Sauvegarder et restaurer PostgreSQL : pg_dump, pg_basebackup et PITR

Un DROP TABLE en production, une corruption de disque, un ransomware — sans sauvegarde testée, vous perdez tout. PostgreSQL fournit deux familles d’outils complémentaires : les dumps logiques (pg_dump) pour exporter et restaurer des bases individuelles, et les sauvegardes physiques (pg_basebackup) combinées à l’archivage WAL pour restaurer le cluster entier à un instant précis (PITR — Point-In-Time Recovery).

Ce guide couvre les deux approches de bout en bout, avec chaque commande testée sur un lab réel (PostgreSQL 18.3, Debian 12). Vous saurez quelle méthode choisir, comment la mettre en place, et surtout comment tester que la restauration fonctionne — parce qu’une sauvegarde non testée n’est pas une sauvegarde.

Version utilisée

Ce guide s’appuie sur PostgreSQL 18.3 (Debian 18.3-1.pgdg12+1) sous Debian 12. Les commandes sont stables depuis PostgreSQL 12+, sauf pg_verifybackup (apparu en PostgreSQL 13).

Ce que vous allez apprendre

• Choisir entre sauvegarde logique et physique selon le contexte (volume, RPO, besoin de PITR)
• Réaliser un pg_dump en formats custom, directory et plain, et restaurer avec pg_restore
• Configurer l’archivage WAL continu (archive_mode, archive_command)
• Réaliser une sauvegarde physique avec pg_basebackup et la vérifier avec pg_verifybackup
• Restaurer à un instant précis (PITR) après un DROP TABLE accidentel
• Définir une stratégie de sauvegarde adaptée à votre volume

Dans quel contexte ?

Vous devez mettre en place des sauvegardes PostgreSQL dans ces situations :

• Vous passez une base en production et avez besoin d’un plan de reprise d’activité
• Vous devez pouvoir annuler une erreur humaine (DROP TABLE, UPDATE sans WHERE) en restaurant à l’instant qui précède
• Vous migrez une base d’un serveur à un autre, ou d’une version de PostgreSQL à une autre
• Vous devez dupliquer une base pour créer un environnement de test
• Vous automatisez des sauvegardes quotidiennes dans un cron ou un pipeline CI/CD

Ce guide ne couvre pas…

Réplication Réplication physique et logique pour la haute disponibilité — pg_basebackup y sert de point de départ, pas de sauvegarde

Configuration Régler wal_level, max_wal_size et les paramètres de checkpoint

Sécurisation Protéger les accès et chiffrer les connexions

Prérequis

• PostgreSQL installé et le service actif (voir le guide Installation)
• Accès au rôle superuser (postgres)
• wal_level = replica (valeur par défaut — vérifiez avec SHOW wal_level;)
• Connaître les bases de psql (voir le guide Prise en main de psql)

Les deux familles de sauvegarde

Logique vs physique : le bon outil pour le bon besoin

Critère	Logique (pg_dump)	Physique (pg_basebackup)
Granularité	Une base, un schéma ou une table	Le cluster entier
PITR possible	Non	Oui (avec archivage WAL)
Portabilité	Migration vers des versions plus récentes, archives portables entre architectures (mais pg_dump ne peut pas dumper un serveur plus récent que sa propre version majeure)	Même version majeure uniquement
Vitesse de dump	Lente sur gros volumes (lecture SQL)	Rapide (copie de fichiers)
Vitesse de restauration	Lente (rejeu SQL)	Rapide (copie de fichiers)
Inclut les rôles	Non (sauf pg_dumpall)	Oui (cluster complet)

Glissez pour voir

Règle pratique :

• pg_dump quand vous devez sauvegarder une base précise, migrer entre versions ou créer un dump portable
• pg_basebackup + archivage WAL quand vous avez besoin de PITR, de RPO faible ou de sauvegardes rapides sur de gros volumes

Règle n°1 : pas de PITR sans archivage WAL testé

