Comment sauvegarder et récupérer PostgreSQL ?

Question

Accepted Answer

PostgreSQL offre plusieurs méthodes de **sauvegarde** — les sauvegardes logiques (`pg_dump`) et les sauvegardes physiques (sauvegarde de base + WAL pour la **récupération à un point dans le temps**). Une stratégie solide de sauvegarde et de récupération est essentielle pour se protéger contre la perte de données, et de façon cruciale, **les sauvegardes doivent être testées**.

## Sauvegardes logiques — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` crée une sauvegarde logique (SQL ou archive) d'une base de données — portative (restaurable sur différentes versions/serveurs), bonne pour les bases de données plus petites, les migrations et les sauvegardes sélectives. Cependant, c'est un instantané à un point dans le temps (pas de récupération continue).

## Sauvegardes physiques + Récupération à un point dans le temps (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

La **PITR** est puissante : en archivant en continu les WAL, vous pouvez récupérer à n'importe quel moment — pas seulement la dernière sauvegarde — ce qui est essentiel pour minimiser la perte de données en cas de sinistre.

## Éléments essentiels de la stratégie de sauvegarde

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## La règle la plus importante : TESTEZ vos sauvegardes

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Pourquoi c'est important

La sauvegarde et la récupération sont des connaissances **critiques** pour exploiter PostgreSQL de façon responsable — la protection contre la perte de données (due à une défaillance matérielle, une corruption, une suppression accidentelle, des sinistres) est l'une des responsabilités les plus importantes pour toute base de données en production, donc comprendre les stratégies de sauvegarde est une connaissance essentielle de niveau senior.

Comprendre les méthodes est nécessaire : **`pg_dump`** (sauvegardes logiques — dumps SQL/archive portables, bons pour les petites bases de données, les migrations et les sauvegardes sélectives/multi-versions, mais uniquement des instantanés à un point dans le temps) et **les sauvegardes physiques avec Récupération à un point dans le temps (PITR)** (sauvegarde de base + archivage continu des WAL, permettant la récupération à *n'importe quel* moment — ce qui est puissant pour minimiser la perte de données, par exemple récupérer juste avant un `DROP TABLE` accidentel, essentiel pour les données critiques).

Connaître les **éléments essentiels de la stratégie** (sauvegardes régulières automatisées, stockage hors serveur et hors site, politiques de rétention, combinaison des sauvegardes de base avec les WAL pour la PITR sur les données critiques, sauvegarde à partir des répliques) est une connaissance opérationnelle importante.

De façon plus critique, comprendre que **les sauvegardes doivent être testées** — une sauvegarde non testée n'est pas fiable et échoue souvent exactement quand elle est nécessaire (corruption, données incomplètes, processus de restauration non familier) — est un principe vital, souvent négligé : tester régulièrement les restaurations est ce qui rend une stratégie de sauvegarde réellement digne de confiance.

Puisque la perte de données peut être catastrophique (et la récupération n'est possible qu'avec des sauvegardes fonctionnelles), et puisqu'une stratégie appropriée (méthodes de sauvegarde appropriées, PITR pour une perte minimale, stockage hors site, et de façon cruciale des restaurations *testées*) est ce qui protège les données d'une organisation, comprendre la sauvegarde et la récupération PostgreSQL est une connaissance critique de niveau senior pour l'exploitation responsable des bases de données — une responsabilité à fort enjeu où la différence entre une stratégie testée et une stratégie non testée peut être la différence entre récupérer d'un sinistre et perdre des données de façon permanente, ce qui en fait un sujet essentiel et fréquemment pertinent pour quiconque exploite des bases de données en production.