Sauvegarde et récupération

Sauvegarde

La sauvegarde applicative de beCPG est entièrement automatisée : un service dédié s'exécute en permanence sur le serveur et produit chaque nuit les sauvegardes de l'application.

La sauvegarde inclut :

• Une sauvegarde de l’index de recherche.
• Une sauvegarde des bases de données.
• Une sauvegarde des contenus et des réglages.

L’ordre de la sauvegarde est important. Par défaut, il est garanti par les scripts beCPG et exécuté ainsi :

• 00:00 Mise à jour des statistiques (module OLAP, si installé)
• 03:00 Sauvegarde de l'index de recherche
• 03:30 Sauvegarde des bases de données
• 04:00 Sauvegarde des données et de la configuration

Toutes ces sauvegardes sont écrites sur le disque de données /mnt/becpg-data (/dev/sdb). Les sauvegardes de bases de données y sont conservées 7 jours.

À la charge du client

Le disque de données contient à la fois les données de l'application et ses sauvegardes. Il doit être sauvegardé une fois par jour, vers 5h du matin, à l'aide de votre hyperviseur, une fois les sauvegardes applicatives terminées.

Points de vigilance :

• Conservez également une sauvegarde de la machine virtuelle configurée : cette documentation ne couvre pas la réinstallation de la VM.
• Vérifiez régulièrement que les sauvegardes de l'hyperviseur se terminent correctement et que la rétention appliquée correspond à vos exigences.
• L'espace disque disponible doit rester suffisant pour accueillir les sauvegardes quotidiennes (voir Administration du serveur).

La supervision beCPG contrôle chaque jour la bonne exécution des sauvegardes applicatives et alerte le support en cas d'anomalie.

Dans la suite de ce document, $BACKUP_DIR correspond à la sauvegarde du disque de données une fois remontée sur la machine depuis votre hyperviseur.

Restauration

Deux cas de figure se présentent selon l'incident rencontré.

Dans tous les cas, la restauration s'effectue application arrêtée. Les contenus, la base de données et l'index de recherche doivent rester cohérents entre eux : ne restaurez jamais l'un sans tenir compte des autres.

Cas 1 : restauration complète depuis la sauvegarde du disque (recommandé)

C'est la méthode la plus sûre : la sauvegarde de l'hyperviseur contient les contenus, les bases de données et l'index de recherche pris au même moment, donc naturellement cohérents entre eux.

1. Arrêter l'application :

    cd /opt/becpg-srv-instances/inst1
    docker compose stop
   

2. Restaurer le disque de données /dev/sdb depuis votre hyperviseur, à la date souhaitée, puis le remonter sur /mnt/becpg-data.

3. Redémarrer l'application :

    cd /opt/becpg-srv-instances/inst1
    docker compose up -d
   

4. Vérifier l'état de l'index de recherche :

    ./tools/solr.sh check
   

   En cas d'écart, lancez ./tools/solr.sh fix (voir Administration du serveur).

Cas 2 : restauration de la base de données seule

À utiliser lorsque seules les données applicatives doivent être ramenées à un état antérieur (erreur de manipulation, import massif à annuler) et que les contenus documentaires sont intacts.

Les sauvegardes quotidiennes de la base sont disponibles sur le serveur, dans le volume becpg_backups, sous le dossier becpg-db. Elles sont nommées db_<aa>_<mm>_<jj>.gz et conservées 7 jours. Pour localiser le dossier :

docker volume inspect becpg_backups --format '{{.Mountpoint}}'

Au-delà de 7 jours, récupérez le fichier depuis la sauvegarde de l'hyperviseur, sous $BACKUP_DIR/docker/volumes/becpg_backups/_data/becpg-db/.

1. Arrêter les services applicatifs, en laissant la base de données démarrée :

    cd /opt/becpg-srv-instances/inst1
    docker compose stop becpg becpg-share solr becpg-report
   

2. Copier puis décompresser la sauvegarde choisie :

    BACKUPS=$(docker volume inspect becpg_backups --format '{{.Mountpoint}}')
    cp $BACKUPS/becpg-db/db_26_08_17.gz /tmp/
    gunzip /tmp/db_26_08_17.gz
   

3. Restaurer la base. L'outil fourni recrée la base puis importe la sauvegarde ; il récupère lui-même les identifiants de connexion, aucun mot de passe n'est à saisir :

    ./tools/db.sh restore /tmp/db_26_08_17
   

4. Redémarrer l'application :

    docker compose up -d
   

5. Reconstruire l'index de recherche. L'index reflète l'état de la base avant restauration : il doit être reconstruit, sans quoi la recherche renvoie des résultats erronés.

    ./tools/solr.sh reindex
   

   Attention : la réindexation peut durer plus de 24 heures sur une grosse instance. C'est la raison pour laquelle la restauration complète du disque (cas 1) est à privilégier lorsqu'elle est possible.

Cas des modules optionnels

• beCPG OLAP : les cubes d'analyse sont reconstruits automatiquement à partir des données du PLM lors de la synchronisation suivante. Il n'y a rien à restaurer ; les tableaux de bord se réalimentent seuls, dans un délai de quelques heures.
• beCPG AI : le module ne stocke aucune donnée métier, il n'y a rien à restaurer.

Après la restauration

• Vérifiez que tous les services sont démarrés (voir Administration du serveur).
• Connectez-vous à l'application et contrôlez quelques produits récents ainsi que l'accès aux documents associés.
• Signalez l'incident au support via le gestionnaire d'incidents en précisant la date de la sauvegarde restaurée : cela permet de vérifier la cohérence de l'instance et, le cas échéant, de vous accompagner sur les suites à donner.