PostgreSQL : comment vider et restaurer une base de données avec pg_dump et pg_restore

Pour vider (exporter) une base PostgreSQL, on utilise pg_dump : pg_dump -Fc -f ma_base.dump ma_base produit une sauvegarde compressée et cohérente, même pendant que la base tourne. Pour la restaurer, on crée une base vide puis on lance pg_restore -d ma_base ma_base.dump (ou psql si le dump est au format texte SQL). Les rôles et utilisateurs ne sont pas inclus : il faut les exporter à part avec pg_dumpall –globals-only.

Le cas le plus courant en agence : une application plante en production ou en préproduction, mais pas en local. Le moyen le plus rapide de savoir si la base de données est en cause est de récupérer une copie de la base distante et de la restaurer sur votre machine. Voici la méthode complète, commandes comprises, avec les options qui évitent les erreurs classiques. Les commandes ci-dessous ont été vérifiées sur la documentation de PostgreSQL 18, la version majeure la plus récente au moment de la rédaction (septembre 2026).

• Que veut dire « vider » une base PostgreSQL ?
• Quel format de dump choisir ?
• Comment exporter une base avec pg_dump ?
• Comment rapatrier le fichier sur votre machine ?
• Comment restaurer le dump ?
• Et les utilisateurs, les rôles, les droits ?
• Quelles erreurs éviter ?
• Questions fréquentes
• Sources

Que veut dire « vider » une base PostgreSQL ?

Le mot prête à confusion. Dans le jargon, « vider » une base est souvent la traduction de l’anglais dump : on « déverse » son contenu dans un fichier pour le sauvegarder ou le déplacer. La base d’origine n’est pas modifiée. C’est le sens de cet article.

Si vous cherchez au contraire à supprimer toutes les données d’une base (la remettre à zéro), c’est une autre opération, traitée dans la FAQ en fin d’article. Faites toujours un dump avant de vider une base au sens propre.

PostgreSQL fournit trois outils en ligne de commande pour ce travail :

• pg_dump exporte une seule base. Il produit un export cohérent même si la base est utilisée en même temps, et ne bloque ni les lectures ni les écritures des autres utilisateurs.
• pg_restore restaure un dump réalisé dans un format archive (custom, directory ou tar).
• pg_dumpall exporte tout le serveur (toutes les bases) ainsi que les objets globaux : rôles, tablespaces.

Quel format de dump choisir ?

pg_dump propose quatre formats, choisis avec l’option -F. Le choix conditionne la façon dont vous restaurerez ensuite.

Format	Option	Restauration	Points forts
Texte SQL (par défaut)	-Fp	psql	Lisible et modifiable dans un éditeur, portable
Custom	-Fc	pg_restore	Compressé par défaut, restauration sélective (une table, un schéma)
Directory	-Fd	pg_restore	Compressé, seul format qui permet l’export en parallèle (-j)
Tar	-Ft	pg_restore	Archive standard, sans compression

Notre recommandation par défaut : le format custom (-Fc). Il est compact, il permet de ne restaurer qu’une partie de la base, et pg_restore sait le restaurer en parallèle. Le format texte reste utile quand vous voulez lire ou retoucher le SQL, ou le rejouer sur un serveur où seul psql est disponible. Pour une très grosse base, le format directory permet d’accélérer l’export avec plusieurs connexions simultanées.

Comment exporter une base avec pg_dump ?

Étape 1 : se connecter au serveur

Connectez-vous en SSH au serveur de production ou de préproduction qui héberge la base. Si PostgreSQL n’accepte que l’utilisateur système postgres, préfixez les commandes par sudo -u postgres.

ssh utilisateur@serveur.example.com

Étape 2 : lancer le dump

Au format custom, en datant le fichier pour distinguer plusieurs sauvegardes :

pg_dump -Fc -f ma_base_2026-09-26.dump ma_base

Au format texte SQL, éventuellement compressé à la volée avec gzip :

pg_dump ma_base > ma_base_2026-09-26.sql
pg_dump ma_base | gzip > ma_base_2026-09-26.sql.gz

Pour une base volumineuse, au format directory avec 4 tâches en parallèle (pg_dump ouvre alors 5 connexions, vérifiez que max_connections le permet) :