pg_basebackup seul ne suffit pas pour le PITR. Sans archivage WAL continu, vous ne pouvez restaurer qu’à l’instant exact de la sauvegarde — pas entre deux sauvegardes. Configurez et testez l’archivage avant de considérer votre PITR opérationnel.

Attention : pg_dump et pg_dumpall produisent des sauvegardes logiques — elles ne contiennent pas les WAL nécessaires à l’archivage continu ni au PITR. Seul pg_basebackup + archivage WAL le permet.

Sauvegarde logique avec pg_dump

Les trois formats de dump

pg_dump propose trois formats principaux. Chacun a son usage :

Format	Option	Extension	Compression	Restauration parallèle	Usage principal
Custom	-Fc	.dump	Oui (gzip)	Oui	Le plus courant — flexible, sélectif
Directory	-Fd	dossier/	Oui (gzip)	Oui (natif)	Gros volumes, dump parallèle
Plain	-Fp	.sql	Non (sauf pipe)	Non	Lisible, versionnable, migration cross-version

Glissez pour voir

Dump complet au format custom (-Fc)

Le format recommandé pour les sauvegardes courantes :

sudo -u postgres pg_dump -Fc lab_admin -f /tmp/lab_admin.dump
ls -lh /tmp/lab_admin.dump

-rw-r--r-- 1 postgres postgres 5.8K Apr 13 10:15 /tmp/lab_admin.dump

Le fichier est compressé (gzip intégré) et contient toute la structure + les données. Avec -Fc, vous pourrez ensuite restaurer sélectivement (une table, un schéma) grâce à pg_restore.

Dump au format directory (-Fd)

Utile pour les gros volumes grâce au dump parallèle :

sudo -u postgres pg_dump -Fd lab_admin -f /tmp/lab_admin_dir -j 2

total 16K
-rw-r--r-- 1 postgres postgres  183 Apr 13 10:15 3389.dat.gz
-rw-r--r-- 1 postgres postgres  127 Apr 13 10:15 3391.dat.gz
-rw-r--r-- 1 postgres postgres 5.5K Apr 13 10:15 toc.dat

Chaque table produit un fichier .dat.gz séparé. L’option -j 2 utilise 2 jobs parallèles — adaptez au nombre de CPU disponibles.

Dump au format plain (-Fp)

Produit un script SQL lisible :

sudo -u postgres pg_dump -Fp lab_admin | head -20

--
-- PostgreSQL database dump
--

-- Dumped from database version 18.3 (Debian 18.3-1.pgdg12+1)
-- Dumped by pg_dump version 18.3 (Debian 18.3-1.pgdg12+1)

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET transaction_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

Le format plain est restauré avec psql, pas avec pg_restore. C’est le seul format directement lisible et versionnable dans Git.

Dump sélectif

Pour ne sauvegarder qu’une partie de la base :

# Une seule table
sudo -u postgres pg_dump -Fc lab_admin --table=app.clients -f /tmp/clients_only.dump

# Un schéma entier
sudo -u postgres pg_dump -Fc lab_admin --schema=app -f /tmp/schema_app.dump

# Tout sauf une table
sudo -u postgres pg_dump -Fc lab_admin --exclude-table=app.commandes -f /tmp/sans_commandes.dump

pg_dumpall : rôles et configuration globale

pg_dump ne sauvegarde pas les rôles ni les tablespaces — ils sont globaux au cluster. Pour capturer ces objets :

sudo -u postgres pg_dumpall --globals-only > /tmp/globals.sql

--
-- Roles
--

CREATE ROLE admin_lab;
ALTER ROLE admin_lab WITH NOSUPERUSER INHERIT NOCREATEROLE CREATEDB LOGIN
  NOREPLICATION NOBYPASSRLS PASSWORD 'SCRAM-SHA-256$4096:...';
CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
  REPLICATION BYPASSRLS;

Stratégie complète pour un dump logique

Pour une sauvegarde logique complète d’un cluster, combinez :

1. pg_dumpall --globals-only — rôles et tablespaces
2. pg_dump -Fc <base> — pour chaque base de données

