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 fonctionneront pas (principalement parce que tar et les outils similaires ne font pas une image atomique de l'état du système de fichiers à un moment spécifique). 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 de la base 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. Donc, les sauvegardes du système de fichiers fonctionnent seulement pour les restaurations complètes d'un groupe entier de bases de données.

Une autre approche à la sauvegarde du système de fichiers est de réaliser une << image cohérente >> du répertoire des données si le système de fichiers supporte cette fonctionnalité (et que vous avez confiance en sa bonne implémentation). La procédure typique est de faire une << image gelée >> du volume contenant la base de données, et enfin de copier le répertoire data complètement (pas seulement quelques parties, voir ci-dessus) de l'image sur un périphérique de sauvegarde, puis de libérer l'image gelé. Ceci fonctionnera même si le serveur de la base de données est en cours d'exécution. Néanmoins, une sauvegarde créée de cette façon sauvegarde les fichiers de la base de données dans un état où le serveur n'était pas correctement arrêté ; du coup, au lancement du serveur à partir des données sauvegardées, PostgreSQL pensera que le serveur s'est stoppé brutalement et rejouera les journaux WAL. Ceci n'est pas un problème, soyez-en juste conscient (et assurez-vous d'inclure les fichiers WAL dans votre sauvegarde).

Si votre base de données est répartie sur plusieurs systèmes de fichiers, il pourrait ne pas y avoir de moyens pour obtenir des images gelées exactement simultanément de tous les disques. Par exemple, si vos fichiers de données et vos journaux WAL sont sur des disques différents ou si les tablespaces sont sur des systèmes de fichiers différents, il pourrait ne pas être possible d'utiliser une sauvegarde par image parce que ces dernières doivent être simultanées. Lisez la documentation de votre système de fichiers avec attention avant de faire confiance à la technique d'images cohérentes dans de telles situations. L'approche la plus sûre est d'arrêter le serveur de bases de données assez longtemps pour créer toutes les images gelées.

Une autre option est d'utiliser rsync pour réaliser une sauvegarde du système de fichiers. Ceci se fait tout d'abord en lançant rsync alors que le serveur de bases de données est en cours d'exécution, puis en arrêtant le serveur juste assez longtemps pour lancer rsync une deuxième fois. Le deuxième rsync sera beaucoup plus rapide que le premier car il aura relativement peu de données à transférer et le résultat final sera cohérent parce que le serveur était arrêté. Cette méthode permet de réaliser une sauvegarde du système de fichiers avec un arrêt minimal.

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).