pg_dump -Fd -j 4 -f ma_base_dir ma_base

Options utiles à connaître

• -h, -p, -U : hôte, port et utilisateur, si la base n’est pas locale ou si vous ne vous connectez pas avec l’utilisateur par défaut.
• -n schema ou -t table : n’exporter qu’un schéma ou qu’une table (options cumulables).
• -O (--no-owner) : ne pas écrire les commandes de propriété. Très pratique quand l’utilisateur local n’a pas le même nom que celui du serveur.
• --clean --if-exists : ajouter des DROP ... IF EXISTS avant chaque création, pour écraser une base existante sans erreurs « n’existe pas ».
• -C (--create) : inclure la création de la base elle-même dans le dump.

Comment rapatrier le fichier sur votre machine ?

Quittez la session SSH et téléchargez le fichier avec scp, qui passe lui aussi par SSH. Si vous n’indiquez pas de chemin local, le fichier arrive dans votre répertoire courant.

scp utilisateur@serveur.example.com:/home/app/backups/ma_base_2026-09-26.dump .

Pour un dossier (format directory), ajoutez -r. Pour les gros fichiers, rsync -avP a l’avantage de reprendre un transfert interrompu.

Autre possibilité : lancer pg_dump directement depuis votre poste en visant le serveur distant avec -h, sans copier de fichier. Cela suppose que le port PostgreSQL soit joignable, ce qui n’est pas souhaitable en production. Un tunnel SSH (ssh -L 5433:localhost:5432 utilisateur@serveur) est alors plus sûr.

Comment restaurer le dump ?

Étape 1 : supprimer l’ancienne base locale (si elle existe)

Attention, cette commande efface définitivement la base locale. Vérifiez deux fois que vous êtes bien sur votre machine et pas sur le serveur.

dropdb --if-exists ma_base

Étape 2 : créer une base vide

La documentation recommande de partir du modèle template0 : les dumps sont relatifs à ce modèle, et partir de template1 personnalisé peut provoquer des conflits.

createdb -T template0 -O mon_utilisateur ma_base

Étape 3 : restaurer

Pour un dump au format custom, directory ou tar, avec pg_restore (ici en 4 tâches parallèles, et sans reprendre les propriétaires d’origine) :

pg_restore -d ma_base -j 4 --no-owner ma_base_2026-09-26.dump

Pour un dump au format texte SQL, avec psql. L’option ON_ERROR_STOP arrête la restauration à la première erreur au lieu de continuer en silence, et --single-transaction annule tout si quelque chose échoue :

psql -X --set ON_ERROR_STOP=on --single-transaction ma_base < ma_base_2026-09-26.sql
gunzip -c ma_base_2026-09-26.sql.gz | psql -X ma_base

Étape 4 : mettre à jour les statistiques

Après une restauration, lancez ANALYZE pour que l’optimiseur de requêtes dispose de statistiques à jour. Sans cela, les premières requêtes peuvent être anormalement lentes, ce qui fausserait votre diagnostic.

psql -d ma_base -c 'ANALYZE;'

Vous disposez maintenant d’une copie de la base distante sur votre machine. Si le bug se reproduit en local, la cause est dans les données ou le schéma ; sinon, cherchez du côté de la configuration du serveur ou du code déployé. Pour aller plus loin sur les lenteurs, voyez notre article sur l’optimisation des performances des bases de données.

Restaurer seulement une table

C’est l’intérêt des formats archive. Listez le contenu du dump, gardez les lignes voulues dans le fichier, puis restaurez uniquement celles-ci :

pg_restore -l ma_base.dump > contenu.txt
# éditez contenu.txt pour ne garder que les éléments voulus
pg_restore -d ma_base -L contenu.txt ma_base.dump

Plus simple pour une seule table : pg_restore -d ma_base -t nom_table ma_base.dump.

Et les utilisateurs, les rôles, les droits ?

C’est le piège le plus fréquent. pg_dump n’exporte ni les rôles (utilisateurs), ni les tablespaces : ce sont des objets globaux au serveur, pas à la base. Or, selon la documentation, tous les utilisateurs qui possèdent des objets ou ont reçu des droits dans la base doivent exister avant la restauration, sinon la propriété et les permissions ne sont pas recréées.