C’est plus flexible qu’un pg_dumpall complet (qui produit un seul fichier plain non sélectif).

Restaurer avec pg_restore

Créez une base cible vide, puis restaurez :

sudo -u postgres psql -c "CREATE DATABASE lab_restore OWNER admin_lab;"
sudo -u postgres pg_restore -d lab_restore --verbose /tmp/lab_admin.dump

pg_restore: connecting to database for restore
pg_restore: creating SCHEMA "app"
pg_restore: creating TABLE "app.clients"
pg_restore: creating SEQUENCE "app.clients_id_seq"
pg_restore: creating TABLE "app.commandes"
pg_restore: creating SEQUENCE "app.commandes_id_seq"
pg_restore: processing data for table "app.clients"
pg_restore: processing data for table "app.commandes"
pg_restore: creating CONSTRAINT "app.clients clients_pkey"
pg_restore: creating CONSTRAINT "app.commandes commandes_pkey"
pg_restore: creating FK CONSTRAINT "app.commandes commandes_client_id_fkey"

Vérification :

SELECT count(*) AS nb_clients FROM app.clients;

 nb_clients
------------
          5

Les 5 clients sont bien restaurés.

pg_restore —list et —use-list : restauration sélective

Le format custom permet de lister le contenu du dump et de ne restaurer qu’une partie :

sudo -u postgres pg_restore --list /tmp/lab_admin.dump

;
; Archive created at 2026-04-13 10:15:32 UTC
;     dbname: lab_admin
;     TOC Entries: 21
;     Compression: gzip
;     Format: CUSTOM
;
; Selected TOC Entries:
;
6; 2615 16390 SCHEMA - app postgres
221; 1259 16392 TABLE app clients postgres
220; 1259 16391 SEQUENCE app clients_id_seq postgres
223; 1259 16407 TABLE app commandes postgres
222; 1259 16406 SEQUENCE app commandes_id_seq postgres
3389; 0 16392 TABLE DATA app clients postgres
3391; 0 16407 TABLE DATA app commandes postgres
3235; 2606 16405 CONSTRAINT app clients clients_email_key postgres
3237; 2606 16403 CONSTRAINT app clients clients_pkey postgres
3239; 2606 16418 CONSTRAINT app commandes commandes_pkey postgres
3240; 2606 16419 FK CONSTRAINT app commandes commandes_client_id_fkey postgres

Pour ne restaurer que les données (pas la structure) :

# Extraire la liste, ne garder que TABLE DATA
sudo -u postgres pg_restore --list /tmp/lab_admin.dump | grep 'TABLE DATA' > /tmp/data_only.list

# Restaurer uniquement ces entrées
sudo -u postgres pg_restore -d lab_restore --use-list=/tmp/data_only.list /tmp/lab_admin.dump

C’est indispensable quand vous devez recharger les données dans une base dont la structure existe déjà.

Sauvegarde physique avec pg_basebackup

Prérequis

Avant de lancer pg_basebackup, vérifiez :

SHOW wal_level;

 wal_level
-----------
 replica

wal_level doit être au moins replica (c’est la valeur par défaut). Si c’est minimal, changez-le et redémarrez — c’est un paramètre postmaster.

Sauvegarde au format plain (-Fp)

La forme la plus courante pour un usage PITR :

sudo -u postgres pg_basebackup \
  -D /var/lib/postgresql/backups/base_backup \
  -Fp -Xs -P -v

pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/4000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_7042"
39450/39450 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/4000120
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup: base backup completed

Option	Rôle
-D	Répertoire de destination (doit être vide ou inexistant)
-Fp	Format plain (copie directe des fichiers — prêt pour PITR)
-Xs	Stream les WAL pendant la sauvegarde (pas besoin d’archivage actif pendant le backup)
-P	Afficher la progression
-v	Mode verbeux

Glissez pour voir

Résultat :

55M     /var/lib/postgresql/backups/base_backup

Sauvegarde au format tar (-Ft) avec compression

