3. Gestion des sauvegardes d'Open-Prod
La gestion des sauvegardes est à la charge du client. Elle est à paramétrer en fonction des outils et des méthodes de sauvegarde déjà utilisées par celui-ci. 1Life communique lors du projet tous les renseignements nécessaires concernant les données métier à sauvegarder et les précautions à prendre lors des procédures de sauvegardes / restaurations d'un environnement Open-Prod. L'ensemble de ces informations sont formalisées ci-dessous.
A minima une sauvegarde unitaire des composants est à prévoir (bases de données Open-Prod, bases de données Jasper (outil de reporting en version 9 uniquement) ainsi que les documents de la GED) de manière régulière, avec rétention, sur des supports externes stockés en lieu sûr.
1Life préconise cependant une Sauvegarde complète du ou des environnements ERP :
- Une sauvegarde totale périodique des différents environnements avec tous les disques sans exception (Système d'exploitation et applicatifs ERP).
- La mise en place d'un Plan de Reprise d'Activité (PRA) cohérent avec le maintien en condition opérationnel d'un système d'information d'entreprise
Les modes de sauvegarde
Sauvegarde complète du ou des environnements
Il est tout à fait possible de sauvegarder un environnement informatique dans son ensemble (système d'exploitation et tout ce qui est installé / paramétré dessus), qu’il soit virtuel ou physique, à l’aide de nombreux outils du marché (sauvegarde de machine virtuelle, snapshot, image système, solution de backup complète, etc.).
Ce type de sauvegarde permet, en théorie, de restaurer l’environnement complet (système, applications, données et services) de manière globale en cas d’incident majeur. Cependant, pour que cette sauvegarde soit fiable et exploitable, il est indispensable de respecter un certain nombre de prérequis techniques, en particulier lorsque l’environnement ERP comme Open-Prod repose sur un système Linux, Une base de données PostgreSQL, des services web (serveur applicatif, reverse proxy, services ERP, etc.).
Ces composants imposent des bonnes pratiques spécifiques (cohérence des données, arrêt ou gel applicatif, gestion des transactions, droits systèmes, synchronisation disque). Une sauvegarde complète réalisée sans prendre en compte ces contraintes peut conduire à une restauration incomplète ou inutilisable, notamment pour les bases de données en production.
Responsabilité du client et du prestataire
La mise en œuvre d’une sauvegarde complète de l’environnement relève de la responsabilité du client, en tant que propriétaire des données et du système, mais surtout de celle du prestataire (hébergeur, intégrateur, infogérant) lorsqu’il met à disposition l’environnement. Le prestataire doit :
- Se conformer aux bonnes pratiques techniques (Linux, PostgreSQL, services web, etc.),
- Utiliser des outils adaptés,
- S’assurer de la cohérence des sauvegardes et être en capacité d’expliquer les conditions de restauration.
Autrement dit, proposer une sauvegarde d’environnement ne se limite pas à « faire une copie », mais implique une maîtrise technique et méthodologique de l'ensemble du du système livré.
1Life ne fournit donc pas d’outil de sauvegarde complète de l’environnement, cette opération étant étroitement dépendante de l’infrastructure du client et relevant de sa responsabilité ou de celle de son hébergeur. Le rôle de 1Life consiste à garantir, sécuriser et documenter la sauvegarde des données métier, sans intervenir sur la sauvegarde de l’infrastructure sous‑jacente.
Cas où la sauvegarde complète de l’environnement n’est pas en place
Si aucune sauvegarde complète et cohérente de l’environnement ERP n’a été prévue ou mise en œuvre par le prestataire ou le client, il revient alors au client de mettre en place lui même une stratégie de sauvegarde (avec l’aide ou non de son prestataire) en s’appuyant sur une sauvegarde unitaire des données métier essentielles à la reprise d’activité de l’ERP, notamment :
• Les données applicatives (base PostgreSQL ERP et Jasper Server ),
• Les fichiers métiers et documents (document GED Système et Client),
• Les éventuels paramétrages applicatifs et systèmes,
• Les éléments nécessaires à la reconstruction du service (configuration, scripts, versions).
Cette approche permet d’assurer une reprise d’activité fonctionnelle, même en l’absence d’une restauration « clé en main » de l’environnement complet.
Les informations suivantes de ce chapitre sont là pour vous accompagner sur ce mode de sauvegarde.
Sauvegarde unitaire des composants du ou des environnement(s)
Si aucune sauvegarde complète du ou des environnement ERP n’est prévue, il revient alors au client et à son prestataire de mettre en place une stratégie de sauvegarde unitaire des données métier essentielles à la reprise d’activité de l’ERP. Ce document décrit l’organisation de ce type de sauvegarde . Il précise le rôle et les responsabilités respectives de : l’éditeur (Open Prod), l’intégrateur (1Life), le client (DSI / exploitation),
Afin de garantir :
• L’extractibilité et la réversibilité des données,
• La sécurité et la pérennité des informations métier,
• La capacité de restauration en cas d’incident ou de sinistre.
Il présente ensuite les outils métier mis à disposition par Open-Prod et 1Life pour réaliser ces sauvegardes.
Organisation de la sauvegarde des données métier
1. Périmètre des données concernées
Les sauvegardes doivent couvrir l’ensemble des données critiques de l’environnement. Soit :
- Bases de données ERP Open-Prod (données métier, référentiels, historiques). Celles si se trouvent en général sous /var/lib/postgresql/xx/main/base (ou xx correspond à la version de PostgreSQL)
- Bases de données Jasper Server - pour la V9 uniquement (rapports, modèles, définitions) sous /opt/jasperserver_7.2.0/PostgreSQL/data/base
- Fichiers de GED système et client (fichiers système, éditions, documents joints, pièces comptables, documents métiers)
- Fichiers GED client (un dossier par base) : /etc/openprod_home/filestore/share/Open-prod/documents/
- Fichiers GED système (un dossier par base) : /etc/openprod_home/filestore/share/Open-prod/filestore/
- Fichiers applicatifs et de configuration essentiels (paramétrage, scripts, connexions, éléments nécessaires à une restauration fonctionnelle, versions applicatives)
- Fichier Open-Prod de configuration : /etc/openprod_home/openprod-server.conf
- Fichier PostgreSQL de configuration : /etc/postgresql/16/main/postgresql.conf
- Fichier PostgreSQL de connexion : /etc/postgresql/16/main/pg_hba.conf
2. Responsabilités de l’éditeur (Open Prod)
L’éditeur Open Prod est responsable de la conception logicielle de la solution et de la mise à disposition des mécanismes d’extraction des données.
À ce titre, l’éditeur :
- Propose, développe et maintient les outils et fonctionnalités permettant l’extraction des données, notamment : Mécanismes d’export des bases de données, Accès aux données GED, Outils ou fonctionnalités d’export pour Jasper Server.
- Garantit que les données de l’ERP sont techniquement extractibles dans des formats standards et exploitables.
- Assure la compatibilité des outils d’extraction avec les versions supportées de la solution.
- Met à jour les outils d’extraction dans le cadre des évolutions du produit.
L’éditeur n’est pas responsable : de l’exécution des sauvegardes, du stockage des données, de la politique de rétention ni des tests de restauration.
3. Responsabilités de l’intégrateur
L’intégrateur intervient comme tiers expert entre l’éditeur et le client. Il est responsable de la présentation, de l’appropriation et de la documentation des outils fournis par l’éditeur.
À ce titre, l’intégrateur doit :
- Identifier et cartographier les données critiques à sauvegarder dans l’environnement client.
- Présenter et expliquer au client les outils d’extraction mis à disposition par l’éditeur Open Prod.
Documenter leur utilisation :
- Procédures d’export,
- Prérequis techniques,
- Contraintes de cohérence applicative,
- Formats et volumétrie des données.
Mettre à disposition, le cas échéant, des scripts ou procédures complémentaires facilitant l’exploitation des outils de l'éditeur. S’assurer que les méthodes proposées permettent une restauration fonctionnelle sur un environnement équivalent.
L’intégrateur ne réalise pas les sauvegardes opérationnelles, sauf prestation explicitement contractualisée.
4. Responsabilités du client (DSI / Exploitation)
Le client, via sa DSI ou son équipe d’exploitation, est pleinement responsable de la stratégie de sauvegarde et de son exécution au travers des éléments communiqués dans ce document.
5. Mise en œuvre
Le client doit :
• Récupérer régulièrement les données extraites à l’aide des outils fournis par l’éditeur et documentés par l’intégrateur.
• Mettre en œuvre les outils de sauvegarde (solutions de backup, automatisation, supervision).
Schéma de principe :
5.1 Définition de la politique de sauvegarde
La DSI définit et formalise :
- Le mode de sauvegarde (sauvegarde complète, sauvegarde incrémentielle ou différentielle, etc.)
- La fréquence de sauvegarde (quotidienne, hebdomadaire, mensuelle, etc.)
- La politique de rétention : journalier, hebdomadaire,semestriel, annuel, selon les exigences métier, réglementaires et légales.
- Les supports de sauvegarde (stockage interne, stockage externe ou déporté, unité de stockage amovible, bandes, site distant
- ou secondaire., etc.)
5.2 Contrôle et exploitation
Le client est responsable de :
- La vérification régulière de l’exécution des sauvegardes,
- La sécurisation des données sauvegardées (accès, chiffrement, conservation),
- La réalisation de tests de restauration périodiques,
- L’intégration de l’ERP Open-Prod dans le Plan de Continuité d'Activité (PCA) ou Plan de Reprise d'Activité (PRA) de l’entreprise.
Les informations suivantes présentent l'ensemble des outils mis à disposition pour extracter les données métier.
Sauvegarde ponctuelle au travers d'un navigateur ou sur le serveur
Sauvegarde manuelle :
Permet de sauvegarder ponctuellement de manière manuelle la GED Système et Client et / ou la base de données Open-Prod. Cette sauvegarde se réalise soit depuis le navigateur du poste client, à distance du serveur, sinon directement depuis le serveur Open-Prod via les scripts myhelp.
Ce type de sauvegarde est recommandée en cas de besoin de mise en place d'une base de test, de transfert rapide de base d'un environnement à un autre, de sauvegarde ponctuelle d'appoint avant un test de paramétrage par exemple. Cette méthode ne peut pas être plannifiée dans le temps.
NOTA : il est important de vérifier l'espace disque disponible sur le serveur Open-Prod avant de lancer le traitement car le fichier de sauvegarde est tout dabord créé localement sur le serveur Open-Prod avant d'étre éventuellement uploadé sur le poste client. Naturellement, lors de ces sauvegardes, l'idéal reste que les utilisateurs ne soient pas connectés afin de garantir une intégrité des données maximum.
Depuis le navigateur
Pour la base de données Open-Prod et la GED
- Se connecter sur le Portail Open-Prod.
- Cliquer sur "Gestion des bases de données" depuis l'écran de connexion.
3. Localiser la base de données que vous désirez sauvegarder, puis cliquer sur « Backup »
4. Saisir le mot de passe administrateur puis le type de sauvegarde souhaitée :
5. Enfin, cliquer sur "Backup" pour lancer la production de la sauvegarde sur le serveur. Celle-ci sera automatiquement téléchargée sur le poste client.
L'option "zip (includes filestore)" produira une sauvegarde contenant l’ensemble de la GED incluse dans l’ERP tandis que l'option "pg_dump custom format (without filestore)" réalisera un simple dump de la base données. C'est à dire une sauvegarde SANS la GED d'Open-Prod.
Note importante : seules les sauvegardes type "zip (includes filestore)" permettent de restaurer l'entièreté de la GED. Cela implique que la restauration des sauvegardes type "dump" ne permettent pas de profiter de l'ensemble des fonctionnalités après restauration. Attention, ce type de sauvegarde peut nécessiter un espace disque important.
Pour les base(s) de données Jasper (version Open-Prod V9 uniquement)
- Se connecter sur le portail Jasper Serveur. Le service est disponible à l'adresse ou est installé le serveur Jasper Report (sur l'environnement Open-Prod dans la majoritée des cas) : http://[IP-Server]:8080/jasperserver/login.html
- Renseigner l'ID de l'utilisateur et le mot de passe (en général jasperadmin / jasperadmin)
- Aller dans Gérer > Paramètres du serveur > Exporter
- Indiquer un nom d'export (export.zip par exemple) puis cocher l'option "Exporter tout") puis valider par le bouton "Exporter" en bas de fenêtre. Le fichier sera automatiquement téléchargé sur le poste client.
- Mettre de coté le fichier sauvegardé
Depuis le serveur Open-Prod
Consulter la page Sauvegarde Ponctuelle depuis le serveur
Sauvegarde récurente via commandes myhelp
Les outils présentés ci-dessous permettent de sauvegarder automatiquement de manière ponctuelle ou plannifiée (avec récurence) la GED Système et Client et / ou la base de données Open-Prod et Jasper. Cette sauvegarde se réalise sur le serveur ERP Open-Prod qui conserve le ou les fichier(s) de sauvegarde à l'emplacement indiqué par la tache de sauvegarde.
Il est possible avant de lancer les sauvegardes de créer un dossier dédié à l'accueil de ces sauvegardes sur l'environnement Open-Prod. Il est également possible de le partager pour récupérer ensuite ces fichiers au travers du réseau local. Consulter la page de la commande shared-folder-config pour celà.
il est important de vérifier l'espace disque disponible sur le serveur Open-Prod avant de lancer un traitement car le fichier de sauvegarde est tout dabord créé localement sur le serveur Open-Prod avant d'étre éventuellement downloadé sur le poste client. Naturellement, lors de ces sauvegardes, l'idéal reste que les utilisateurs ne soient pas connectés afin de garantir une intégrité des données maximum.
Utilisation de l'outil :
Au travers des outils myhelp, myFAB propose des fonctions permettant de réaliser des sauvegardes ponctuelles ou automatisées des bases de données d'Open-Prod.
Les sauvegardes effectuées au travers des scripts myhelp produisent des sauvegardes de type :
- zip (includes filestore). Ceci comporte la ou les bases de données (ERP, Jasper) ainsi quye la GED (documents système et client)
- "pg_dump" (without filestore). Comporte uniquement la ou les bases de données (sans la GED)
Note importante : seules les sauvegardes type "zip", (avec sauvegarde des bases de données + GED) permettent de restaurer l'entièreté des données de l'ERP. Attention, ce type de sauvegarde peut nécessiter un espace disque important (la GED peut occuper beaucoup d'espace). Cela implique que les sauvegardes de type "dump" (sans sauvegarde de la GED) ne permettent pas de profiter de l'ensemble des fonctionnalités de l'ERP après restauration.
1. Réalisation d'une sauvegarde ponctuelle via scripts myhelp
Sur l’utilisateur ubuntu d'administration des scripts myhelp, les commandes sql-backup et sql-auto-backup sont accessibles directement en mode commande au travers des scripts myhelp.
Depuis votre terminal, taper sql-backup.
Tapez 0 pour sauvegarder votre ou vos bases Open-Prod, 1 pour votre base jasper.
Sélectionnez la base que vous désirez sauvegarder, puis indiquer le répertoire ou le dump sera placé.
2. Mise en place d'une sauvegarde automatique
Depuis votre terminal, tapez sql-auto-backup suivi de « Entrée » :
Renseigner les informations suivantes :
- Sélectionner l'application à sauvegarder (OPen-Prod ou Jasper si V9),
- Indiquer si la GED est également à prende en compte lors de la sauvegarde,
- Sélectionner la ou les bases à inclure,
- Tout comme pour la réalisation d’une sauvegarde manuelle, la commande demandera le répertoire de destination où seront produits le ou les dump ou zip.
- L’intervalle de temps entre chaque sauvegardes (saisir 24h si vous désirez une sauvegarde quotidienne, par exemple).
- Enfin, la durée de rétention de sauvegarde : indiquez ici le nombre de jour consécutifs sur lesquels vous désirez conserver une sauvegarde.
Note importante : l’espace utile nécessaire à la réalisation d’une telle programmation est à étudier en amont, en fonction de la volumétrie des bases, du nombre de bases, et du nombre de jours de rétention souhaité : il peut être souhaitable de réaliser cette sauvegarde sur un autre volume, externe au serveur de gestion de base de données.
Une fois la programmation réalisée, l’utilisateur peut revenir sur celle-ci afin de l’ajuster (modification de l’heure de lancement, jour de la semaine, etc..) en tapant la commande suivante :
sudo -u root crontab -e
La machine affichera alors la programmation du « cron » système de l’utilisateur root.
Note importante : la modification d’un paramétrage de sauvegarde automatique doit être réalisée par un utilisateur expert dans la notion de cron linux et ayant une bonne maitrise d’un éditeur de texte tel que vim ou nano. Naturellement, si la programmation de cette sauvegarde est modifiée d’une quelconque manière, il convient de vérifier, au cours des jours suivant la modification que les sauvegardes réalisées sont bien fonctionnelles et en adéquation avec les attentes initiales.
3. Mise en sécurité des sauvegardes
Une fois les tâches de sauvegarde effectuées, il est important de mettre ces sauvegardes en sécurité sur un espace de stockage dédié. Il est ensuite possible d’utiliser toute méthode ou outil tiers de sauvegarde installé sur le réseau local afin de récupérer les sauvegardes présentes dans ce répertoire partagé et de les répliquer vers des sites distants ou vers des supports de sauvegarde indépendants (disques externes, supports à bande, etc.).
Sauvegarde récurente via commandes Externes
Attention ! Les batch (ou lignes de commande) sont fournis à titre d’exemple : ils sont à adapter et à tester en fonction du contexte réseau et du résultat attendu. Ils doivent être mis en place par un utilisateur maitrisant PostgreSQL et les flux réseau associés. En fonction des protocoles de sécurité mis en place, les identifiants et mot de passes peuvent circuler en « clair » sur le réseau !
1. Réalisation d’une sauvegarde distante via pg_dump (au travers des fonctions de sauvegarde Postgresql)
Descriptif de la commande : pg_dump est une commande Postgresql permettant de réaliser une sauvegarde d’une base de données PostgreSQL locale ou distante.
Documentation en ligne : https://docs.postgresql.fr/15/app-pgdump.html
Tant sous Windows que sous linux, il est possible de réaliser une sauvegarde distante via la commande pg_dump :
pg_dump --no-owner --format=c -h <IP_SERVER> -p <PORT> -d <BDD> -U <USER_POSTGRESQL>
Exemple d’utilisation de la commande pg_dump sous windows.
Naturellement, sous Windows, il conviendra de télécharger un PostgreSQL et de n’installer, par exemple, que les outils en ligne de commande :
Sur un serveur linux, les paquets nécessaires à la cette opération seront à installer sur le serveur distant :
Pensez toujours à télécharger une version des commandes PostgreSQL (Linux ou Windows) compatible et au plus proche de la version présente sur l’environnement Open-Prod !
Pour Windows, rendez-vous sur l’url : https://www.postgresql.org/download/windows/
Note : les commande pg_restore, createdb et dropdb sont aussi disponibles sur les différents OS. Naturellement l’utilisation de ces commandes spécifiques nécessite une bonne connaissance de PostgreSQL.
Toutes les commandes précitées nécessitent une authentification sur le serveur PostgreSQL distant. Rendez-vous sur l’url : https://www.postgresql.org/docs/12/libpq-pgpass.html afin d’automatiser la connexion à partir du poste client.
2. Réalisation d’une sauvegarde via curl (au travers des fonction de sauvegarde Open-Prod)
Descriptif de la commande : curl est une commande présente sur de nombreux système Windows et Linux. Cette commande permet d’exécuter des scripts ou des connexion web en ligne de commande. Elle permet, entre autres, de transférer des fichiers. Cette fonction Curl expose les méthodes de sauvegarde Open-Prod (pour la base de données et la GED).
Cette commande peut être lancée directement sur le serveur Open-Prod ou depuis un environnement client du réseau local (poste Windows, poste Linux, serveur NAS, système de sauvegarde, etc.).
Pour plus d’information, rendez-vous sur : https://curl.se/docs/tooldocs.html
Exemple de script Windows :
Syntaxe de la fonction utilisée :
curl -X POST -F master_pwd=<MASTER_PASSWORD> -F name=<DATABASE> -F backup_format=<BACKUP_FORMAT> -o <NOM_DE_FICHIER> http://<ADRESSE_IP>:8068/web/database/backup
Mise en script .bat de la fonction pour Windows :
@ECHO OFF
SET ADMIN_PASSWORD_DEST=M0t2PassE
SET SERVEUR_DEST=192.168.40.17
SET DATABASE_DEST=REFERENCE_MYFAB
SET BACKUP_FORMAT=zip
SET FILE_DEST=REFERENCE_MYFAB_BCK_WIN_CURL.zip
curl -X POST -F master_pwd=%ADMIN_PASSWORD_DEST% -F name=%DATABASE_DEST% -F backup_format=%BACKUP_FORMAT% -o %FILE_DEST% http://%SERVEUR_DEST%:8068/web/database/backup
Note : la variable ADMIN_PASSWORD_DEST est ici le mot de passe Admin de manipulation de bases de données sous Open-Prod. Naturellement l’url de sauvegarde doit embarquer le protocole (ici http) et le port (8068). Le type de sauvegarde (dump ou zip) est à adapter en fonction de la volumétrie et du stockage de la GED d’Open-Prod.
Utilisation du script .bat
La mise en place d’un paramétrage de sauvegarde à distance doit être réalisée par un utilisateur connaissant bien la notion des flux réseau. Naturellement, un test de la validité du fichier .zip (donc la sauvegarde) est à réaliser en aval de ladite sauvegarde de manière périodique, par tentative de restauration sur le serveur, par exemple.
Autre exemple détaillé d'une sauvegarde / restauration via curl :
1 - Sauvegarde backup zip sur serveur Open-Prod ou depuis un poste distant Windows
Décomposition des options
curl: client API HTTP(s) en ligne de commande.-X POST: envoie une requête HTTP POST (nécessaire pour cet endpoint).-F master_pwd=openprod: champ de formulairemaster_pwdOpen-Prod (mot de passe maître) défini dans la configuration du serveur (fichierserver.confOpen‑Prod). Sans ce mot de passe, le serveur refuse l’opération.-F name=BaseOPP1: nom de la base de données à sauvegarder.-F backup_format=zip: demande un format fichier ZIP (contient le dump SQL + éventuellement les fichiers/filestore selon l’implémentation).-o SauvOPP_001.zip: nom du fichier de sortie côté client. Le contenu renvoyé par le serveur est écrit dans ce fichier.https://10.10.20.30:8068/web/database/backup: URL de l’endpoint de backup (sur Open‑Prod, c’est l’API standard de sauvegarde des bases).10.10.20.30: IP du serveur8068: port HTTP(S) utilisé par le service (utiliser le l'url directe si nom DNS ou le port 443)/web/database/backup: route qui génère la sauvegarde.
curl -X POST -F master_pwd=openprod -F name=BaseOPP1 -F backup_format=zip -o SauvOPP_001.zip https://10.10.20.30:8068/web/database/backup
le fichier SauvOPP_001.zip sera créé dans le répertoire courant (celui où est exécuté la commande curl). Si la commande est lancée sous Linux depuis /home/erp/ le fichier sera sous : /home/erp/SauvOPP_001.zip. Si la commande est lancée sous Windows depuis C:\Windows\System32 e fichier sera sous : C:\Windows\System32\SauvOPP_001.zip
Exemple d'utilisation de la fonction sous Windows / cmd (préparation du fichier puis transfert du fichier sur le disque en local sous Windows) :
2. Copie du fichier de sauvegarde
2.1 Depuis le serveur Open-Prod vers un autre environnement Linux (NAS, serveur de sauvegarde Linux, etc.) si la sauvegarde a été lancée sur le serveur Open-Prod. Sous terminal Linux, lancer :
scp /home/erp/SauvOPP_001.zip erp@10.10.20.40:/home/erp/
2.2. Depuis un poste Windows connecté au réseau si la sauvegarde a été lancée sur le serveur Open-Prod. Sous Windows cmd, lancer :
scp erp@10.10.20.30:/home/erp/SauvOPP_001.zip C:\
3. Restauration :
5. Intégrer le token de session et lancer la restauration du backup par Curl :
curl -X POST -F master_pwd=openprod -F name=SauvOPP_001 -F backup_file=@/home/erp/SauvOPP_001.zip -F "copy=true" -F csrf_token=6b7c2d9daac14ff4c5615e9429cd93bd32f002b7 http://10.10.20.40:8068/web/database/manager