Aller au contenu

Sauvegarde et reprise

Politique actuelle : retrait Backblaze B2, decision du 11/10/2026. Les sauvegardes/PITR B2 decrits ci-dessous sont historiques, retires de la composition active. Aucun remplacement externe qualifie.

Le runbook opérateur exécutable sans agent est disponible dans Sauvegarde et reprise sans IA.

État actuel

  • etcd embarqué sur trois serveurs.
  • Snapshot post-migration créé sur le VPS principal.
  • Sauvegarde pré-HA sous /var/backups/k3s/ sur le VPS principal.
  • Les PVC utilisent encore local-path et ne sont pas répliqués.
  • n8n dispose de sauvegardes PostgreSQL CloudNativePG/Barman vers Backblaze B2. Au 7 octobre 2026, les deux catalogues actifs exposent une fenêtre de récupération et les backups quotidiens les plus récents sont completed.

Snapshot etcd

Sur un serveur K3s :

sudo k3s etcd-snapshot save --name manuel-$(date +%Y%m%d-%H%M)
sudo k3s etcd-snapshot ls

Copier régulièrement les snapshots hors des VPS du cluster. Un snapshot présent uniquement sur le serveur défaillant n'est pas une sauvegarde.

Sauvegarde n8n PostgreSQL

Deux générations n8n coexistent au relevé du 09/10/2026 : n8n-postgresql dispose d'un catalogue historique Barman ; la base actuellement consommée par le Deployment n8n est n8n-incident-recovery, référencée par DB_POSTGRESDB_HOST=n8n-incident-recovery-rw.n8n.svc.cluster.local, avec son catalogue B2 dédié. Les tests de restauration doivent viser la génération pertinente, sans confondre les catalogues.

  • planification déclarée : tous les jours à 02:00 via ScheduledBackup ;
  • destination : bucket B2 backups-lab, préfixes distincts selon la génération PostgreSQL ; ne pas substituer le catalogue historique à celui de la base active ;
  • rétention déclarée : 7d ;
  • données et WAL : compression gzip, chiffrement AES256 ;
  • les identifiants B2 restent hors Git dans le Secret référencé par le manifeste ;
  • l'archivage WAL ne doit pas être désactivé pour contourner une erreur de rétention.

L'ancien incident RetentionPolicyFailed de septembre est clos côté état runtime observé : au 7 octobre 2026, les ObjectStore n8n-incident-recovery-b2-live-v1 et n8n-postgresql-b2-live-v2 exposent chacun une serverRecoveryWindow avec un dernier backup réussi le 7 octobre vers 02:00, et les Backup quotidiens visibles depuis le 30 septembre sont completed. La rétention déclarée reste 7d.

Cette santé du catalogue ne remplace pas un test de restauration périodique. Continuer les drills isolés, notamment après changement de CNPG/Barman, de clé de chiffrement n8n ou de génération de catalogue.

Données persistantes à protéger

Archive de l'inventaire du 24/08/2026, non exhaustif aujourd'hui. La liste de quatre PVC ci-dessous est historique : elle précède notamment les bases CNPG NotreCouple, n8n et Plane, Task Runtime et la file du dispatcher. Pour l'état présent, lancer kubectl get pvc -A -o wide et classer les volumes par application, nœud, StorageClass et nécessité de restauration.

PVC Taille Risque Priorité
moncouple/moncouple-data 1 GiB Perte de données privées non reconstructibles, source de l'import vers NotreCouple Haute jusqu'à la bascule
squash-tm/data-postgres-0 5 GiB Perte de la base, application actuellement à 0 réplica Moyenne
monitoring/prometheus-…-prometheus-0 5 GiB Perte d'historique de métriques, reconstructible Faible
jemimah/jemimah-config-data 100 MiB Contenu à confirmer, application à 0 réplica Faible

Aucun PVC Grafana n'existe : la configuration est provisionnée, pas persistée sur volume. Le volume précédemment désigné « Atelier Jemimah » est en réalité jemimah/jemimah-config-data.

Suite recommandée

  1. Vérifier la conservation et la lisibilité de moncouple-data comme archive après la bascule vers NotreCouple déjà réalisée le 28/08/2026. Ne pas relancer un import sans procédure de réconciliation et validation des données existantes. Le stockage distribué type Longhorn est écarté en l'état : voir ADR 0001 — Stockage persistant HA pour l'inventaire complet, la matrice RPO/RTO et les coûts mesurés sur les trois VPS.
  2. Sauvegarder etcd quotidiennement vers un stockage objet externe.
  3. Exporter les volumes importants avec une rétention hors cluster.
  4. Tester une restauration sur une machine isolée.
  5. Documenter chaque test avec date, durée et résultat.