Une autre stratégie de sauvegarde consiste à copier les fichiers utilisés par PostgreSQL™ pour le stockage des données. Dans la Section 16.2, « Créer un groupe de base de données », l'emplacement de ces fichiers est précisé mais quiconque s'intéresse à cette méthode les a probablement déjà localisés. N'importe quelle méthode de sauvegarde peut être utilisée, par exemple :
tar -cf sauvegarde.tar /usr/local/pgsql/data
Cependant, deux restrictions rendent cette méthode peu pratique ou en tout cas inférieure à la méthode pg_dump.
Le serveur de base de données doit être arrêté pour obtenir une sauvegarde utilisable. Toutes les demi-mesures, comme la suppression des connexions, ne fonctionnent 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 donné). Les informations concernant la façon d'arrêter le serveur PostgreSQL™ se trouvent dans la Section 16.5, « Arrêter le serveur ».
Le serveur doit également être arrêté avant de restaurer les données.
Quiconque s'est aventuré dans les détails de l'organisation de la base de données peut être tenté de ne sauvegarder et de ne restaurer que certaines tables ou bases de données particulières. Cela ne fonctionne pas parce que les informations contenues dans ces fichiers ne représentent que la moitité de la vérité. 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. Les sauvegardes du système de fichiers fonctionnent, de ce fait, uniquement pour les restaurations complètes d'un cluster de bases de données.
Une autre approche à la sauvegarde du système de fichiers consiste à réaliser une « image cohérente » du répertoire des données. Il faut pour cela que le système de fichiers supporte cette fonctionnalité (et qu'il puisse lui être fait confiance). La procédure typique consiste à réaliser une « image gelée » du volume contenant la base de données et ensuite de copier entièrement le répertoire de données (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 fonctionne même si le serveur de la base de données est en cours d'exécution. Néanmoins, une telle sauvegarde copie les fichiers de la base de données dans un état où le serveur n'est pas correctement arrêté ; du coup, au lancement du serveur à partir des données sauvegardées, PostgreSQL peut penser que le serveur s'est stoppé brutalement et rejouer les journaux WAL. Ceci n'est pas un problème, mais il faut en être conscient (et s'assurer d'inclure les fichiers WAL dans la sauvegarde).
Si la base de données est répartie sur plusieurs systèmes de fichiers, il n'est peut-être pas possible d'obtenir des images gelées exactement simultanées de tous les disques. Si les fichiers de données et les journaux WAL sont sur des disques différents, par exemple, ou si les tablespaces sont sur des systèmes de fichiers différents, une sauvegarde par images n'est probablement pas utilisable parce que ces dernières doivent être simultanées. La documentation du système de fichiers doit être étudiée 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 consiste à 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 est beaucoup plus rapide que le premier car il a relativement peu de données à transférer et le résultat final est cohérent, le serveur étant arrêté. Cette méthode permet de réaliser une sauvegarde du système de fichiers avec un arrêt minimal.
Une sauvegarde des fichiers de données n'est pas forcément moins volumineuse qu'une sauvegarde SQL. Au contraire, elle l'est très certainement plus (pg_dump ne sauvegarde pas le contenu des index, mais la commande pour les recréer).
Sauvegardes et restaurations
