Sauvegardes en production et alerting

Objectifs

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

• industrialiser les sauvegardes (script, cron, rétention, distant) ;
• construire un dashboard de monitoring minimal ;
• écrire des alertes actionnables.

🔗 Pour vous rafraîchir la mémoire : réseaux et volumes Docker · commandes docker de base · manipulation de fichiers (cp, mv, rm) · lecture de fichiers et aide (cat, grep, man)

Le script de sauvegarde complet

#!/bin/bash
# /opt/scripts/backup.sh — cron : 0 3 * * *
set -euo pipefail

DATE=$(date +%F)
DEST=/var/backups/app
REMOTE=backup@stockage.exemple.fr:/backups/monsite

mkdir -p "$DEST/$DATE"

# 1. Base PostgreSQL (cohérence transactionnelle garantie)
docker exec devmind-postgres-1 \
  pg_dump -U cours cours_full_stack | gzip > "$DEST/$DATE/db.sql.gz"

# 2. Volume des uploads
docker run --rm -v course-uploads:/source:ro -v "$DEST/$DATE":/out \
  alpine tar czf /out/uploads.tar.gz -C /source .

# 3. Copie HORS serveur + rotation locale
rsync -a "$DEST/$DATE/" "$REMOTE/$DATE/"
find "$DEST" -maxdepth 1 -mtime +7 -exec rm -rf {} \;

echo "[$(date)] Backup OK → $DATE"

Points de conception à noter : set -euo pipefail (échec = arrêt immédiat), la copie distante AVANT la rotation locale (il reste toujours une copie quelque part), la rétention 7 jours côté serveur seulement (le stockage long terme vit ailleurs).

Vérifier que le cron tourne vraiment

crontab -l                                  # la tâche est-elle là ?
grep CRON /var/log/syslog | tail            # s'exécute-t-elle ?
ls -lt /var/backups/app                     # fichiers récents ? taille plausible ?

La troisième vérification est la plus importante : une sauvegarde de 4 Ko quand la base fait 2 Go est un échec silencieux. Les sauvegardes se surveillent comme un service.

Le dashboard minimum vital

Avec Prometheus + Grafana (aperçu architecture) :

Sources :
  node_exporter   → CPU, RAM, disque du serveur
  postgres_exporter→ connexions, cache hit ratio, requêtes lentes
  votre API       → /metrics exposant erreurs HTTP et latences

Panneaux essentiels :
  1. Disponible ? (sonde externe sur /api/health)
  2. Disque libre (%)              ← la panne n°1 des serveurs web
  3. Taux d'erreurs 5xx par minute
  4. Latence p95 des endpoints

Quatre courbes suffisent pour voir venir 90 % des incidents. L'ordre n'est pas anodin : disque d'abord — c'est ce qui tue les applications lentement puis brutalement (logs non rotatifs, backups accumulés).

Alerte = message qui exige une action

# Règle Prometheus (exemple)
- alert: DisquePresquePlein
  expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) > 0.85
  for: 10m
  annotations:
    summary: "Disque {{ $labels.instance }} à {{ $value | humanizePercentage }}"

Test de qualité d'une alerte : « si je la reçois à 3h du matin, quelle ACTION précise fais-je ? ». Pas d'action claire → pas d'alerte (un tableau de bord suffit). Et chaque alerte déclenchée doit mener à une correction structurelle, sinon elle reviendra.

Et les traces ? (aperçu)

Logs et métriques suffisent tant qu'il y a un serveur. Le jour où une requête traverse plusieurs services, une question devient ardue : « où le temps est-il passé, chez qui l'erreur a-t-elle eu lieu ? » C'est le rôle du tracing distribué : chaque requête porte un identifiant propagé de service en service (vous avez déjà posé la première brique avec le request-id du chapitre 41), et chaque étape enregistre un span (qui, quoi, durée). Un agrégateur reconstruit alors le chemin complet de la requête — OpenTelemetry est le standard émergent, Jaeger un outil de visualisation classique.

Pour l'instant : gardez le réflexe request-id dans vos logs. Le jour où vous avez deux services, vous saurez exactement quoi installer.

Exercice

1. Déployez backup.sh en cron ; simulez un échec pg_dump et vérifiez l'arrêt propre.
2. Écrivez check-backup.sh qui alerte si le dernier backup a plus de 25 h.
3. Listez vos 4 panneaux de dashboard avec leur seuil d'alerte.
4. Pourquoi copier vers le distant AVANT la rotation locale ?

Résumé

• Script idempotent + set -e + cron + surveillance du résultat.
• Dashboard : dispo, disque, erreurs, latence.
• Alerte actionnable ou pas d'alerte.