Pour un stockage plus compact ou un transfert réseau :

sudo -u postgres pg_basebackup \
  -D /var/lib/postgresql/backups/base_backup_tar \
  -Ft -z -Xs -P -v

total 5.3M
-rw------- 1 postgres postgres 224K Apr 13 10:19 backup_manifest
-rw------- 1 postgres postgres 5.1M Apr 13 10:19 base.tar.gz
-rw------- 1 postgres postgres  17K Apr 13 10:19 pg_wal.tar.gz

L’option -z active la compression gzip. Le résultat passe de 55 Mo (plain) à 5,3 Mo (tar+gzip).

Vérifier l’intégrité avec pg_verifybackup

PostgreSQL inclut un outil de vérification qui compare le manifeste du backup aux fichiers réels :

/usr/lib/postgresql/18/bin/pg_verifybackup /var/lib/postgresql/backups/base_backup

backup successfully verified

Emplacement de pg_verifybackup

Sur Debian/Ubuntu avec les paquets PGDG, pg_verifybackup est dans /usr/lib/postgresql/18/bin/ (pas dans le PATH par défaut). Ajoutez ce répertoire à votre PATH ou utilisez le chemin complet.

pg_verifybackup détecte les fichiers manquants, corrompus ou modifiés depuis le backup. Intégrez-le dans vos scripts de sauvegarde automatisée.

PostgreSQL 18 : vérification des backups tar

Depuis PostgreSQL 18, pg_verifybackup sait vérifier les backups au format tar (y compris compressés). Mais la vérification des WAL reste limitée aux backups au format plain — un backup tar compressé ne bénéficie pas exactement des mêmes contrôles WAL qu’un backup plain.

Archivage WAL continu

Pourquoi archiver les WAL

Les fichiers WAL (Write-Ahead Log) contiennent toutes les modifications apportées aux données. L’archivage WAL copie chaque segment WAL terminé (16 Mo par défaut) vers un emplacement séparé.

Combiné à une sauvegarde physique (pg_basebackup), l’archivage WAL permet :

• PITR : restaurer à n’importe quel instant entre deux sauvegardes
• RPO quasi nul : ne perdre que les transactions en cours au moment du crash
• Rétention longue : conserver des semaines de WAL sans refaire de backup complet

Sans archivage WAL, une sauvegarde physique ne permet de restaurer qu’à l’instant exact du backup — pas entre deux backups.

Configurer archive_mode et archive_command

1. Créer le répertoire d’archivage :

   sudo mkdir -p /var/lib/postgresql/wal_archive
   sudo chown postgres:postgres /var/lib/postgresql/wal_archive

2. Activer l’archivage :

   ALTER SYSTEM SET archive_mode = 'on';
   ALTER SYSTEM SET archive_command = 'test ! -f /var/lib/postgresql/wal_archive/%f && cp %p /var/lib/postgresql/wal_archive/%f';

   %p est le chemin complet du segment WAL source, %f est le nom du fichier. Le test ! -f empêche d’écraser un WAL déjà archivé — c’est la recommandation de la documentation officielle pour éviter les collisions.

3. Redémarrer (archive_mode est un paramètre postmaster) :

   sudo systemctl restart postgresql@18-main

4. Vérifier :

   SHOW archive_mode;
   SHOW archive_command;

    archive_mode
   --------------
    on
   
                         archive_command
   ------------------------------------------------------------------
    test ! -f /var/lib/postgresql/wal_archive/%f && cp %p /var/lib/postgresql/wal_archive/%f

5. Forcer une rotation WAL pour vérifier que l’archivage fonctionne :

   SELECT pg_switch_wal();

   ls -lh /var/lib/postgresql/wal_archive/

   total 16M
   -rw------- 1 postgres postgres 16M Apr 13 10:18 000000010000000000000002

Si le fichier WAL apparaît dans le répertoire d’archivage, tout fonctionne.

