Sauvegarde et contrôle de restauration¶

Une sauvegarde n'est considérée comme exploitable que si son intégrité est vérifiée et si son dump a été restauré avec succès dans une base isolée.

Les scripts officiels sont :

scripts/backup-create.sh : crée un bundle atomique ;
scripts/backup-verify.sh : vérifie le manifeste, les empreintes et les archives ;
scripts/backup-restore-check.sh : restaure le dump dans une MariaDB éphémère, sans réseau et sans accès à la base de production.

Contenu du bundle¶

Chaque bundle contient :

database.sql.gz : dump transactionnel de la base applicative, créé par WP-CLI avec les identifiants réellement chargés depuis wp-config.php ;
uploads.tar.gz : uploads WordPress, s'ils existent ;
MANIFEST : date UTC, commit déployé, état du dépôt, image MariaDB immuable et empreinte de .env ;
SHA256SUMS : empreintes cryptographiques de tous les fichiers du bundle.

Le fichier .env et les secrets ne sont pas copiés. Ils doivent être sauvegardés séparément dans un gestionnaire de secrets ou un coffre chiffré.

La sauvegarde n'utilise volontairement pas le mot de passe root déclaré dans Compose : modifier une variable d'environnement ne modifie pas un compte déjà enregistré dans MariaDB. WP-CLI charge les mêmes paramètres DB_HOST, DB_NAME, DB_USER et DB_PASSWORD que le WordPress actif, ce qui empêche cette dérive de casser les sauvegardes.

Les métriques Prometheus, les journaux Loki, Redis et runtime-spool sont des données reconstructibles et ne font pas partie du bundle critique.

Stockage¶

CCX_BACKUP_ROOT doit être un chemin absolu dédié, hors du dépôt et sur un stockage chiffré. Les nouveaux répertoires et bundles sont créés avec des permissions privées.

Une copie hors site est obligatoire. Le script crée et vérifie le bundle local ; le transfert, le chiffrement externe, la rétention et l'immuabilité dépendent de l'infrastructure du VPS.

Ne jamais utiliser /, la racine du dépôt ou un répertoire servi par le Web comme destination.

Créer une sauvegarde¶

CCX_BACKUP_ROOT=/mnt/backup/cmonchoix make backup

Le résultat attendu se termine par :

CCX_BACKUP_STATUS=PASS
CCX_BACKUP_BUNDLE=/mnt/backup/cmonchoix/cmonchoix-...

Une sauvegarde d'un dépôt sale est permise pour ne pas bloquer une sauvegarde d'urgence, mais git_dirty=yes est enregistré dans le manifeste et doit déclencher une investigation.

Vérifier le bundle¶

BUNDLE=/mnt/backup/cmonchoix/cmonchoix-... make backup-verify

Résultat attendu :

CCX_BACKUP_VERIFY_STATUS=PASS

Cette étape détecte les fichiers absents, modifiés, tronqués, les archives invalides et les manifestes non conformes. Elle ne suffit pas à prouver que SQL se restaure.

Les empreintes détectent la corruption accidentelle, mais ne prouvent pas l'authenticité face à un attaquant capable de remplacer le bundle et ses empreintes. La copie hors site doit être chiffrée, à accès restreint et, idéalement, immuable.

Effectuer un contrôle réel de restauration¶

BUNDLE=/mnt/backup/cmonchoix/cmonchoix-... make restore-check

Le contrôle :

vérifie le bundle ;
réutilise l'identifiant immuable de l'image MariaDB enregistré au moment de la sauvegarde ;
démarre un conteneur éphémère sans réseau ;
utilise un système de fichiers temporaire et des limites CPU/mémoire ;
force les clients MariaDB sur la boucle locale TCP afin de ne pas dépendre du mode d'authentification du socket Unix ;
restaure SQL ;
exécute mariadb-check et vérifie que des tables existent ;
détruit toujours le conteneur temporaire.

Il ne monte aucun volume de production et ne se connecte jamais à ccx-mariadb.

Les limites peuvent être ajustées pour un gros dump :

CCX_RESTORE_TMPFS_SIZE=4g \
CCX_RESTORE_MEMORY_LIMIT=4g \
CCX_RESTORE_CPU_LIMIT=2 \
BUNDLE=/mnt/backup/cmonchoix/cmonchoix-... \
make restore-check

Fréquence et rétention minimales¶

sauvegarde quotidienne ;
contrôle cryptographique après chaque sauvegarde ;
restauration isolée au moins une fois par semaine et avant toute migration critique ;
rétention quotidienne, hebdomadaire et mensuelle adaptée aux obligations métier ;
test périodique de la copie hors site depuis un hôte distinct.

La fréquence réelle doit être dérivée des objectifs RPO et RTO. Tant que ces objectifs ne sont pas formellement définis, aucune promesse de perte de données maximale ou de délai de reprise ne doit être communiquée.

Restauration de production¶

La restauration de production est une opération destructive. Elle n'est volontairement pas automatisée par ces scripts.

Avant toute restauration :

déclarer et qualifier l'incident ;
figer les écritures ;
créer une sauvegarde de l'état dégradé ;
identifier le bundle et son commit ;
obtenir une validation explicite ;
documenter la procédure SQL et uploads adaptée à l'incident ;
exécuter make doctor après reprise.

Échec¶

Tout statut différent de PASS est bloquant. Ne pas supprimer le bundle en échec : le conserver en quarantaine pour analyse, sans le promouvoir comme sauvegarde restaurable.