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 tampon interne 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 journaux 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'un cluster de bases de données.
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 qu'il puisse lui être fait
confiance). 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 stoppé brutalement et rejouer les journaux WAL. Ce n'est
pas un problème, mais il faut en être conscient (et s'assurer d'inclure les
fichiers WAL 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 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.
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.4).
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.