6. Vérifier l’état de l’archivage avec pg_stat_archiver :

   SELECT archived_count, failed_count,
          last_archived_wal,
          last_failed_wal,
          last_failed_time
   FROM pg_stat_archiver;

   Si failed_count > 0, inspectez last_failed_wal et last_failed_time pour diagnostiquer le problème.

archive_command doit retourner 0 uniquement en cas de succès

PostgreSQL retentera indéfiniment un archive_command qui échoue (code retour ≠ 0). C’est une sécurité : les WAL ne sont pas supprimés tant qu’ils ne sont pas archivés. Mais si votre commande échoue silencieusement (disque plein, permission refusée), les WAL s’accumulent dans pg_wal/ et le disque se remplit. Surveillez pg_stat_archiver régulièrement pour détecter les échecs.

Lab ≠ production : stockage local

Dans ce guide, l’archive WAL et les base backups restent sur la même machine pour simplifier le lab. En production, l’archive doit partir vers un stockage distinct du serveur source (NFS, S3, autre machine) — sinon une panne disque, un incendie ou un ransomware détruit les données et les sauvegardes.

Politique de rétention des WAL archivés

Les WAL archivés s’accumulent indéfiniment. Définissez une politique de purge :

• RPO cible : si votre dernière sauvegarde physique date de 24h, conservez au minimum 24h de WAL
• Règle pratique : conservez les WAL jusqu’à la deuxième sauvegarde physique la plus récente (pour pouvoir restaurer même si la dernière est corrompue)
• Purge : un cron qui supprime les WAL antérieurs au backup_label de l’avant-dernière sauvegarde

Outils de gestion avancée

Pour une gestion automatisée de la rétention, du parallélisme et de la vérification, des outils comme pgBackRest ou Barman sont plus adaptés que des scripts maison. Ils gèrent la purge, la compression, le chiffrement et la vérification en un seul outil.

Restauration Point-In-Time (PITR)

Le PITR est la capacité de restaurer le cluster à un instant précis passé. C’est le filet de sécurité ultime contre les erreurs humaines.

Le principe

1. Base backup : une sauvegarde physique complète (le point de départ)
2. WAL archivés : toutes les modifications entre le backup et l’instant cible
3. recovery_target_time : l’instant exact où arrêter le rejeu des WAL

PostgreSQL rejoue les WAL depuis le backup jusqu’à l’instant cible, puis s’arrête — avant la transaction destructrice.

Règle importante : le point cible (recovery_target_time) doit être postérieur à la fin du base backup utilisé pour la restauration. On ne peut pas utiliser un backup pour revenir à un instant situé pendant ou avant ce backup.

Démonstration : simuler un DROP TABLE et restaurer

Voici un scénario complet testé sur le lab. La base lab_admin contient 5 clients et 5 commandes. Un backup physique et l’archivage WAL sont déjà en place.

1. Insérer une ligne (qui doit survivre à la restauration) :

   INSERT INTO app.clients (nom, email, ville)
   VALUES ('PITR Test', 'pitr@example.com', 'Nantes');
   
   SELECT count(*) FROM app.clients;

    count
   -------
        6

2. Forcer l’archivage WAL et noter l’instant de référence :

   SELECT pg_switch_wal();
   SELECT now() AS safe_timestamp;

           safe_timestamp
   -------------------------------
    2026-04-13 10:19:49.368402+00

3. Simuler la catastrophe (3 secondes après, pour être sûr que le timestamp est passé) :

   DROP TABLE app.commandes;
   DROP TABLE app.clients;

   Les tables ont disparu. Sans PITR, les données sont perdues.

4. Forcer l’archivage du WAL contenant le DROP :

   SELECT pg_switch_wal();

5. Arrêter PostgreSQL :

   sudo systemctl stop postgresql@18-main

6. Remplacer le data directory par la sauvegarde physique :

   sudo mv /var/lib/postgresql/18/main /var/lib/postgresql/18/main_damaged
   sudo cp -a /var/lib/postgresql/backups/base_backup /var/lib/postgresql/18/main
   sudo chown -R postgres:postgres /var/lib/postgresql/18/main