Deux solutions :

1. En local, ignorer les propriétaires : restaurez avec --no-owner (et --no-privileges si besoin). Tous les objets appartiendront à l’utilisateur qui restaure. C’est la solution la plus simple pour du débogage.
2. Pour une migration de serveur, exporter les globaux : pg_dumpall --globals-only > globaux.sql, puis psql -X -f globaux.sql postgres sur le nouveau serveur avant de restaurer les bases. Cette opération demande des droits superutilisateur.

Pour sauvegarder un serveur entier d’un coup, pg_dumpall > serveur_complet.sql produit un seul script SQL, à rejouer avec psql -X -f serveur_complet.sql postgres. pg_dumpall ne produit que du texte SQL : vous perdez la restauration sélective et parallèle.

Quelles erreurs éviter ?

• Restaurer vers une version plus ancienne. Un dump se recharge en général sans problème dans une version plus récente de PostgreSQL. L’inverse n’est pas garanti, même avec le pg_dump de l’ancienne version : il faut parfois retoucher le fichier. Alignez votre version locale sur celle du serveur.
• Utiliser pg_restore sur un dump texte (ou psql sur un dump custom). pg_restore n’accepte que les formats archive. Le message d’erreur est explicite, mais la confusion est fréquente.
• Laisser des données personnelles traîner. Un dump de production contient souvent des noms, e-mails, adresses. Il tombe sous le coup du RGPD : chiffrez-le, supprimez-le après usage et, pour du développement, préférez une base anonymisée.
• Ne jamais tester la restauration. Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde fiable. Programmez un test régulier sur un serveur de préproduction.
• Stocker le dump sur le même serveur que la base. Si le disque ou la machine lâche, vous perdez les deux. Envoyez une copie ailleurs.

pg_dump est parfait pour copier une base, la migrer ou garder des sauvegardes ponctuelles. Pour une base critique où chaque minute de données compte, il faut aussi regarder l’archivage continu des journaux (WAL) et la restauration à un instant donné, décrits dans la documentation officielle. C’est typiquement le genre de dispositif qu’on met en place dans le cadre d’un contrat d’hébergement et de maintenance ou lors du développement d’une application web sur mesure. Si vous hésitez encore sur le moteur de base de données, notre comparatif PostgreSQL vs MySQL peut vous aider.

Questions fréquentes

Comment vider toutes les données d’une base sans la supprimer ?

Pour vider des tables en gardant leur structure : TRUNCATE nom_table RESTART IDENTITY CASCADE; (CASCADE vide aussi les tables liées par clé étrangère, RESTART IDENTITY remet les compteurs à zéro). Pour repartir d’une base totalement vide, le plus propre est dropdb puis createdb. Faites un dump avant.

pg_dump bloque-t-il le site pendant la sauvegarde ?

Non. pg_dump ne bloque ni les lectures ni les écritures des autres utilisateurs, et l’export reste cohérent. En revanche, il consomme des ressources disque et processeur : sur un serveur chargé, lancez-le en heure creuse.

Comment écraser une base existante lors de la restauration ?

Avec pg_restore : pg_restore -d ma_base --clean --if-exists ma_base.dump supprime les objets avant de les recréer. Pour tout recréer y compris la base : pg_restore -C -c -d postgres ma_base.dump.

Mon dump est énorme, comment le découper ?

Utilisez le format custom ou directory, déjà compressés. Pour un dump texte, compressez-le avec gzip ou découpez-le avec split -b 2G, puis reconstituez-le avec cat fichier* | psql ma_base.

Peut-on faire la même chose avec une interface graphique ?

Oui, des outils comme pgAdmin proposent des menus de sauvegarde et de restauration qui appellent pg_dump et pg_restore en arrière-plan. La ligne de commande reste plus fiable pour automatiser et pour les grosses bases.

Sources

• Documentation PostgreSQL : pg_dump
• Documentation PostgreSQL : pg_restore
• Documentation PostgreSQL : pg_dumpall
• Documentation PostgreSQL : SQL Dump (sauvegarde et restauration)
• PostgreSQL : politique de versions et versions supportées