Playbook Backup

Statut	Actif — v1.0 — 2026-06-27
Priorité	P0
Obligatoire V1	Oui
Responsable	Sylvain
Voir aussi	Playbook Monitoring · Backup détaillé · Playbook Release

info

Ce playbook décrit les principes et procédures. La documentation technique détaillée (scripts, formats, chemins) est dans DevOps → Backup.

Principe directeur

La restauration est plus importante que la sauvegarde.

Une sauvegarde non testée n'existe pas. Planifier des restaurations de test aussi rigoureusement que les sauvegardes elles-mêmes.

Que sauvegarde-t-on ?

Élément	Méthode	Fréquence
Base PostgreSQL (schéma + données)	pg_dump format custom	Quotidienne
Politiques RLS	Incluses dans le dump	Quotidienne
Triggers, fonctions, extensions	Incluses dans le dump	Quotidienne
Code source	Git (GitHub)	À chaque push
Edge Functions	Git (GitHub)	À chaque push

Ce qui n'est pas sauvegardé automatiquement

Élément	Action requise
Storage Supabase (logos, bannières, PDFs)	Sync manuel via CLI Supabase si nécessaire
Configuration projet Supabase (Auth, SMTP)	Snapshot manuel via dashboard
Rôles globaux PostgreSQL	Gérés par Supabase, non exportables

Fréquence et rétention

Type	Fréquence	Rétention
Backup automatique	Quotidien (nuit)	7 jours glissants
Backup avant release majeure	Manuel	Conservé 30 jours
Backup mensuel (archivage)	1er du mois	12 mois

Où sont stockées les sauvegardes ?

Deux emplacements distincts pour la résilience :

1. VPS local — dossier dédié sur le serveur (/srv/dmv/backups/)
2. Stockage distant — bucket Object Storage ou équivalent hors VPS

Une sauvegarde uniquement locale n'est pas suffisante : la perte du VPS entraînerait la perte des sauvegardes.

Vérification d'intégrité

Chaque sauvegarde est vérifiée immédiatement après sa création :

# Vérification pg_dump custom
pg_restore --list backup.dump > /dev/null && echo "OK" || echo "CORROMPU"

# Vérification checksum
sha256sum backup.dump > backup.dump.sha256
sha256sum -c backup.dump.sha256

Une alerte est envoyée si la vérification échoue.

Procédure de restauration

Restauration complète (sinistre)

# 1. Identifier la sauvegarde à restaurer
ls -lh /srv/dmv/backups/

# 2. Vérifier l'intégrité
sha256sum -c backup_YYYY-MM-DD.dump.sha256

# 3. Restaurer sur une base vide
pg_restore \
  --host=$DB_HOST \
  --port=$DB_PORT \
  --username=$DB_USER \
  --dbname=$DB_NAME \
  --verbose \
  backup_YYYY-MM-DD.dump

# 4. Vérifier les données restaurées
psql -c "SELECT COUNT(*) FROM users;"
psql -c "SELECT COUNT(*) FROM acteurs;"

# 5. Relancer l'API et vérifier le health check

Restauration partielle (données supprimées accidentellement)

1. Restaurer dans une base temporaire (dmv_restore)
2. Extraire les données manquantes via SQL
3. Insérer manuellement dans la production
4. Vérifier la cohérence

Rollback après migration cassée

Si php artisan migrate --force casse des données :

1. Activer le mode maintenance (php artisan down)
2. Restaurer la sauvegarde pré-release (voir Release Checklist)
3. Revenir au commit précédent (git checkout <sha>)
4. Désactiver la maintenance (php artisan up)

Test de restauration

Fréquence recommandée : mensuelle.

Protocole minimal :

# 1. Restaurer le backup J-1 dans dmv_test_restore
pg_restore --dbname=dmv_test_restore backup_hier.dump

# 2. Vérifier les tables critiques
psql dmv_test_restore -c "SELECT COUNT(*) FROM users, acteurs, publications;"

# 3. Consigner le résultat
echo "$(date) — Restauration testée OK — N utilisateurs" >> /srv/dmv/restore-tests.log

Un test de restauration non documenté n'est pas un test.

Alertes backup

• Si le cron de backup ne produit pas de fichier dans les 25 heures : alerte immédiate
• Si la vérification d'intégrité échoue : alerte immédiate + tentative de backup manuel
• Si l'espace disque réservé aux backups dépasse 80 % : alerte

Checklist backup en cas de doute

• Le backup d'hier est présent et son checksum est valide
• Le backup existe en deux emplacements distincts
• Le dernier test de restauration date de moins de 30 jours
• L'alerte d'intégrité est configurée