root/traduc/branches/bv747/manuel/backup.sgml

<!--
$Header: /var/lib/cvs/pgsql-fr/sgml/backup.sgml,v 1.7.2.1 2005/03/20 22:34:39 guillaume Exp $
-->
<chapter id="backup">
 <title>Sauvegardes et restaurations</title>

 <indexterm zone="backup"><primary>backup</></>

 <para>
  Comme tout ce qui contient des données importantes, les bases de données 
  <productname>PostgreSQL</> doivent être sauvegardées régulièrement.
  Bien que la procédure soit plutôt simple, il est important de comprendre les
  techniques et les suppositions sous-jacentes à celle-ci.
 </para>

 <para>
  Il y a deux approches fondamentalement différentes pour sauvegarder les 
  données de <productname>PostgreSQL</>&nbsp;:
  <itemizedlist>
   <listitem><para><acronym>Sauvegarde SQL&nbsp;;</></para></listitem>
   <listitem><para>Sauvegarde de niveau système de fichiers.</para></listitem>
  </itemizedlist>
 </para>

 <sect1 id="backup-dump">
  <title>Sauvegarde <acronym>SQL</></title>

  <para>
   Le principe est de générer un fichier texte de commandes SQL (appelé 
   <quote>fichier dump</quote>), qui, si on le renvoie au serveur, recrée une
   base de données identique à celle sauvegardée.
   <productname>PostgreSQL</> propose pour cela le programme utilitaire
   <application>pg_dump</>. L'usage basique est&nbsp;:
<synopsis>
pg_dump <replaceable class="parameter">base_de_donnees</replaceable> &gt; <replaceable class="parameter">fichier_de_sortie</replaceable>
</synopsis>
   Comme vous le voyez, <application>pg_dump</> écrit son résultat sur la sortie standard.
   Nous verrons plus loin que cela peut être pratique.
  </para>

  <para>
   <application>pg_dump</> est un programme client <productname>PostgreSQL</>
   classique (mais plutôt intelligent). Ceci veut dire que vous pouvez 
   faire une sauvegarde depuis n'importe quel ordinateur ayant accès à la base.
   Mais rappelez-vous que <application>pg_dump</> n'a pas de droits spéciaux.
   En particulier, vous devez avoir accès en lecture à toutes les tables que 
   vous voulez sauvegarder, si bien qu'en pratique vous devez pratiquement 
   toujours être le super-utilisateur de la base.
  </para>

  <para>
   Pour préciser quel serveur de bases de données <application>pg_dump</> doit
   contacter, utilisez les options de ligne de commande <option>-h
   <replaceable>serveur</></> et <option>-p <replaceable>port</></>.
   Le serveur par défaut est le serveur local, ou bien celui spécifié par la 
   variable d'environnement <envar>PGHOST</envar>.
   De la même façon, le port par défaut est indiqué par la variable d'environnement
   <envar>PGPORT</envar> ou, en son absence, par la valeur par défaut précisée 
   à la compilation. Heureusement, la serveur a normalement la même valeur par
   défaut à la compilation.
  </para>

  <para>
   Comme tout programme client <productname>PostgreSQL</>, <application>pg_dump</>
   se connecte par défaut avec l'utilisateur de base de données de même nom que 
   l'utilisateur système courant. Pour passer outre, précisez l'option 
   <option>-U</option> ou donnez une valeur à la variable d'environnement
   <envar>PGUSER</envar>. Rappelez-vous que les connexions de
   <application>pg_dump</> sont soumises aux mécanismes normaux
   d'authentification des programmes clients (qui sont décrits dans le <xref
   linkend="client-authentication">).
  </para>

  <para>
   Les sauvegardes créées par <application>pg_dump</> sont cohérentes, ce
   qui veut dire que les modifications effectuées alors que <application>pg_dump</>
   est en cours de fonctionnement ne sont pas dans le fichier de résultat.
   <application>pg_dump</> ne bloque pas les autres opérations sur la base 
   lorsqu'il fonctionne (sauf celles qui ont besoin d'un verrou exclusif, comme 
   <command>VACUUM FULL</command>.)
  </para>

  <important>
   <para>
    Lorsque votre base de données dépend des OID (par exemple en tant que clés 
    étrangères), vous devez indiquer à <application>pg_dump</> de sauvegarder
    aussi les OID. Pour cela, utilisez l'option <option>-o</option> sur la ligne
    de commande.
    Les <quote>gros objets</> ne sont pas non plus sauvegardés par défaut. 
    Consultez la page de référence de la commande <application>pg_dump</> si vous 
    utilisez les <quote>gros objets</>.
   </para>
  </important>

  <sect2 id="backup-dump-restore">
   <title>Restaurer la sauvegarde</title>

   <para>
    Les fichiers texte créés par <application>pg_dump</> sont prévus pour être 
    lus par le programme <application>psql</application>. La syntaxe générale 
    d'une commande de restauration est
