Mettre à jour et sauvegarder l'application

Cette page s'adresse à l'administrateur technique d'une instance MyZapp installée sur ses propres serveurs (voir « Installer l'application sur ses serveurs »). Sur une instance hébergée par l'éditeur, les sauvegardes et les mises à jour sont assurées par l'hébergeur.

Ce qu'il faut sauvegarder

Une instance ne garde son état qu'à deux endroits :

• la base PostgreSQL : toutes les données et tout le paramétrage ;
• le volume de données de l'application : sa configuration locale (avec les secrets chiffrés), les journaux et les fichiers déposés.

Les conteneurs eux-mêmes ne contiennent rien à garder : ils se recréent à l'identique depuis l'image. Sauvegardez aussi, à part, les fichiers du serveur : .env, le dossier secrets/ et, s'il est utilisé, le dossier views-override/. Conservez les clefs de sécurité exportées à l'installation avec la même prudence.

Sauvegarder

Le script backup.sh, livré avec l'application, produit en une commande :

• un dump de la base, db_ suivi de la date, au format de pg_restore (ce n'est pas un fichier SQL lisible) ;
• une archive du volume de données, appdata_ suivi de la date.

Lancez-le depuis le dossier du fichier d'orchestration : ./backup.sh .env ./backups. Il garde les 10 dernières sauvegardes de chaque type ; BACKUP_RETENTION_COUNT dans .env change ce nombre.

En option, réglées dans .env :

• le chiffrement des sauvegardes (BACKUP_ENCRYPT=true, par mot de passe ou par clé publique GPG) ;
• une copie hors site vers une ou plusieurs destinations : FTP, stockage compatible S3, partage Windows, partage déjà monté ou serveur joignable en SSH (BACKUP_OFFSITE_TYPES). Par défaut, l'échec d'une copie hors site n'est qu'un avertissement ; BACKUP_OFFSITE_REQUIRED=true en fait une erreur.

L'application ne lance pas ce script d'elle-même : planifiez-le sur le serveur, par exemple chaque nuit avec cron. La liste complète des réglages figure en tête du script.

Restaurer

La même procédure sert après un incident et pour reconstruire une instance sur un nouveau serveur.

1. Démarrez seulement la base et arrêtez l'application, pour qu'aucune migration ne s'applique pendant la restauration.
2. Si les sauvegardes sont chiffrées, déchiffrez-les d'abord.
3. Restaurez la base avec pg_restore et les options --clean --if-exists, dans le conteneur webbase-postgres.
4. Restaurez le volume de données à partir de son archive : son contenu actuel est remplacé.
5. Redémarrez l'ensemble, puis vérifiez que /health répond Healthy.

Une base restaurée sur une autre installation (par exemple une production copiée en recette) peut faire apparaître une identité en conflit sur la page Licences : choisissez alors entre nouvelle instance et instance déplacée (voir « Gérer les licences de l'instance »).

Mettre à jour la version

1. Sauvegardez : une mise à jour ne prévoit aucun retour arrière automatique.
2. Chargez la nouvelle image (docker load pour un fichier) ou indiquez sa version dans WEBBASE_IMAGE, dans .env.
3. Avec un registre, tirez la nouvelle image : docker compose -f docker-compose.onprem-client.yml pull.
4. Redémarrez : docker compose -f docker-compose.onprem-client.yml up -d. Les données sont conservées.

Au démarrage, chaque module applique lui-même ses migrations de base de données. Contrôlez ensuite :

• l'écran État de l'instance, qui affiche la nouvelle version, et l'écran Diagnostic support, qui doit indiquer À jour pour chaque module (voir « Surveiller l'instance ») ;
• le Journal des versions, qui liste les évolutions de la version installée ;
• la documentation livrée avec la version, à importer de nouveau (voir « Mettre à jour la documentation »).

Lisez les notes de la version avant de mettre à jour : certaines demandent une étape de plus, par exemple recopier un nouveau fichier d'orchestration.

Une vue personnalisée doit se trouver dans views-override/ : c'est le seul emplacement conservé d'une version à l'autre.

Si la mise à jour échoue

Si une migration échoue, l'application ne démarre pas et la base peut rester dans un état intermédiaire. Pour revenir à la version précédente :

1. restaurez la sauvegarde faite juste avant la mise à jour (voir plus haut) ;
2. remettez l'ancienne version dans WEBBASE_IMAGE ;
3. redémarrez.

Remettre seulement l'ancienne image ne suffit pas quand la nouvelle version a déjà migré la base : les migrations appliquées ne sont pas annulées. L'ancienne image reste disponible sur le serveur tant qu'elle n'a pas été supprimée.

Changer de version de PostgreSQL

Une nouvelle version majeure de PostgreSQL ne relit pas les fichiers de données de la précédente : changer seulement l'image de la base ne fonctionne pas. Il faut un dump complet, une base neuve dans la nouvelle version, puis la restauration du dump. Gardez une image qui contient l'extension pgvector, utilisée par la base de connaissances : sans elle, la restauration échoue.

Voir aussi

• « Installer l'application sur ses serveurs ».
• « Surveiller l'instance » : version, état de la base, modules et migrations.
• « Changer la connexion à la base de données ».