Sauvegardes et monitoring

Objectifs

À la fin de cette leçon, vous saurez :

• sauvegarder et RESTAURER PostgreSQL (le seul test qui compte) ;
• organiser rotation et stockage externe ;
• surveiller : métriques essentielles et alertes.

🔗 Pour vous rafraîchir la mémoire : commandes docker de base · CRUD en SQL · redirections et pipes

Sauvegarder

# Dump complet compressé
docker exec devmind-postgres-1 \
  pg_dump -U cours cours_full_stack | gzip > backup-2026-08-23.sql.gz

pg_dump produit du SQL rejouable : schéma + données. Combiné au volume des uploads, c'est l'intégralité de l'état de votre application — PostgreSQL ET fichiers se sauvegardent ENSEMBLE (règle du projet).

Restaurer : le test obligatoire

Une sauvegarde jamais restaurée est une hypothèse :

createdb -U cours test_restore
gunzip < backup-2026-08-23.sql.gz | \
  docker exec -i devmind-postgres-1 psql -U cours -d test_restore
psql ... -c "SELECT COUNT(*) FROM lessons;"    # cohérent ?
DROP DATABASE test_restore;

L'exercice canonique du programme : sauvegarder, SUPPRIMER volontairement des données, restaurer, vérifier. Faites-le une fois pour de vrai — c'est ce jour-là que vous découvrez les options manquantes, pas le soir de l'incident.

Rotation et stockage externe

quotidien   → garde 7 jours     (retour arrière court)
hebdomadaire→ garde 4 semaines
mensuel     → garde 12 mois
COPIE HORS SERVEUR (autre machine/cloud) — indispensable :
un backup sur le disque qu'on sauvegarde ne protège de rien.

Script cron + rsync/rclone vers un stockage distant ; chiffrement si le stockage n'est pas à vous.

Monitoring : savoir avant les utilisateurs

Les métriques minimales d'une application web :

DISPONIBILITÉ  : /api/health répond 200 ?      (sonde externe chaque minute)
RESSOURCES     : CPU, RAM, disque du serveur   (node_exporter / htop)
APPLICATION    : taux d'erreurs HTTP, temps de réponse p95
BASE           : connexions actives, taille, requêtes lentes

Deux outils cités par le programme, en aperçu :

Prometheus  → collecte les métriques exposées (/metrics) et les stocke
Grafana     → tableaux de bord + ALERTES (seuil → notification)

Alerte utile = actionnable : « disque > 85 % depuis 10 min » exige une action claire. Alerte inutile = fatigue d'alerte = la vraie panne passera inaperçue.

Exercice

1. Scriptez backup.sh (dump + gzip + copie distante) et planifiez-le en cron.
2. Faites l'exercice complet : dump → suppression de données → restauration → vérification.
3. Ajoutez /api/health à votre API et sondez-la avec curl dans un script minuté.

Résumé

• pg_dump régulier + uploads ensemble ; restauration TESTÉE périodiquement.
• 3 générations de rétention + copie hors serveur.
• Surveiller disponibilité, ressources, erreurs, latence ; alerter actionnable.