<synopsis>
psql <replaceable class="parameter">base_de_donnees</replaceable> &lt; <replaceable class="parameter">fichier_d_entree</replaceable>
</synopsis>
    où <replaceable class="parameter">fichier_d_entree</replaceable> est ce que 
    vous avez précisé comme <replaceable class="parameter">fichier_de_sortie</replaceable>
    à la commande <command>pg_dump</>. La base de données 
    <replaceable class="parameter">base_de_donnees</replaceable> n'est pas créée par cette 
    commande. Vous devez la créer vous-même à partir de <literal>template0</>
    avant d'exécuter <application>psql</> (par exemple avec <literal>createdb -T
    template0 <replaceable class="parameter">base_de_donnees</></literal>).
    <application>psql</> propose des options similaires à celles de
    <application>pg_dump</> pour contrôler l'emplacement du serveur de bases de
    données et le nom d'utilisateur. Voyez sa page de référence pour plus
    d'informations.
    </para>

   <para>
    Si les objets de la base de données originale appartenaient à plusieurs 
    utilisateurs, alors le fichier de sauvegarde ordonne à <application>psql</>
    de se connecter comme chacun de ces utilisateurs tour à tour et crée  
    les objets correspondants. 
    Ainsi, le propriétaire initial est maintenu. Cela signifie 
    aussi, cependant, que tous ces utilisateurs doivent déjà exister et que 
    vous devez avoir le droit de vous connecter comme chacun d'entre eux.
    Il peut être nécessaire pour cela de relâcher temporairement les règles 
    d'identification des clients.
   </para>

   <para>
    Il est recommandé de lancer <command>ANALYZE</> sur 
    chacune des bases de données restaurées, afin que l'optimiseur de requêtes 
    dispose de statistiques utiles. Vous pouvez aussi lancer la commande 
    <command>vacuumdb -a -z</> pour lancer <command>ANALYZE</> sur toutes les 
    bases de données.
   </para>

   <para>
    La capacité de <application>pg_dump</> et <application>psql</> à écrire
    et à lire dans des tubes permet de sauvegarder une base de données 
    directement d'un serveur sur un autre. Par exemple&nbsp;:
<programlisting>
pg_dump -h <replaceable>serveur1</> <replaceable>base_de_donnees</> | psql -h <replaceable>serveur2</> <replaceable>base_de_donnees</>
</programlisting>
   </para>

   <important>
    <para>
     Les fichiers de sauvegarde produits par <application>pg_dump</> sont
     relatifs à <literal>template0</>. Cela signifie que chaque langage,
     procédure, etc. ajoutés à <literal>template1</> seront aussi sauvegardés
     par <application>pg_dump</>. En conséquence, si vous utilisez une base
     <literal>template1</> modifiée, vous devez créer la base vide à partir de
     <literal>template0</>, comme dans l'exemple précédent.
    </para>
   </important>

   <tip>
    <para>
    La vitesse de restauration peut être améliorée en augmentant le paramètre
    <varname>sort_mem</varname> (voir la <xref
    linkend="runtime-config-resource-memory">).
    </para>
   </tip>

  </sect2>

  <sect2 id="backup-dump-all">
   <title>Utilisation de <command>pg_dumpall</></title>

   <para>
    Le mécanisme précédent est peu pratique pour sauvegarder un serveur de bases
    de données complet. <application>pg_dumpall</> est prévu pour cela.
    <application>pg_dumpall</> sauvegarde toutes les bases de données d'un groupe 
    de bases de données <productname>PostgreSQL</> (appelé cluster) et préserve
    les données communes au groupe de bases comme les utilisateurs et les 
    groupes. La syntaxe d'appel est simplement
