Guide complet de sauvegarde et restauration des bases de données — pg_dump, mysqldump, mongodump, WAL archiving, PITR, backup stratégies, test de restauration, et automation cron.
Instrucciones de origen · Vista previa de solo lectura
name
sauvegarde-restauration
description
Guide complet de sauvegarde et restauration des bases de données — pg_dump, mysqldump, mongodump, WAL archiving, PITR, backup stratégies, test de restauration, et automation cron.
Compétence Sauvegarde et Restauration des Bases de Données
Vue d'ensemble
Sans sauvegarde testée, vos données n'existent pas. Cette compétence couvre toutes les stratégies de backup (logique, physique, WAL archiving, snapshots), la restauration point-in-time (PITR), l'automatisation, la compression, le chiffrement, et les tests de restauration. L'objectif : pouvoir restaurer n'importe quelle base à n'importe quel point dans le temps avec une procédure documentée.
Quand l'utiliser
Activez cette compétence lorsque l'utilisateur :
Demande de configurer une stratégie de backup pour production
Veut automatiser les sauvegardes avec cron ou borg
Doit restaurer une base après un incident
A besoin de PITR (Point-In-Time Recovery)
Veut sécuriser les backups (chiffrement, stockage distant)
# mongodump standard
mongodump --uri="mongodb://localhost:27017/eva_industrial" \
--out=/backup/mongo/$(date +%Y%m%d)
# Avec compression et archive
mongodump --uri="mongodb://localhost:27017/eva_industrial" \
--gzip --archive=/backup/mongo/eva_industrial_$(date +%Y%m%d).gz
# Avec oplog (PITR pour réplica set)
mongodump --uri="mongodb://192.168.1.10:27017/eva_industrial" \
--oplog --out=/backup/mongo/oplog_$(date +%Y%m%d)
# Copie physique du réplica set (arrêt du secondaire)# 1. Arrêter le secondaire# 2. Copier tout le répertoire dbpath# 3. Redémarrer
# Tous les jours à 2h du matin (full)
0 2 * * * /usr/local/bin/backup_pg.sh > /var/log/backup_pg.log 2>&1
# Toutes les 5 minutes (WAL archiving)
*/5 * * * * /usr/local/bin/archive_wal.sh
8. Test de Restauration (Le plus important)
8.1 Procédure de test mensuelle
#!/bin/bash# /usr/local/bin/test_restore.sh
TEST_DIR="/tmp/test_restore"
LATEST_BACKUP=$(ls -t /backup/pg/eva_prod_*.dump | head -1)
echo"=== Test de restauration - $(date) ==="echo"Backup testé : $LATEST_BACKUP"# Initialiser un cluster vide
initdb -D ${TEST_DIR}/data
# Restaurer le dump
pg_restore -d postgres --clean "$LATEST_BACKUP" -j 4 || {
echo"ÉCHEC : restauration impossible"exit 1
}
# Vérifier l'intégrité
pg_dump -d postgres --schema-only | grep -q "CREATE TABLE" || {
echo"ÉCHEC : aucune table trouvée"exit 1
}
# Vérifier le nombre de lignes
ROW_COUNT=$(psql -d postgres -tAc "SELECT SUM(n_live_tup) FROM pg_stat_user_tables;")
echo"OK : $ROW_COUNT lignes restaurées"# Nettoyerrm -rf ${TEST_DIR}echo"=== Test terminé : SUCCÈS ==="
Pièges Courants
Jamais testé avant le jour J. Un backup jamais restauré n'est pas un backup. Tester au moins une fois par mois.
Chiffrement sans test de déchiffrement. Après un crash, la clé GPG perdue = données perdues. Stocker la clé de déchiffrement séparément du backup.
Rotation trop agressive. Garder au minimum : 7 full backups quotidiens, 4 hebdomadaires, 12 mensuels. Les corruptions peuvent mettre des semaines à être détectées.
Pas de backup du WAL. Sans WAL, la restauration PITR est impossible. Vérifier que archive_command fonctionne avec pg_switch_wal().
Backup sur le même disque que la base. Un crash disque tue les deux. Toujours stocker les backups sur un filesystem ou un hôte différent.
Oublier les backups logiques pour les migrations. Les dumps physiques ne sont pas portables entre versions majeures de PostgreSQL. Toujours avoir un dump logique pour les migrations.
