23.2. Sauvegarde de niveau système de fichiers
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
