22.2. Sauvegarde de niveau système de fichiers

Une autre stratégie de sauvegarde est de copier les fichiers utilisés par PostgreSQL pour enregistrer les données. Dans la Section 16.2, l'emplacement de ces fichiers sont donnés mais vous les avez probablement déjà trouvés si vous vous intéressez à cette méthode. Vous pouvez utiliser n'importe quelle méthode de sauvegarde, par exemple :

tar -cf sauvegarde.tar /usr/local/pgsql/data

Cependant, il y a deux restrictions qui rendent cette méthode inutilisable ou en tout cas inférieure à la méthode pg_dump.

1. Le serveur de base de données doit être arrêté pour obtenir une sauvegarde utilisable. Toutes les demi-mesures, comme supprimer toutes les connections, ne fonctionnent pas, car il y a toujours des données dans des tampons en mémoire. Pour cette raison, il n'est pas conseillé de se reposer sur des systèmes de fichiers qui affirment permettre des << photographies cohérentes (snapshot) >>. Vous trouverez des informations sur la façon d'arrêter le serveur PostgreSQL dans la Section 16.6.

   Il va sans dire que vous devez aussi éteindre le serveur avant de restaurer les données.

2. Si vous vous êtes aventurés dans les détails de l'organisation des fichiers de données, vous pouvez être tentés de ne sauvegarder et de ne restaurer que certaines tables ou bases de données particulières. Ceci ne fonctionnera pas parce que les informations contenues dans ces fichiers ne sont qu'à moitié vraies. L'autre moitié est dans les fichiers journaux de validation pg_clog/*, qui contiennent l'état de la validation de chaque transaction. Un fichier de table n'est utilisable qu'avec cette information. Bien entendu, il est impossible de ne restaurer qu'une table et les données pg_clog associées car cela rendrait toutes les autres tables du serveur inutilisables.

Une autre approche de sauvegarde d'un système de fichiers est de réaliser une << copie cohérente >> du répertoire data, si le système de fichiers dispose de cette fonctionnalité. Une telle copie sauvegardera les fichiers de la base de données dans un état où le serveur n'était pas correctement arrêté ; donc, avant de se retrouver dans un état normal après avoir lancé le serveur sur ce répertoire sauvegardé, le serveur pensera qu'il s'est arrêté brutalement et voudra rejouer les traces WAL. Ceci n'est pas un problème mais vous devez en être conscient.

Notez aussi qu'une sauvegarde des fichiers de données ne sera pas forcément moins grosse qu'une sauvegarde SQL. Au contraire, elle sera très certainement plus grande (pg_dump ne sauvegarde pas le contenu des index, mais la commande pour les recréer).