Sauvegardes et restauration
AvancéUne sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde : c'est une hypothèse.
Sauvegarde logique : pg_dump#
pg_dump -Fc -h localhost -U app ma_base > ma_base.dump # format personnalisé, compressé
pg_restore -h localhost -U app -d ma_base_restauree --clean ma_base.dump
pg_dumpall --globals-only > roles.sql # rôles et tablespaces
Simple, portable entre versions, cohérent (instantané) ; mais lent à restaurer sur de grosses bases et sans point de restauration précis.
Sauvegarde physique et PITR#
Une copie de base (pg_basebackup) combinée à l'archivage continu du WAL permet de restaurer la base à un instant précis (Point-In-Time Recovery) : « juste avant le DELETE accidentel de 14h32 ».
# postgresql.conf (principe)
# archive_mode = on
# archive_command = 'pgbackrest --stanza=prod archive-push %p'
pg_basebackup -h primaire -D /var/lib/postgresql/base -Ft -z -P
Des outils comme pgBackRest et Barman automatisent sauvegardes complètes/incrémentales, archivage, rétention et restauration.
Les objectifs à définir#
| Sigle | Question | Détermine |
|---|---|---|
| RPO (Recovery Point Objective) | Combien de données peut-on perdre ? | Fréquence d'archivage, réplication synchrone |
| RTO (Recovery Time Objective) | En combien de temps doit-on redémarrer ? | Standby prêt, taille de la base, automatisation |
Cas pratique : planifiez un exercice de restauration mensuel sur un serveur vierge, chronométré. Vous découvrirez avant l'incident que le mot de passe du stockage a changé ou que la restauration prend 9 heures au lieu de 1.