<synopsis>
pg_dumpall &gt; <replaceable>fichier_de_sortie</>
</synopsis>
    Le fichier de sauvegarde résultant peut être restauré avec <application>psql</>&nbsp;:
<synopsis>
psql template1 &lt; <replaceable class="parameter">fichier_d_entree</replaceable>
</synopsis>
    (Vous pouvez utiliser n'importe quelle base de données pour vous 
    connecter mais si vous êtes en train de recharger un serveur vide, 
    <literal>template1</> est la seule base de données disponible.)
    Il faut obligatoirement être le super-utilisateur de la base pour restaurer
    une sauvegarde faite avec <application>pg_dumpall</>, pour pouvoir restaurer
    les informations sur les utilisateurs et les groupes.
   </para>
  </sect2>

  <sect2 id="backup-dump-large">
   <title>Grosses bases de données</title>

   <para>
    Comme <productname>PostgreSQL</productname> permet que des tables soient plus
    grandes que la taille maximale d'un fichier sur votre système de fichiers,
    sauvegarder une telle table en fichier peut poser des problèmes. 
    Comme <application>pg_dump</> peut écrire sur la sortie standard, vous pouvez
    utiliser des outils standard d'Unix pour contourner ce problème éventuel.
   </para>

   <formalpara>
    <title>Compresser le fichier de sauvegarde</title>
    <para>
     Vous pouvez utiliser votre programme de compression habituel. Par exemple
     <application>gzip</application>.

<programlisting>
pg_dump <replaceable class="parameter">base_de_donnees</replaceable> | gzip &gt; <replaceable class="parameter">nom_fichier</replaceable>.gz
</programlisting>

     Pour restaurer&nbsp;:

<programlisting>
createdb <replaceable class="parameter">base_de_donnees</replaceable>
gunzip -c <replaceable class="parameter">nom_fichier</replaceable>.gz | psql <replaceable class="parameter">base_de_donnees</replaceable>
</programlisting>

     ou

<programlisting>
cat <replaceable class="parameter">nom_fichier</replaceable>.gz | gunzip | psql <replaceable class="parameter">base_de_donnees</replaceable>
</programlisting>
    </para>
   </formalpara>

   <formalpara>
    <title>Couper le fichier avec <command>split</></title>
    <para>
     La commande <command>split</command> vous permet de découper le fichier en
     morceaux d'une taille acceptable pour le système de fichiers sous-jacent.
     Par exemple, pour faire des morceaux de 1&nbsp;Mo&nbsp;:
 
<programlisting>
pg_dump <replaceable class="parameter">base_de_donnees</replaceable> | split -b 1m - <replaceable class="parameter">nom_fichier</replaceable>
</programlisting>

     Pour restaurer&nbsp;:

<programlisting>
createdb <replaceable class="parameter">base_de_donnees</replaceable>
cat <replaceable class="parameter">nom_fichier</replaceable>* | psql <replaceable class="parameter">base_de_donnees</replaceable>
</programlisting>
    </para>
   </formalpara>

   <formalpara>
    <title>Utilisation du format de sauvegarde spécial</title>
    <para>
     Si <productname>PostgreSQL</productname> est installé sur un système où la 
     bibliothèque de compression <application>zlib</> est disponible, ce format
     de sauvegarde spécial peut être utilisé. Pour les grandes bases de données,
     cela produira un fichier de sauvegarde d'une taille comparable à celle de
     <command>gzip</command>, avec l'avantage supplémentaire de permettre de
     restaurer des tables sélectivement. La commande qui suit sauvegarde une
     base de données en utilisant le format de sauvegarde spécial&nbsp;:
 
