Aller au contenu

Sauvegarde et contrôle de restauration

Une sauvegarde n'est utile que si l'on sait qu'elle est intègre et surtout restaurable. Cette page explique comment protéger CMonChoix sans prendre le risque de toucher accidentellement à la base de production.

À quoi sert cette procédure ?

CMonChoix contient plusieurs types de données : code, base MariaDB, uploads WordPress, secrets et données techniques temporaires.

Le code peut généralement être récupéré depuis Git. Les données métier, elles, ne peuvent pas être recréées aussi facilement si elles sont perdues ou corrompues.

C'est pourquoi une sauvegarde sérieuse suit trois étapes distinctes :

Créer la sauvegarde
        ↓
Vérifier son intégrité
        ↓
Tester sa restauration dans un environnement isolé

Une archive présente sur le disque mais jamais restaurée ne doit pas être considérée comme une garantie de reprise.

Les trois scripts officiels

La plateforme fournit :

  • scripts/backup-create.sh : crée un bundle de sauvegarde cohérent ;
  • scripts/backup-verify.sh : vérifie les fichiers, le manifeste et leurs empreintes ;
  • scripts/backup-restore-check.sh : restaure le dump dans une MariaDB temporaire et isolée.

Ces scripts ont des rôles différents. Aucun ne remplace les autres.

Vocabulaire à connaître

Dump SQL

Un dump SQL est un fichier contenant les instructions nécessaires pour recréer la base de données et ses données.

Dans CMonChoix, il est compressé dans database.sql.gz.

Bundle

Un bundle est le dossier de sauvegarde complet produit par la procédure. Il regroupe le dump SQL, les uploads éventuels, le manifeste et les empreintes de contrôle.

Empreinte SHA-256

Une empreinte cryptographique permet de détecter si un fichier a été modifié ou corrompu depuis sa création.

Elle ne remplace pas une politique de sécurité, mais elle permet de détecter une corruption accidentelle.

Restauration isolée

Une restauration isolée consiste à tester le dump dans une base temporaire qui n'a aucun accès à la base de production.

C'est cette étape qui prouve réellement que le dump peut être relu par MariaDB.

Contenu d'un bundle

Chaque bundle contient :

  • database.sql.gz : dump transactionnel de la base applicative ;
  • uploads.tar.gz : uploads WordPress, s'ils existent ;
  • MANIFEST : informations de contexte sur la sauvegarde ;
  • SHA256SUMS : empreintes cryptographiques des fichiers du bundle.

Le manifeste contient notamment :

  • la date UTC ;
  • le commit déployé ;
  • l'état Git du dépôt ;
  • l'image MariaDB utilisée ;
  • l'empreinte de .env.

Le fichier .env lui-même n'est pas copié dans le bundle, car il contient des secrets.

Ce qui n'est pas sauvegardé dans ce bundle

Certains éléments sont reconstructibles et ne font pas partie du bundle critique :

  • métriques Prometheus ;
  • journaux Loki ;
  • contenu Redis ;
  • runtime-spool.

Les secrets doivent être sauvegardés séparément dans un gestionnaire de secrets ou un coffre chiffré.

Pourquoi le script utilise les identifiants WordPress

La sauvegarde utilise les paramètres de connexion réellement chargés par WordPress :

  • DB_HOST ;
  • DB_NAME ;
  • DB_USER ;
  • DB_PASSWORD.

C'est important car changer une variable root dans Docker Compose ne modifie pas automatiquement un compte MariaDB déjà créé.

En réutilisant les identifiants que WordPress utilise réellement, le script évite qu'une divergence de configuration fasse échouer silencieusement les sauvegardes.

Où stocker les sauvegardes

CCX_BACKUP_ROOT doit pointer vers un chemin absolu dédié, hors du dépôt Git et idéalement sur un stockage chiffré.

Exemple :

/mnt/backup/cmonchoix

Ne jamais utiliser :

  • / ;
  • la racine du dépôt ;
  • un dossier servi par le Web ;
  • un emplacement temporaire non sauvegardé.

Une copie hors site est également nécessaire. Cela signifie qu'au moins une copie doit exister ailleurs que sur le VPS principal.

Pourquoi ? Parce qu'une panne disque, une mauvaise manipulation ou une compromission du serveur peut détruire à la fois la production et les sauvegardes locales.

