Sauvegarde et restauration

1. Avant de commencerCopier le lien du titre

Exécutez les commandes depuis le kit correspondant au schéma de la base (en principe la version installée), avec Python 3.11+ et les paquets de backend/requirements.txt. Le service Compose postgres de l’installation doit fonctionner : l’outil exécute les commandes PostgreSQL dans ce conteneur. Sous macOS/Linux, utilisez python3. Sur un serveur Linux, un environnement virtuel garde ces paquets à l’écart du système : voir Installer sur un VPS, pas à pas, où une sauvegarde et une restauration isolée ont été exécutées.

Pour une installation créée par le lanceur, ajoutez --workspace CHEMIN_PRIVE avant la commande, comme ci-dessous. Pour une installation Compose manuelle configurée dans .env, omettez-le.

Les mots de passe passent par l’environnement du processus enfant, jamais par la ligne de commande. Les erreurs PostgreSQL et le contenu des sauvegardes ne sont jamais affichés, car ils peuvent contenir des données.

2. Faire une sauvegardeCopier le lien du titre

python scripts/database_backup.py --workspace CHEMIN_PRIVE backup

Sans --output, l’archive se nomme vrp-<heure UTC>-<id>.dump dans le dossier backups du kit. Avec --output FICHIER, choisissez un nouveau nom à chaque fois : un fichier existant n’est jamais écrasé.

La commande vérifie d’abord que le schéma de la base correspond au kit. Elle écrit une archive PostgreSQL cohérente et ne la publie qu’une fois complète. L’archive contient les comptes et leurs empreintes de mot de passe, l’entreprise et ses paramètres, les dépôts et lieux, les clients, les véhicules, les livraisons, les calculs et les plans enregistrés ; les sessions de connexion en sont exclues.

Sous Windows, l’archive hérite des droits de son dossier : utilisez un dossier lisible par les seuls opérateurs.

3. Chiffrer les archives qui quittent la machineCopier le lien du titre

Installez age sur la machine et indiquez une clé publique destinataire :

python scripts/database_backup.py --workspace CHEMIN_PRIVE backup --encrypt-to age1...

L’archive vérifiée est chiffrée dans un fichier .dump.age et le fichier temporaire non chiffré est supprimé. Seule l’identité privée correspondante permet de la restaurer : conservez-la hors du serveur.

4. Planifier, copier hors de la machine et élaguerCopier le lien du titre

1. Planifiez la commande de sauvegarde avec cron, un timer systemd ou le Planificateur de tâches Windows.
2. Copiez chaque archive chiffrée vers un stockage séparé, par exemple avec rclone ou rsync. Une copie sur le même disque ne protège pas contre la perte de la machine.
3. Supprimez explicitement les archives plus anciennes :

python scripts/database_backup.py prune --keep 14

prune conserve les N archives les plus récentes du dossier backups du kit (--directory en choisit un autre). Il ne supprime que les fichiers nommés par cet outil (vrp-…dump ou vrp-…dump.age) ; les autres fichiers, dont les archives before-upgrade-*.dump du lanceur, ne sont pas touchés. Rien n’est jamais élagué automatiquement.

L’outil se termine avec un code non nul en cas d’échec et ne publie alors aucune archive. Déclenchez une alerte sur ce code et sur l’âge de l’archive la plus récente, pour remarquer une planification arrêtée sans bruit. Convenez de la durée de conservation avant d’enregistrer des données réelles : les sauvegardes conservent les données supprimées ou effacées jusqu’à leur élagage.

5. Restaurer dans une base isoléeCopier le lien du titre

python scripts/database_backup.py --workspace CHEMIN_PRIVE restore backups/ARCHIVE.dump

Pour une archive chiffrée, ajoutez --identity FICHIER_IDENTITE. Ne restaurez que des archives de confiance : une archive PostgreSQL peut contenir du SQL exécutable.

La commande crée une nouvelle base nommée vrp_restore_ suivi de 32 chiffres hexadécimaux, restaure en une seule transaction, vérifie le schéma, supprime les sessions de connexion et réapplique les droits de l’application. Elle affiche le nom de la base et le nombre de lignes par table. Elle ne remplace jamais la base en service, ne modifie pas la configuration, ne démarre pas de worker et ne bascule pas les utilisateurs. Si elle échoue après la création de la base, cette base isolée est conservée pour inspection.

Le nombre de lignes n’est qu’un premier contrôle.

6. Basculer vers la copie restauréeCopier le lien du titre

Pour une installation créée par le lanceur, utilisez ce lanceur :

python scripts/start_server.py --directory CHEMIN_PRIVE --cutover-to vrp_restore_...

Une installation locale utilise start_local.py avec les mêmes options. Une installation Compose manuelle utilise l’outil de sauvegarde, en indiquant dans l’ordre les fichiers Compose supplémentaires qu’elle utilise ; le fichier de base deploy/docker-compose.example.yml vient toujours en premier :

python scripts/database_backup.py cutover vrp_restore_... --overlay deploy/docker-compose.routing.yml

La bascule vérifie que la base cible existe et correspond au schéma de l’application, puis arrête l’API et le worker afin qu’aucune base ne soit modifiée pendant le changement. Elle fait pointer POSTGRES_DB (et DB_NAME, s’il est défini) vers la cible et démarre l’installation : setup réapplique les migrations et les droits, et le proxy HTTPS est redémarré. Si l’installation ne devient pas saine, la base précédente est rétablie et redémarrée.

Aucune base n’est modifiée ni supprimée. Les utilisateurs se reconnectent. Vérifiez la connexion d’un compte nominatif, les plans enregistrés et un nouveau calcul avant de vous fier à la copie.

7. Revenir à la base précédenteCopier le lien du titre

La bascule affiche la commande exacte pour revenir à la base précédente. Il s’agit de la même bascule, qui nomme la base précédente. Conservez cette base jusqu’à ce que les vérifications de l’étape 6 soient concluantes.

Le point de reprise est l’archive la plus récente : choisissez l’intervalle des sauvegardes selon la quantité de travail de planification que vous pouvez perdre.

8. Conservation et effacementCopier le lien du titre

Les plans et les calculs conservent des copies des adresses, instructions et coordonnées des livraisons. Le rôle de base de données de l’API ne peut pas les supprimer ; ces commandes utilisent le rôle de migration, dans le conteneur setup. Le kit les documente pour une installation Compose configurée dans .env :

docker compose --env-file .env -f deploy/docker-compose.example.yml run --rm setup python -m app.retention purge --older-than-days 90 --dry-run
docker compose --env-file .env -f deploy/docker-compose.example.yml run --rm setup python -m app.retention erase-order --external-id ORDER-123

• purge --older-than-days N (au moins 1) supprime les plans non modifiés depuis N jours et les calculs terminés depuis plus de N jours ; un plan sur lequel un calcul travaille encore est conservé. --orders supprime aussi les livraisons datées de plus de N jours.
• erase-order --external-id ID remplace l’adresse d’une livraison par [erased], efface ses instructions et ses coordonnées, la désactive et supprime les plans et calculs qui l’ont copiée.

Les deux commandes n’affichent que des nombres et acceptent --dry-run pour un compte rendu sans modification. Elles ne suppriment jamais un calcul en attente ou en cours ; erase-order refuse tant qu’un tel calcul inclut la livraison. Les sauvegardes antérieures conservent les données jusqu’à leur élagage : fixez leur durée de conservation dans la période convenue.