Sauvegardes et restauration

La donnée métier du backend se trouve dans /app/pb_data. Ce répertoire contient la base SQLite et les fichiers PocketBase ; sauvegarder seulement le fichier de base ou seulement les médias produit une restauration incohérente.

Objectifs à définir

Terme	Question	Exemple de décision à formaliser
RPO	combien de données peut-on perdre ?	une heure, une journée
RTO	combien de temps pour rétablir le service ?	trente minutes, quatre heures
rétention	combien de générations conserver ?	quotidiennes + hebdomadaires + mensuelles
localisation	où stocker une copie hors serveur ?	stockage objet chiffré, autre fournisseur

Ces valeurs dépendent des engagements métier. Une tâche « backup réussi » ne suffit pas : seule une restauration testée prouve que le RTO est réaliste.

Contenu d’une sauvegarde

• intégralité du volume /app/pb_data ;
• SHA de l’image backend et horodatage UTC ;
• liste des variables nécessaires à la reconstruction, sans leur valeur secrète ;
• export ou registre de la configuration Dokploy ;
• empreinte et taille de l’archive ;
• version du schéma ou dernière migration connue.

Les clés HARMONY_TOTP_ENCRYPTION_KEY et HARMONY_CALENDAR_ENCRYPTION_KEY doivent être sauvegardées séparément dans un coffre. Restaurer les données sans les clés stables rend les champs chiffrés inutilisables.

Cohérence SQLite

Une copie brute pendant des écritures peut capturer plusieurs fichiers à des instants différents. Utilisez en priorité le mécanisme de backup PocketBase/Dokploy prévu pour le volume ou une procédure SQLite cohérente. À défaut, planifiez une courte fenêtre :

1. annoncez la fenêtre et bloquez les écritures ;
2. arrêtez proprement le conteneur backend ;
3. copiez tout le volume vers une destination datée ;
4. calculez une empreinte et envoyez la copie hors machine ;
5. redémarrez le backend ;
6. vérifiez /api/health et un enregistrement représentatif.

Ne présentez pas ici une commande de copie générique comme universelle : le nom et le chemin réel du volume dépendent de Dokploy. Résolvez-les en lecture seule avant toute opération.

Fréquence recommandée

Adaptez la fréquence au RPO, avec au minimum :

• sauvegarde automatisée régulière du volume ;
• sauvegarde immédiate avant une migration ou une opération de masse ;
• copie hors serveur et chiffrée ;
• alerte si aucune sauvegarde récente ou si la taille varie anormalement ;
• test de restauration périodique dans un environnement isolé.

Procédure de restauration

1. Déclarez l’incident et stoppez les écritures sur l’environnement cible.
2. Identifiez l’instant de restauration et vérifiez empreinte, taille et clés associées.
3. Conservez une copie du volume actuel, même s’il semble corrompu.
4. Créez un volume isolé ; ne remplacez pas encore la production.
5. Restaurez l’intégralité de pb_data dans ce volume.
6. Démarrez la version backend compatible avec ce snapshot.
7. Vérifiez migrations, santé, authentification, fichiers, contenus et relations.
8. Comparez des compteurs métier attendus et recherchez des erreurs dans les logs.
9. Basculez le service vers le volume restauré après validation.
10. Surveillez puis consignez perte de données, durée et actions complémentaires.

Le démarrage d’une image plus récente peut appliquer des migrations à la copie restaurée. Faites ce test dans l’environnement isolé et gardez toujours l’archive originale intacte.

Validation d’une restauration

• /api/health répond ;
• le superuser peut ouvrir l’administration PocketBase ;
• un compte back-office peut accomplir le flux mot de passe + TOTP ;
• contenus publics, traductions et fichiers médias sont accessibles ;
• demandes de contact/réservation et statuts sont cohérents ;
• sources de calendrier restent déchiffrables ;
• aucune migration ne boucle ou ne s’exécute plusieurs fois ;
• le web cible bien le backend restauré.

Suppression et confidentialité

Une archive contient des données personnelles et des secrets chiffrés. Limitez les accès, chiffrez le transport et le stockage, journalisez les restaurations, puis appliquez la politique de rétention. La suppression d’une donnée dans l’application doit aussi être prise en compte dans la durée de vie des sauvegardes et les obligations légales applicables.