Étape 1 — créer une sauvegarde

Depuis la racine du dépôt :

CCX_BACKUP_ROOT=/mnt/backup/cmonchoix make backup

Résultat attendu :

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

Le chemin indiqué par CCX_BACKUP_BUNDLE correspond au bundle qui vient d'être créé.

Si le dépôt Git est sale

Une sauvegarde d'urgence n'est pas bloquée si des fichiers locaux ont été modifiés.

Dans ce cas, le manifeste contient :

git_dirty=yes

Cela ne signifie pas que la sauvegarde est inutilisable, mais cet état doit être compris et investigué.

Étape 2 — vérifier l'intégrité

Remplacer le chemin par celui du bundle créé :

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

Résultat attendu :

CCX_BACKUP_VERIFY_STATUS=PASS

Cette vérification détecte notamment :

  • fichiers absents ;
  • fichiers modifiés ;
  • archives tronquées ;
  • archives invalides ;
  • manifeste incorrect.

Attention : un résultat PASS ici ne prouve toujours pas que MariaDB acceptera le dump.

Étape 3 — tester réellement la restauration

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

Cette commande ne restaure pas la production.

Elle :

  1. vérifie le bundle ;
  2. retrouve l'image MariaDB correspondant à la sauvegarde ;
  3. démarre un conteneur MariaDB temporaire ;
  4. l'isole du réseau et de la production ;
  5. restaure le dump SQL ;
  6. lance mariadb-check ;
  7. vérifie que des tables existent ;
  8. détruit le conteneur temporaire à la fin.

Elle ne monte aucun volume de production et ne se connecte pas à ccx-mariadb.

C'est donc la commande à utiliser pour vérifier une capacité de restauration sans toucher aux données actives.

Si le dump est volumineux

Les ressources du conteneur temporaire peuvent être augmentées :

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

Ne modifier ces limites que si le contrôle échoue réellement par manque de ressources.

Fréquence minimale

La politique minimale documentée est :

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

RPO et RTO

Deux notions sont souvent utilisées en reprise d'activité :

  • RPO (Recovery Point Objective) : quantité maximale de données que l'on accepte potentiellement de perdre ;
  • RTO (Recovery Time Objective) : délai maximal souhaité pour remettre le service en fonctionnement.

Tant que ces objectifs ne sont pas formellement définis pour CMonChoix, il ne faut pas promettre un délai précis de reprise ou une perte maximale de données.

Restauration de production : opération sensible

La restauration réelle de la production est destructive. Elle n'est volontairement pas automatisée par ces scripts.

Avant toute restauration de production :

  1. déclarer et qualifier l'incident ;
  2. figer les écritures ;
  3. créer une sauvegarde de l'état dégradé actuel ;
  4. identifier précisément le bundle à restaurer ;
  5. vérifier à quel commit ce bundle correspond ;
  6. obtenir une validation explicite ;
  7. documenter la procédure SQL et uploads adaptée à l'incident ;
  8. effectuer la restauration ;
  9. exécuter make doctor après reprise ;
  10. contrôler fonctionnellement le site.

Pourquoi sauvegarder l'état dégradé ?

Même une base partiellement corrompue peut contenir des informations nécessaires pour comprendre l'incident ou récupérer des données récentes.

Écraser cet état immédiatement ferait perdre ces preuves.

Que faire en cas d'échec

Tout statut différent de PASS est bloquant.

Ne jamais :

  • promouvoir un bundle en échec comme sauvegarde valide ;
  • supprimer immédiatement le bundle défectueux ;
  • ignorer un échec parce qu'une sauvegarde précédente semblait fonctionner ;
  • lancer une restauration de production pour « tester » le dump.

Conserver le bundle en quarantaine pour analyse.

Checklist simple pour le futur mainteneur

Pour vérifier qu'une sauvegarde est réellement exploitable :

[ ] make backup = PASS
[ ] le chemin du bundle est noté
[ ] make backup-verify = PASS
[ ] make restore-check = PASS
[ ] une copie hors site existe
[ ] les secrets sont sauvegardés séparément

Si une de ces étapes manque, la capacité de reprise n'est pas entièrement démontrée.

Voir aussi