Comme avec tout ce qui contient des données importantes, les bases de données PostgreSQL™ doivent être sauvegardées régulièrement. Bien que la procédure soit plutôt simple, il est important de comprendre les techniques sous-jacentes ainsi que les hypothèses prises.
Il y a trois approches fondamentalement différentes pour sauvegarder les données de PostgreSQL™ :
La sauvegarde SQL ;
La sauvegarde de niveau système de fichiers ;
La sauvegarde à chaud (ou en ligne).
Chacune a ses avantages et inconvénients.
Le principe est de générer un fichier texte de commandes SQL (appelé « fichier dump »), qui, si on le renvoie au serveur, recrée une base de données identique à celle sauvegardée. PostgreSQL™ propose pour cela le programme utilitaire pg_dump(1). L'usage basique est :
pg_dump base_de_donnees > fichier_de_sortie
Comme vous le voyez, pg_dump écrit son résultat sur la sortie standard. Nous verrons plus loin que cela peut être pratique.
pg_dump est un programme client PostgreSQL™ classique (mais plutôt intelligent). Ceci veut dire que vous pouvez faire une sauvegarde depuis n'importe quel ordinateur ayant accès à la base. Mais rappelez-vous que pg_dump n'a pas de droits spéciaux. En particulier, il doit avoir accès en lecture à toutes les tables que vous voulez sauvegarder, si bien qu'il doit être lancé pratiquement toujours en tant que super-utilisateur de la base.
Pour préciser quel serveur de bases de données pg_dump doit contacter, utilisez les options de ligne de commande -h serveur et -p port. Le serveur par défaut est le serveur local ou celui indiqué par la variable d'environnement PGHOST. De la même façon, le port par défaut est indiqué par la variable d'environnement PGPORT ou, en son absence, par la valeur par défaut précisée à la compilation. Heureusement, le serveur et le client possèdent généralement la même valeur de compilation par défaut.
Comme tout programme client PostgreSQL™, pg_dump se connecte par défaut avec l'utilisateur de base de données de même nom que l'utilisateur système courant. Pour passer outre, précisez l'option -U ou donnez une valeur à la variable d'environnement PGUSER. Rappelez-vous que les connexions de pg_dump sont soumises aux mécanismes normaux d'authentification des programmes clients (qui sont décrits dans le Chapitre 20, Authentification du client).
Les sauvegardes créées par pg_dump sont cohérentes, ce qui veut dire que les modifications effectuées alors que pg_dump est en cours de fonctionnement ne sont pas dans le fichier de résultat. pg_dump ne bloque pas les autres opérations sur la base lorsqu'il fonctionne (sauf celles qui ont besoin d'un verrou exclusif, comme VACUUM FULL.)
![[Important]](images/important.png)
Lorsque votre base de données dépend des OID (par exemple en tant que clés étrangères), vous devez indiquer à pg_dump de sauvegarder aussi les OID. Pour cela, utilisez l'option -o sur la ligne de commande.
Les fichiers texte créés par pg_dump sont prévus pour être lus par le programme psql. La syntaxe générale d'une commande de restauration est
psql base_de_donnees < fichier_d_entree
où fichier_d_entree est ce que vous avez précisé comme fichier_de_sortie à la commande pg_dump. La base de données base_de_donnees n'est pas créée par cette commande. Vous devez la créer vous-même à partir de template0 avant d'exécuter psql (par exemple avec createdb -T template0 base_de_donnees). psql propose des options similaires à celles de pg_dump pour contrôler l'emplacement du serveur de bases de données et le nom d'utilisateur. Voyez la page de référence de psql(1) pour plus d'informations.
La base de données cible doit déjà exister avant de lancer la restauration, ainsi que les utilisateurs possédant les objets dans la base de données sauvegardée ou ayant des droits sur ces objets. S'ils n'existent pas, la restauration échouera pour la création des objets dont ils sont propriétaires ou pour lesquels ils ont des droits (quelque fois, cela correspond à ce que vous souhaitez mais ce n'est pas le cas habituellement).
Une fois restauré, il est recommandé de lancer ANALYZE sur chacune des bases de données afin que l'optimiseur de requêtes dispose de statistiques utiles. Une façon aisée de le faire est de lancer la commande vacuumdb -a -z pour lancer ANALYZE sur toutes les bases de données ; ceci est équivalent à lancer VACUUM ANALYZE manuellement.
La capacité de pg_dump et psql à écrire et à lire dans des tubes permet de sauvegarder une base de données directement d'un serveur sur un autre. Par exemple :
pg_dump -h serveur1 base_de_donnees | psql -h serveur2 base_de_donnees
Les fichiers de sauvegarde produits par pg_dump sont relatifs à template0. Cela signifie que chaque langage, procédure, etc. ajoutés à template1 seront aussi sauvegardés par pg_dump. En conséquence, si vous utilisez une base template1 modifiée, vous devez créer la base vide à partir de template0, comme dans l'exemple précédent.
Pour des conseils sur le chargement efficace de grosses quantités de données dans PostgreSQL™, référez-vous à la Section 13.4, « Remplir une base de données ».
Le mécanisme précédent est peu pratique pour sauvegarder un serveur de bases de données complet. pg_dumpall(1) est prévu pour cela. pg_dumpall sauvegarde toutes les bases de données d'un groupe de bases de données PostgreSQL™ (appelé cluster) et préserve les données communes au groupe de bases comme les utilisateurs et les groupes. L'utilisation basique de cette commande est :
pg_dumpall > fichier_de_sortie
Le fichier de sauvegarde résultant peut être restauré avec psql :
psql -f fichier_d_entree postgres
(Vous pouvez utiliser n'importe quelle base de données pour vous connecter mais si vous êtes en train de recharger un serveur vide, postgres devrait habituellement être utilisée.) Il faut obligatoirement être le super-utilisateur de la base pour restaurer une sauvegarde faite avec pg_dumpall, pour pouvoir restaurer les informations sur les utilisateurs et les groupes.
Comme PostgreSQL™ permet que des tables soient plus grandes que la taille maximale d'un fichier sur votre système de fichiers, sauvegarder une telle table en fichier peut poser des problèmes. Comme pg_dump peut écrire sur la sortie standard, vous pouvez utiliser des outils standard d'Unix pour contourner ce problème éventuel.
Compresser le fichier de sauvegarde. Vous pouvez utiliser votre programme de compression habituel. Par exemple gzip.
pg_dump base_de_donnees | gzip > nom_fichier.gz
Pour restaurer :
createdb base_de_donnees gunzip -c nom_fichier.gz | psql base_de_donnees
ou
cat nom_fichier.gz | gunzip | psql base_de_donnees
Couper le fichier avec split. La commande split vous permet de découper le fichier en morceaux d'une taille acceptable pour le système de fichiers sous-jacent. Par exemple, pour faire des morceaux de 1 Mo :
pg_dump base_de_donnees | split -b 1m - nom_fichier
Pour restaurer :
createdb base_de_donnees cat nom_fichier* | psql base_de_donnees
Utilisation du format de sauvegarde spécial. Si PostgreSQL™ est installé sur un système où la bibliothèque de compression zlib est disponible, ce format de sauvegarde spécial peut être utilisé. Pour les grandes bases de données, cela produira un fichier de sauvegarde d'une taille comparable à celle de gzip, avec l'avantage supplémentaire de permettre de restaurer des tables sélectivement. La commande qui suit sauvegarde une base de données en utilisant le format de sauvegarde spécial :
pg_dump -Fc base_de_donnees > nom_fichier
Un format personnalisé de la sauvegarde n'est pas un script pour psql mais doit, à la place, être restauré avec pg_restore. Voir les pages de référence de pg_dump(1) et pg_restore(1) pour quelques détails.
Maintenance du fichier
de traces