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