7. Configurer la restauration dans postgresql.conf :

   restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
   recovery_target_time = '2026-04-13 10:19:49+00'

8. Créer le fichier signal qui indique à PostgreSQL d’entrer en mode recovery :

   sudo -u postgres touch /var/lib/postgresql/18/main/recovery.signal

   Pas de recovery.conf depuis PostgreSQL 12

   Depuis PostgreSQL 12, il n’y a plus de fichier recovery.conf. Les paramètres de restauration (restore_command, recovery_target_time, etc.) se placent directement dans postgresql.conf. Le fichier recovery.signal déclenche le mode recovery au démarrage.

9. Démarrer PostgreSQL :

   sudo systemctl start postgresql@18-main

   Le serveur entre en mode recovery et rejoue les WAL :

   LOG:  completed backup recovery with redo LSN 0/4000028 and end LSN 0/4000120
   LOG:  consistent recovery state reached at 0/4000120
   LOG:  recovery stopping before commit of transaction 798, time 2026-04-13 10:20:03.6119+00
   LOG:  pausing at the end of recovery

   Le serveur s’est arrêté avant la transaction 798 (le DROP TABLE).

10. Reprendre l’activité — le serveur est en pause (recovery_target_action = 'pause' par défaut). Reprenez le rejeu puis laissez la recovery se terminer :

    SELECT pg_wal_replay_resume();

    LOG:  archive recovery complete

    Alternative : promotion automatique

    Si vous préférez éviter l’étape manuelle, ajoutez recovery_target_action = 'promote' dans postgresql.conf à l’étape 7. Le serveur quittera automatiquement le mode recovery une fois le point cible atteint.

11. Vérifier les données :

    SELECT pg_is_in_recovery();

     pg_is_in_recovery
    -------------------
     f

    SELECT nom, email FROM app.clients ORDER BY id;

          nom      |       email
    ---------------+--------------------
     Alice Martin  | alice@example.com
     Bob Dupont    | bob@example.com
     Claire Durand | claire@example.com
     David Moreau  | david@example.com
     Eva Bernard   | eva@example.com
     PITR Test     | pitr@example.com

    6 clients : les 5 d’origine + la ligne insérée avant le DROP. Les tables commandes et clients sont intactes. Le PITR a fonctionné.

Vérifier ses sauvegardes

Une sauvegarde non testée n’est pas une sauvegarde

La vérification doit être automatisée et régulière. Trois niveaux :

Niveau	Méthode	Ce que ça prouve
1. Intégrité	pg_verifybackup (physique)	Les fichiers ne sont pas corrompus
2. Restauration	pg_restore dans une base jetable (logique)	Le dump est lisible et complet
3. Cohérence	Requêtes de contrôle sur la base restaurée	Les données sont exploitables

Glissez pour voir

Vérification automatisée (exemple de script)

#!/bin/bash
set -euo pipefail

DUMP="/var/lib/postgresql/backups/lab_admin_$(date +%Y%m%d).dump"
TEST_DB="verify_$(date +%Y%m%d)"

# Dump
sudo -u postgres pg_dump -Fc lab_admin -f "$DUMP"

# Restaurer dans une base temporaire
sudo -u postgres psql -c "CREATE DATABASE $TEST_DB;"
sudo -u postgres pg_restore -d "$TEST_DB" "$DUMP"

# Vérifier le contenu
COUNT=$(sudo -u postgres psql -tA -d "$TEST_DB" \
  -c "SELECT count(*) FROM app.clients;")

if [ "$COUNT" -gt 0 ]; then
  echo "OK: $COUNT clients restaurés"
else
  echo "ERREUR: base vide après restauration" >&2
  exit 1
fi

# Nettoyage
sudo -u postgres psql -c "DROP DATABASE $TEST_DB;"

Stratégie recommandée selon le volume

Petit volume (< 50 Go)

• pg_dump -Fc quotidien via cron
• Test de restauration hebdomadaire automatisé
• Rétention : 7 dumps glissants + 1 mensuel
• Suffisant pour la plupart des applications métier