<programlisting>
pg_dump -Fc <replaceable class="parameter">base_de_donnees</replaceable> > <replaceable class="parameter">nom_fichier</replaceable>
</programlisting>

     Voyez les pages de référence de <application>pg_dump</> et <application>pg_restore</> pour plus de détails.
    </para>
   </formalpara>

  </sect2>

  <sect2 id="backup-dump-caveats">
   <title>Limitations</title>

   <para>
    <application>pg_dump</> (et du coup 
    <application>pg_dumpall</>) a un certain nombre de limitations dûes à la 
    difficulté de reconstruire certaines informations du catalogue système. 
   </para>

   <para>
    Notamment, l'ordre dans lequel <application>pg_dump</> écrit les objets
    n'est pas très sophistiqué. Cela peut créer des problèmes, par exemple 
    quand des fonctions sont utilisées pour préciser les valeurs par défaut 
    de colonnes. La seule solution est alors de réordonner le fichier de 
    sauvegarde à la main. Si vous avez créé des références circulaires dans 
    votre modèle de données, alors vous aurez encore plus de travail.
   </para>

   <para>
    Pour des raisons de compatibilité avec les versions précédentes, <application>pg_dump</>
    ne sauvegarde pas les gros objets par défaut. <indexterm><primary>gros
    objets</primary><secondary>backup</secondary></indexterm> Pour
    les sauvegarder, vous devez utiliser soit le format de sauvegarde
    spécial soit le format TAR, et passer l'option <option>-b</> à 
    <application>pg_dump</>. Voyez la page de référence pour plus de détails.
    Le répertoire <filename>contrib/pg_dumplo</> des fichiers sources de <productname>PostgreSQL</>
    contient aussi un programme qui peut sauvegarder les gros objets.
  </para>

   <para>
    Merci de vous familiariser avec la page de référence de
    <citerefentry><refentrytitle>pg_dump</></>.
   </para>
  </sect2>
 </sect1>

 <sect1 id="backup-file">
  <title>Sauvegarde de niveau système de fichiers</title>

  <para>
   Une autre stratégie de sauvegarde est de copier les fichiers
   utilisés par <productname>PostgreSQL</> pour enregistrer les données.
   Dans la <xref linkend="creating-cluster">, 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&nbsp;:
 
