Sauvegardes PostgreSQL : pg_dump vs WAL archiving

PostgreSQL est l'un des SGBD relationnels open source les plus puissants et robustes du marché, plébiscité pour sa conformité ACID stricte et sa capacité à gérer des charges complexes. Lorsqu'il s'agit de protéger les données d'une application critique sous PostgreSQL, l'administrateur se trouve confronté à un choix stratégique fondamental : opter pour une sauvegarde logique (`pg_dump`) ou mettre en place une stratégie de sauvegarde physique continue avec archivage des journaux de transactions (WAL Archiving).

Ce choix dépend directement de deux indicateurs clés de continuité d'activité : le **RPO** (Recovery Point Objective : combien de données accepte-t-on de perdre en cas de crash ?) et le **RTO** (Recovery Time Objective : combien de temps met-on à rétablir le service ?).

1. pg_dump : la sauvegarde logique simple et portable

L'outil natif `pg_dump` (et son équivalent global `pg_dumpall`) réalise un export logique de la base de données sous forme de requêtes SQL ou d'archives compressées. C'est la méthode idéale pour les bases de petite à moyenne taille, les migrations de serveurs, ou pour cloner une base de production vers un environnement de staging.

• **Avantages :** Fichiers compacts, portabilité parfaite entre différentes versions majeures de PostgreSQL, manipulation aisée. • **Limites :** Ne réalise pas une copie à chaud instantanée (consomme des ressources CPU/RAM lors de l'export), et surtout, offre un RPO limité à la fréquence du dernier dump (si vous sauvegardez une fois par nuit, vous perdez toutes les modifications de la journée en cas de panne à 16h).

# Exemple de sauvegarde logique compressée avec pg_dump
pg_dump -U postgres -h localhost -F c -b -v -f /backups/mydb_$(date +%F).dump mydb

2. WAL Archiving et PITR : l'art de la sauvegarde continue

Pour les applications critiques où la perte de données ne peut excéder quelques secondes, le `pg_dump` ne suffit plus. PostgreSQL consigne chaque modification dans des journaux de transactions appelés **WAL (Write-Ahead Logs)**. En activant l'archivage continu de ces fichiers WAL vers un stockage sécurisé (via des outils comme `pgBackRest` ou `Barman`), vous conservez l'historique absolu de chaque écriture.

Grâce à l'archivage des WAL et au PITR (Point-In-Time Recovery), vous pouvez restaurer votre base de données à la seconde exacte précédant une erreur humaine destructrice.