Une autre stratégie de sauvegarde consiste à copier les fichiers utilisés par PostgreSQL pour le stockage des données. Dans la Section 18.2, l'emplacement de ces fichiers est précisé. 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, mais aussi à cause du cache disque du serveur). Les
informations concernant la façon d'arrêter le serveur
PostgreSQL se trouvent dans la Section 18.5.
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 restaurer que certaines
tables ou bases de données particulières. Ce n'est
pas utilisable sans les fichiers de validation
pg_xact/* 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_xact 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 sauvegardes et restaurations complètes d'une instance.
Une autre approche à la sauvegarde du système de fichiers consiste à
réaliser une « image cohérente »
(consistent snapshot) du répertoire des
données. Il faut pour cela que le système de fichiers supporte cette
fonctionnalité (et que l'administrateur fasse confiance à cette
technologie). La procédure typique consiste à réaliser une « image
gelée »(frozen snapshot) 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 plus haut) de
l'image sur un périphérique de sauvegarde, puis de libérer l'image gelée.
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 arrêté brutalement et rejouer
les journaux de transactions. Ce n'est pas un problème, mais il faut en
être conscient (et s'assurer d'inclure les journaux de transactions dans
la sauvegarde). Vous pouvez réaliser un CHECKPOINT
avant de prendre la sauvegarde pour réduire le temps de restauration.
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 de transactions se trouvent sur des disques différents, par exemple, ou si les tablespaces sont sur des systèmes de fichiers différents, une sauvegarde par image 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.
S'il n'est pas possible d'obtenir des images simultanées, il est toujours possible d'éteindre le serveur de bases de données suffisamment longtemps pour établir toutes les images gelées. Une autre possibilité est de faire une sauvegarde de la base en archivage continu (Section 25.3.2) parce que ces sauvegardes ne sont pas sensibles aux modifications des fichiers pendant la sauvegarde. Cela n'impose d'activer l'archivage en continu que pendant la période de sauvegarde ; la restauration est faite en utilisant la restauration d'archive en ligne(Section 25.3.5).
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 --checksum une
deuxième fois (--checksum est nécessaire car
rsync n'a une granularité que d'une seconde quand il
teste par horodatage de modification). 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 va être généralement plus volumineuse qu'une sauvegarde SQL. (pg_dump ne sauvegarde pas le contenu des index, mais la commande pour les recréer). Cependant, une sauvegarde des fichiers de données peut être plus rapide.