<programlisting>
tar -cf sauvegarde.tar /usr/local/pgsql/data
</programlisting>
  </para>

  <para>
   Cependant, il y a deux restrictions qui rendent cette méthode inutilisable
   ou en tout cas inférieure à la méthode <application>pg_dump</>.
 
   <orderedlist>
    <listitem>
     <para>
      Le serveur de base de données <emphasis>doit</> être arrêté pour obtenir
      une sauvegarde utilisable. Toutes les demi-mesures, comme supprimer
      toutes les connections, ne fonctionnent pas, car il y a toujours des
      données dans des tampons en mémoire.
      Pour cette raison, il n'est pas conseillé de se reposer sur des systèmes 
      de fichiers qui affirment permettre des <quote>photographies cohérentes
      (snapshot)</quote>.
      Vous trouverez des informations sur la façon d'arrêter le serveur 
      <productname>PostgreSQL</> dans la <xref linkend="postmaster-shutdown">.
    </para>

     <para>
      Il va sans dire que vous devez aussi éteindre le serveur avant de 
      restaurer les données.
      </para>
    </listitem>

    <listitem>
     <para>
      Si vous vous êtes aventurés dans les détails de l'organisation des 
      fichiers 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 <emphasis>pas</> parce que les informations
      contenues dans ces fichiers ne sont qu'à moitié vraies. L'autre moitié
      est dans les fichiers journaux de validation
      <filename>pg_clog/*</filename>, 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 <filename>pg_clog</filename>
      associées car cela rendrait toutes les autres tables du serveur 
      inutilisables.
     </para>
    </listitem>
   </orderedlist>
  </para>

  <para>
   Une autre approche de sauvegarde d'un système de fichiers est de réaliser une
   <quote>copie cohérente</quote> du répertoire data, si le système de fichiers
   dispose de cette fonctionnalité. Une telle copie sauvegardera les fichiers de
   la base de données dans un état où le serveur n'était pas correctement
   arrêté&nbsp;; donc, avant de se retrouver dans un état normal après avoir
   lancé le serveur sur ce répertoire sauvegardé, le serveur pensera qu'il s'est
   arrêté brutalement et voudra rejouer les traces WAL. Ceci n'est pas un problème
   mais vous devez en être conscient.
  </para>

  <para>
   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 (<application>pg_dump</application> ne sauvegarde pas le 
   contenu des index, mais la commande pour les recréer).
  </para>

 </sect1>

 <sect1 id="migration">
  <title>Migration entre les différentes versions</title>

  <indexterm zone="migration">
   <primary>mise à jour</primary>
  </indexterm>

  <indexterm zone="migration">
   <primary>version</primary>
   <secondary>compatibilité</secondary>
  </indexterm>

  <para>
   En règle générale, le format interne des données est modifié entre les 
   différentes versions de <productname>PostgreSQL</> (quand le nombre après le
   premier point change). Ceci ne s'applique pas entre les différentes sorties
   mineures ayant le même numéro de version majeur (quand le nombre après le
   deuxième point change)&nbsp;; elles ont toujours un format de stockage
   compatible.
   Par exemple, les versions 7.0.1, 7.1.2 et 7.2 ne sont pas compatibles, alors
   que les versions 7.1.1 et 7.1.2 le sont. Lorsque vous migrez entre des 
   versions compatibles, vous pouvez simplement réutiliser les anciens fichiers
   de données avec les nouveaux exécutables. Sinon, vous devez <quote>sauvegarder</>
   et <quote>restaurer</> vos données sur le nouveau serveur avec <application>pg_dump</>
   (Des vérifications sont faites pour vous éviter de faire des mauvaises
   manipulations, si bien que rien de dangereux ne peut arriver si vous vous 
   trompez.). La procédure d'installation précise n'est pas le sujet de cette
   section. Les détails se trouvent dans le <xref linkend="installation">.
   </para>

  <para>
   Vous minimiserez la durée d'indisponibilité en installant le nouveau serveur
   dans un répertoire différent et en lançant l'ancien et le nouveau serveur en 
   parallèle sur des ports différents, puis en utilisant des commandes comme
 
<programlisting>
pg_dumpall -p 5432 | psql -d template1 -p 6543
</programlisting>

   pour transférer les données. Ou utilisez un fichier intermédiaire si vous
   voulez. Vous pouvez alors éteindre le nouveau serveur et démarrer le nouveau
   sur le port que l'ancien utilisait. Vous devez vous assurer que la base de
   données n'est pas modifiée après que vous ayez lancé 
   <application>pg_dumpall</>, sans quoi ces modifications seraient évidemment 
   perdues. Référez vous au <xref linkend="client-authentication"> pour savoir 
   comment interdire l'accès. En pratique, vous voudrez certainement tester 
   votre application sur le nouveau serveur avant de basculer définitivement.
  </para>

  <para>
   Si vous ne pouvez pas ou ne voulez pas lancer les deux serveurs en 
   parallèle, vous pouvez faire l'étape de sauvegarde avant d'installer la 
   nouvelle version, éteindre le serveur, déplacer l'ancienne version à un autre
   endroit, installer la nouvelle, la démarrer et enfin restaurer les données. Par
   exemple&nbsp;:
   
<programlisting>
pg_dumpall > sauvegarde.sql
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-&version;
gmake install
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
psql template1 < sauvegarde.sql
</programlisting>

   Vous trouverez les méthodes pour arrêter et démarrer les serveurs, ainsi que 
   d'autres détails dans le <xref linkend="runtime">.
   Les instructions d'installation vous donneront des conseils sur les endroits 
   stratégiques pour réaliser ces opérations.
  </para>

  <note>
   <para>
    Quand vous <quote>déplacez l'ancienne version à un autre endroit</quote>, 
    l'ancienne installation n'est plus tout à fait utilisable. Certaines parties
    de l'installation contiennent des informations sur l'endroit où d'autres
    parties sont installées. Ce n'est généralement pas un gros problème, mais si
    vous prévoyez d'utiliser deux installations en parallèle pendant un certain 
    temps, vous devriez leur donner des répertoires d'installation différents
    lors de la compilation.
   </para>
  </note>
 </sect1>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-tabs-mode:nil
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/share/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->