Volume moyen (50 Go – 500 Go)

• pg_basebackup hebdomadaire + archivage WAL continu
• pg_dump pour les bases critiques en complément
• Test de PITR mensuel
• RPO : quelques minutes (WAL archivés)
• RTO : temps de copie + rejeu WAL

Gros volume (> 500 Go) ou RPO très faible

• Réplication streaming pour la haute disponibilité
• pgBackRest ou Barman pour la gestion des sauvegardes (parallélisme, compression, chiffrement, rétention automatique, vérification)
• Archivage WAL continu vers stockage distant (S3, NFS)
• Test de restauration automatisé dans la CI

pgBackRest et Barman

Pour les environnements de production exigeants, pgBackRest et Barman remplacent avantageusement les scripts maison. Ils gèrent le parallélisme, la déduplication, la compression, le chiffrement, la rétention, et la vérification. Ce sont les outils de référence dans l’écosystème PostgreSQL.

Dépannage

Symptôme	Cause probable	Solution
pg_dump extrêmement lent	Table volumineuse sans index, ou serveur sous charge	Utiliser -Fd -j N (parallèle) ou planifier en heures creuses
pg_restore échoue avec “relation already exists”	La base cible contient déjà des objets	Ajouter --clean (supprime avant de recréer) ou restaurer dans une base vide
pg_basebackup: could not connect to server	Rôle sans attribut REPLICATION ou pg_hba.conf manquant	Ajouter REPLICATION au rôle et une ligne replication dans pg_hba.conf
WAL archivés s’accumulent dans pg_wal/	archive_command échoue silencieusement	Vérifier pg_stat_archiver : last_failed_wal, last_failed_time
PITR : “could not find WAL file”	Segment WAL manquant dans le répertoire d’archivage	Le segment a été purgé trop tôt — revoir la politique de rétention
PITR : serveur reste en recovery	recovery_target_action vaut pause par défaut	Exécuter SELECT pg_wal_replay_resume(); ou configurer recovery_target_action = 'promote'
pg_verifybackup : “file not found”	Fichier supprimé ou déplacé après le backup	Refaire la sauvegarde — le manifeste ne correspond plus aux fichiers

Glissez pour voir

À retenir

• Deux familles : pg_dump (logique, portable, sélectif) et pg_basebackup (physique, rapide, PITR possible).
• Utilisez -Fc (custom format) pour vos dumps — c’est le format le plus flexible pour la restauration.
• pg_dumpall --globals-only sauvegarde les rôles et tablespaces que pg_dump ignore.
• pg_basebackup seul ne suffit pas pour le PITR — il faut l’archivage WAL continu.
• archive_command doit retourner 0 uniquement quand l’archivage a réellement réussi — PostgreSQL retente indéfiniment sinon.
• Depuis PostgreSQL 12, le PITR se configure dans postgresql.conf + recovery.signal (plus de recovery.conf).
• Après un PITR, le serveur est en pause — exécutez pg_wal_replay_resume() pour terminer la recovery (ou configurez recovery_target_action = 'promote' pour automatiser).
• Le PITR restaure les données, pas vos fichiers de configuration. Pensez à sauvegarder séparément postgresql.conf, pg_hba.conf et pg_ident.conf.
• Testez vos restaurations régulièrement — un backup non testé est un faux sentiment de sécurité.
• Pour les gros volumes, passez à pgBackRest ou Barman plutôt que des scripts maison.

Prochaines étapes

Monitoring et maintenance pg_stat_*, autovacuum avancé, bloat et alertes — surveiller ce que vous venez de sauvegarder

Sécuriser PostgreSQL pg_hba.conf restrictif, TLS, séparation de rôles — protéger les accès avant et après restauration

Réplication Réplication physique et logique, failover automatique — la haute disponibilité en complément du backup

Configurer PostgreSQL wal_level, archive_mode et les paramètres qui impactent les sauvegardes

×

📖 Voir la documentation →