root/traduc/trunk/postgresql/backup.xml

<?xml version="1.0" encoding="ISO-8859-15"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<chapter id="backup">
 <title>Sauvegardes et restaurations</title>

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

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

 <para>
  Il y a trois approches fondamentalement différentes pour sauvegarder les 
  données de <productname>PostgreSQL</productname>&nbsp;:
  <itemizedlist>
   <listitem><para><acronym>la sauvegarde SQL&nbsp;;</acronym></para></listitem>
   <listitem><para>la sauvegarde au niveau du système de
    fichiers&nbsp;;</para></listitem>
   <listitem><para>l'archivage continu.</para></listitem>
  </itemizedlist>
  Chacune a ses avantages et ses inconvénients.
  Elles sont toutes analysées, chacune leur tour.
 </para>

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

  <para>
   Le principe est de produire 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</productname> propose pour cela le programme utilitaire
   <xref linkend="app-pgdump"/>. L'usage basique est&nbsp;:
<synopsis>pg_dump <replaceable class="parameter">base_de_donnees</replaceable> &gt; <replaceable class="parameter">fichier_de_sortie</replaceable></synopsis>
   <application>pg_dump</application> écrit son résultat sur la
   sortie standard. Son utilité est expliqué plus loin.
  </para>

  <para>
   <application>pg_dump</application> est un programme client
   <productname>PostgreSQL</productname>
   classique (mais plutôt intelligent). Cela signifie que la 
   sauvegarde peut être effectuée depuis n'importe quel ordinateur ayant accès à la base.
   Mais <application>pg_dump</application> n'a pas de droits spéciaux.
   Il doit, en particulier, avoir accès en lecture à toutes les tables 
   à sauvegarder, si bien qu'il doit être lancé pratiquement
   toujours en tant que superutilisateur de la base.
  </para>

  <para>
   Pour préciser le serveur de bases de données que 
   <application>pg_dump</application> doit
   contacter, on utilise les options de ligne de commande
   <option>-h <replaceable>serveur</replaceable></option> et
   <option>-p <replaceable>port</replaceable></option>.
   Le serveur par défaut est le serveur local ou celui indiqué 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. Le serveur a normalement reçu les mêmes valeurs par
   défaut à la compilation.
  </para>

  <para>
   Comme tout programme client <productname>PostgreSQL</productname>,
   <application>pg_dump</application>
   se connecte par défaut avec l'utilisateur de base de données de même nom que 
   l'utilisateur système courant. L'utilisation de l'option
   <option>-U</option> ou de la variable d'environnement
   <envar>PGUSER</envar> permettent de
   modifier le comportement par défaut. Les connexions de
   <application>pg_dump</application> sont soumises aux mécanismes normaux
   d'authentification des programmes clients (décrits dans le
   <xref linkend="client-authentication"/>).
  </para>

  <para>
   Les sauvegardes créées par <application>pg_dump</application> sont
   cohérentes, ce qui signifie que la sauvegarde représente une image de la
   base de données au moment où commence l'exécution de
   <application>pg_dump</application>.
   <application>pg_dump</application> ne bloque pas les autres opérations sur la base 
   lorsqu'il fonctionne (sauf celles qui nécessitent un verrou exclusif, comme 
   la plupart des formes d'<command>ALTER TABLE</command>.)
  </para>

  <important>
   <para>
    Si la base de données utilise les OID (par exemple en tant que clés 
    étrangères), il est impératif d'indiquer à
    <application>pg_dump</application> de sauvegarder
    aussi les OID. Pour cela, on utilise l'option <option>-o</option> sur la ligne
    de commande.
   </para>
  </important>

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

   <para>
    Les fichiers texte créés par <application>pg_dump</application> peuvent ê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
    celui précisé comme <replaceable class="parameter">fichier_de_sortie</replaceable>
    à la commande <application>pg_dump</application>. La base de données 
    <replaceable class="parameter">base_de_donnees</replaceable> n'est pas créée par cette 
    commande. Elle doit être créée à partir de <literal>template0</literal>
    avant d'exécuter <application>psql</application> (par exemple avec <literal>createdb -T
    template0 <replaceable class="parameter">base_de_donnees</replaceable></literal>).
    <application>psql</application> propose des options similaires à celles de
    <application>pg_dump</application> pour indiquer le serveur de bases de
    données sur lequel se connecter et le nom d'utilisateur à utiliser. La
    page de référence de <xref linkend="app-psql"/> donne plus d'informations.
    </para>

   <para>
    Tous les utilisateurs possédant des
    objets ou ayant certains droits sur les objets de la base sauvegardée
    doivent exister préalablement à la restauration de la sauvegarde. S'ils
    n'existent pas, la
    restauration échoue pour la création des objets dont ils sont
    propriétaires ou sur lesquels ils ont des droits (quelque fois, cela
    est souhaitable mais ce n'est habituellement pas le cas).
   </para>

   <para>
    Par défaut, le script <application>psql</application> continue de
    s'exécuter après la détection d'une erreur SQL. La commande suivante
    peut être placée au début du script pour modifier ce comportement.
    <application>psql</application> quitte alors avec un
    code d'erreur 3 si une erreur SQL survient&nbsp;:
<programlisting>\set ON_ERROR_STOP
</programlisting>
    Dans tous les cas, une sauvegarde partiellement restaurée est obtenue.
    Si cela n'est pas souhaitable, il est possible d'indiquer que la sauvegarde
    complète doit être restaurée au cours d'une transaction unique. De ce
    fait, soit la restauration est validée dans son ensemble, soit elle est
    entièrement annulée. Ce mode est choisi
    en passant l'option <option>-1</option> ou <option>--single-transaction</option>
    en ligne de commande à <application>psql</application>. Dans ce mode, 
    la plus petite erreur peut annuler une restauration en cours depuis
    plusieurs heures. Néanmoins, c'est probablement
    préférable au nettoyage manuel d'une base rendue complexe par une
    sauvegarde partiellement restaurée.
   </para>

   <para>
    La capacité de <application>pg_dump</application> et
    <application>psql</application> à é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> <replaceable>base_de_donnees</replaceable> | psql -h <replaceable>serveur2</replaceable> <replaceable>base_de_donnees</replaceable></programlisting>
   </para>

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

   <para>
    Après la restauration d'une sauvegarde, il est conseillé d'exécuter
    <xref linkend="sql-analyze" endterm="sql-analyze-title"/> sur chaque base de
    données pour que l'optimiseur de requêtes dispose de statistiques utiles.
    Un moyen simple de le faire est d'exécuter <command>vacuumdb -a -z</command>&nbsp;;
    c'est équivalent à exécuter manuellement <command>VACUUM ANALYZE</command> sur chaque
    base.
    Pour plus de conseils sur le chargement efficace de grosses quantités de
    données dans <productname>PostgreSQL</productname>, on peut se référer à la
    <xref linkend="populate"/>.
   </para>
   
  </sect2>

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

   <para>
    <application>pg_dump</application> ne sauvegarde qu'une seule base à la
    fois, et ne sauvegarde pas les informations relatives aux rôles et
    <foreignphrase>tablespaces</foreignphrase> (parce que ceux-ci portent
    sur l'ensemble des bases du cluster, et non sur une base particulière).
    Pour permettre une sauvegarde aisée de tout le contenu d'un cluster, le
    programme <xref linkend="app-pg-dumpall"/> est fourni.
    <application>pg_dumpall</application> sauvegarde toutes les bases de données d'un
    cluster (ensemble des bases d'une instance) <productname>PostgreSQL</productname> et
    préserve les données communes au cluster, telles que les rôles et tablespaces.
    L'utilisation basique de cette commande est&nbsp;:
<synopsis>pg_dumpall &gt; <replaceable>fichier_de_sortie</replaceable></synopsis>
    Le fichier de sauvegarde résultant peut être restauré avec
    <application>psql</application>&nbsp;:
<synopsis>psql -f <replaceable class="parameter">fichier_d_entree</replaceable> postgres</synopsis>
    (N'importe quelle base de données peut être utilisée pour la connexion 
    mais si le rechargement est exécuté sur un cluster vide, il est
    préférable d'utiliser <literal>postgres</literal>.)
    Il faut obligatoirement avoir le profil superutilisateur pour restaurer
    une sauvegarde faite avec <application>pg_dumpall</application>, afin de
    pouvoir restaurer les informations sur les rôles et les tablespaces.
    Si les <foreignphrase>tablespaces</foreignphrase> sont utilisés, il faut
    s'assurer que leurs chemins sauvegardés sont appropriés à la nouvelle
    installation.
   </para>

   <para>
    <application>pg_dumpall</application> fonctionne en émettant des
    commandes pour re-créer des rôles, des tablespaces et des bases vides, puis
    en invoquant <application>pg_dump</application> pour chaque base de
    données. Cela signifie que, bien que chaque base de données est
    cohérente en interne, les images des différentes bases de données peuvent
    ne pas être tout à fait synchronisées.
   </para>
  </sect2>

  <sect2 id="backup-dump-large">
   <title>Gérer les grosses bases de données</title>

   <para>
    Comme <productname>PostgreSQL</productname> autorise des tables plus
    volumineuses que la taille maximale d'un fichier sur le système de fichiers,
    sauvegarder une telle table en fichier peut poser des problèmes. 
    Puisque <application>pg_dump</application> peut écrire sur la sortie
    standard, les outils standard d'Unix peuvent être utilisés pour contourner
    ce problème éventuel.
    Il existe plusieurs façon de procéder&nbsp;:
   </para>

   <formalpara>
    <title>Compresser le fichier de sauvegarde</title>
    <para>
     Tout programme de compression habituel est utilisable. Par exemple
     <application>gzip</application>&nbsp;:

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

     Pour restaurer&nbsp;:

<programlisting>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</command></title>
    <para>
     La commande <command>split</command> permet de découper le fichier en
     morceaux de taille acceptable par 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>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 personnalisé de
     <application>pg_dump</application></title>
    <para>
     Si <productname>PostgreSQL</productname> est installé sur un système où la 
     bibliothèque de compression <application>zlib</application> est
     disponible, le format de sauvegarde personnalisé peut être utilisé pour
     compresser les données à la volée. Pour les bases de données
     volumineuses,
     cela produit un fichier de sauvegarde d'une taille comparable à celle
     du fichier produit par
     <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 ce format de sauvegarde&nbsp;:
 
<programlisting>pg_dump -Fc <replaceable class="parameter">base_de_donnees</replaceable> &gt; <replaceable class="parameter">nom_fichier</replaceable></programlisting>

     Le format de sauvegarde personnalisé ne produit pas un script
     utilisable par
     <application>psql</application>. Ce script doit être restauré avec
     <application>pg_restore</application>, par exemple&nbsp;:

<programlisting>
pg_restore -d <replaceable class="parameter">nom_base</replaceable> <replaceable class="parameter">nom_fichier</replaceable>
</programlisting>

     Voir les pages de référence de
     <xref linkend="app-pgdump"/> et <xref linkend="app-pgrestore"/> pour plus de
     détails.
    </para>
   </formalpara>

   <para>
    Pour les très grosses bases de données, il peut être nécessaire de combiner
    <command>split</command> avec une des deux autres approches.
   </para>

  </sect2>
 </sect1>

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

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

  <para>
   Cependant, deux restrictions rendent cette méthode peu pratique
   ou en tout cas inférieure à la méthode <application>pg_dump</application>.
 
   <orderedlist>
    <listitem>
     <para>
      Le serveur de base de données <emphasis>doit</emphasis> être arrêté pour obtenir
      une sauvegarde utilisable. Toutes les demi-mesures, comme la
      suppression des connexions, ne fonctionnent <emphasis>pas</emphasis>
      (principalement parce que <command>tar</command> 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 <productname>PostgreSQL</productname> se trouvent dans la
      <xref linkend="server-shutdown"/>.
    </para>

     <para>
      Le serveur doit également être arrêté avant de restaurer les données.
      </para>
    </listitem>

    <listitem>
     <para>
      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. 
      Cela ne fonctionne <emphasis>pas</emphasis> 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
      <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. 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.
     </para>
    </listitem>
   </orderedlist>
  </para>

  <para>
   Une autre approche à la sauvegarde du système de fichiers consiste à réaliser
   une <quote>image cohérente</quote> (<foreignphrase>consistent
   snapshot</foreignphrase>) 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
   <quote>image gelée</quote> (<foreignphrase>frozen snapshot</foreignphrase>) 
   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é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é&nbsp;; 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).
  </para>

  <para>
   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 <emphasis>doivent</emphasis> ê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.
  </para>

  <para>
   Une autre option consiste à utiliser <application>rsync</application> pour réaliser une
   sauvegarde du système de fichiers. Ceci se fait tout d'abord en lançant
   <application>rsync</application> 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
   <application>rsync</application> une deuxième fois. Le deuxième
   <application>rsync</application> 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.
  </para>

  <para>
   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 (<application>pg_dump</application> 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.
  </para>

 </sect1>

 <sect1 id="continuous-archiving">
  <title>Archivage continu et récupération d'un instantané (PITR)</title>

  <indexterm zone="backup">
   <primary>archivage en continue</primary>
  </indexterm>

  <indexterm zone="backup">
   <primary>récupération d'un instantané</primary>
  </indexterm>

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

  <para>
   <productname>PostgreSQL</productname> maintient en permanence des journaux WAL
   (<firstterm>write ahead log</firstterm>) dans le sous-répertoire
   <filename>pg_xlog/</filename> du répertoire de données du cluster. Ces journaux
   décrivent chaque modification effectuée sur les fichiers de données des
   bases. Ils existent principalement pour se prémunir des suites d'un
   arrêt brutal&nbsp;: si le système s'arrête brutalement, la base de données
   peut être restaurée dans un état cohérent en
   <quote>rejouant</quote> les entrées des journaux enregistrées depuis le dernier
   point de vérification. Néanmoins, l'existence de ces journaux rend possible
   l'utilisation d'une troisième stratégie pour la sauvegarde des bases de
   données&nbsp;: la combinaison d'une sauvegarde de niveau système de
   fichiers avec la sauvegarde des fichiers WAL. Si la récupération est
   nécessaire, la sauvegarde est restaurée, puis les fichiers WAL sauvegardés
   sont rejoués pour amener la sauvegarde jusqu'à la date
   actuelle. Cette approche est plus complexe à administrer que toutes les
   autres approches mais elle apporte des bénéfices significatifs&nbsp;:
  <itemizedlist>
   <listitem>
    <para>
     Il n'est pas nécessaire de disposer d'une sauvegarde parfaitement cohérente
     comme point de départ. Toute incohérence dans la sauvegarde est corrigée
     par la ré-exécution des journaux (ceci n'est pas significativement
     différent de ce qu'il se passe lors d'une récupération après un arrêt
     brutal). La fonctionnalité d'image du système de fichiers n'est alors
     pas nécessaire, <application>tar</application> ou tout
     autre outil d'archivage est suffisant.
    </para>
   </listitem>
   <listitem>
    <para>
     Puisqu'une longue séquence de fichiers WAL peut être assemblée pour
     être rejouée, une sauvegarde continue est obtenue en continuant
     simplement à archiver les fichiers WAL. C'est particulièrement
     intéressant pour les grosses bases de données dont une sauvegarde
     complète fréquente est difficilement réalisable.
    </para>
   </listitem>
   <listitem>
    <para>
     Les entrées WAL ne doivent pas obligatoirement être rejouées
     intégralement. La ré-exécution peut être stoppée en tout point, tout en
     garantissant une image cohérente de la base de données telle qu'elle
     était à ce moment-là. Ainsi, cette technique autorise la
     <firstterm>récupération d'un instantané</firstterm> (PITR)&nbsp;: il est
     possible de restaurer l'état de la base de données telle qu'elle était 
     en tout point dans le temps depuis la dernière sauvegarde de base.
    </para>
   </listitem>
   <listitem>
    <para>
     Si la série de fichiers WAL est fournie en continu à une autre
     machine chargée avec le même fichier de sauvegarde de base,
     on obtient un système <quote>de reprise intermédiaire</quote>
     (<foreignphrase>warm standby</foreignphrase>)&nbsp;: à tout
     moment, la deuxième machine peut être montée et disposer d'une copie
     quasi-complète de la base de données.
    </para>
   </listitem>
  </itemizedlist>
  </para>

  <para>
   Tout comme la technique de sauvegarde standard du système de fichiers,
   cette méthode ne supporte que la restauration d'un cluster de bases de données
   complet, pas d'un sous-ensemble. De plus, un espace d'archivage important
   est requis&nbsp;: la sauvegarde de la base peut être volumineuse et un
   système très utilisé engendre un trafic WAL à archiver de plusieurs Mo.
   Malgré tout, c'est la technique de sauvegarde préférée dans de nombreuses
   situations où une haute fiabilité est requise.
  </para>

  <para>
   Une récupération fructueuse à partir de l'archivage continu
   (aussi appelé <quote>sauvegarde à chaud</quote> par certains vendeurs de SGBD) nécessite
   une séquence ininterrompue de fichiers WAL archivés qui
   s'étend au moins jusqu'au point de départ de la sauvegarde. Pour
   commencer, il faut configurer et tester la procédure d'archivage
   des journaux WAL <emphasis>avant</emphasis> d'effectuer la première sauvegarde de
   base. C'est pourquoi la suite du document commence par présenter les mécanismes
   d'archivage des fichiers WAL.
  </para>

  <sect2 id="backup-archiving-wal">
   <title>Configurer l'archivage WAL</title>

   <para>
    Au sens abstrait, un système <productname>PostgreSQL</productname> fonctionnel
    produit une séquence infinie d'enregistrements WAL. Le système
    divise physiquement cette séquence en <firstterm>fichiers de segment</firstterm>
    WAL de 16&nbsp;Mo chacun (en général, mais cette taille peut
    être modifiée lors de la construction de <productname>PostgreSQL</productname>). Les
    fichiers segment reçoivent des noms numériques pour refléter leur
    position dans la séquence abstraite des WAL. Lorsque le système n'utilise
    pas l'archivage des WAL, il ne crée que quelques fichiers segment,
    qu'il <quote>recycle</quote> en renommant les fichiers devenus inutiles.
    Un fichier segment dont le contenu précède le
    dernier point de vérification est supposé inutile et peut être recyclé.
   </para>

   <para>
    Lors de l'archivage des données WAL, le contenu de
    chaque fichier de segment doit être capturé dès qu'il est rempli pour
    sauvegarder les données ailleurs avant son recyclage.
    En fonction de l'application et du matériel disponible, 
    <quote>sauvegarder les données ailleurs</quote> peut se faire de plusieurs
    façons&nbsp;: les fichiers segment peuvent être copiés dans un répertoire
    NFS monté sur une autre machine, être écrits sur une cartouche (après
    s'être assuré qu'il existe un moyen d'identifier le nom d'origine de chaque
    fichier) ou être groupés pour gravage sur un CD, ou toute autre chose.
    Pour fournir autant de flexibilité que possible à l'administrateur de la
    base de données, <productname>PostgreSQL</productname> essaie de ne faire aucune
    supposition sur la façon dont l'archivage est réalisé. À la place,
    <productname>PostgreSQL</productname> permet de préciser la commande
    shell à exécuter pour copier le fichier de segment complet à l'endroit
    désiré. La commande peut être aussi simple qu'un
    <literal>cp</literal> ou impliquer un shell complexe &mdash;
    c'est l'utilisateur qui décide.
   </para>

   <para>
    Pour activer l'archivage des journaux de transaction, on positionne le
    paramètre <xref linkend="guc-archive-mode"/> à <literal>on</literal>,
    et on précise la commande shell à utiliser dans le paramètre
    <xref linkend="guc-archive-command"/> de la configuration. En fait, ces
    paramètres seront toujours placés dans le fichier
    <filename>postgresql.conf</filename>. Dans cette chaîne, un
    <literal>%p</literal> est remplacé par le chemin absolu de
    l'archive alors qu'un <literal>%f</literal> n'est remplacé que par le
    nom du fichier. (Le nom du chemin est relatif au répertoire de travail du
    serveur, c'est-à-dire le répertoire des données du cluster.)
    <literal>%%</literal> est utilisé pour écrire le
    caractère <literal>%</literal> dans la commande. La commande la plus
    simple ressemble à&nbsp;:
<programlisting>archive_command = 'cp -i %p /mnt/serveur/repertoire_archive/%f &lt;/dev/null'</programlisting>
    qui copie les segments WAL archivables dans le répertoire
    <filename>/mnt/serveur/repertoire_archive</filename>. (Ceci est un exemple, pas
    une recommandation, et peut ne pas fonctionner sur toutes les
    plateformes.) Après le remplacement des paramètres <literal>%p</literal>
    et <literal>%f</literal>, la commande réellement exécutée peut ressembler
    à&nbsp;:
<programlisting>cp -i pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065 &lt;/dev/null
</programlisting>
    Une commande similaire est produite pour chaque nouveau fichier à archiver.
   </para>

   <para>
    La commande d'archivage est exécutée sous l'identité de l'utilisateur 
    propriétaire du serveur <productname>PostgreSQL</productname>. La série de
    fichiers WAL en cours d'archivage contient absolument tout ce qui se
    trouve dans la base de données, il convient donc de s'assurer que les
    données archivées sont protégées des autres utilisateurs&nbsp;; on peut,
    par exemple, archiver dans un répertoire sur lequel les droits de lecture
    ne sont positionnés ni pour le groupe ni pour le reste du monde.
   </para>

   <para>
    Il est important que la commande d'archivage ne renvoie le code de sortie
    zéro que si, et seulement si, l'exécution a réussi. En obtenant un résultat
    zéro, <productname>PostgreSQL</productname> suppose que le fichier segment WAL a
    été archivé avec succès et qu'il peut le supprimer ou le recycler.
    Un statut différent de zéro indique à  
    <productname>PostgreSQL</productname> que le fichier n'a pas été archivé&nbsp;; il
    essaie alors périodiquement jusqu'à la réussite de l'archivage.
   </para>

   <para>
    La commande d'archivage doit en général être conçue pour refuser
    d'écraser tout fichier archive qui existe déjà. C'est une fonctionnalité
    de sécurité importante pour préserver l'intégrité de l'archive dans le
    cas d'une erreur de l'administrateur (comme l'envoi de la sortie de deux
    serveurs différents dans le même répertoire d'archivage). Il est
    conseillé de tester la commande d'archivage proposée pour
    s'assurer qu'en effet elle n'écrase pas un fichier existant <emphasis>et
    qu'elle retourne un statut différent de zéro dans ce cas</emphasis>.
    Il a été découvert
    que <literal>cp -i</literal> travaille correctement sur certaines plateformes,
    mais pas sur toutes. Si la commande choisie ne gère pas elle-même ce
    cas, il convient d'ajouter une commande pour tester l'existence du fichier
    d'archivage. Par exemple, quelque chose comme&nbsp;:
<programlisting>archive_command = 'test ! -f .../%f &amp;&amp; cp %p .../%f'</programlisting>
    fonctionne correctement sur la plupart des variantes Unix.
   </para>

   <para>
    Lors de la conception de la configuration d'archivage, il faut
    considérer ce qui arrive si la commande d'archivage échoue de façon
    répétée, parce
    que certains aspects demandent une intervention de l'opérateur ou
    par manque d'espace dans le répertoire d'archivage. 
    Ceci peut arriver, par exemple, lors de l'écriture sur une cartouche sans changeur 
    automatique&nbsp;; quand la cartouche est pleine, rien ne peut être
    archivé tant que la cassette n'est pas changée. 
    Toute erreur ou requête à un opérateur humain doit être rapportée de façon
    appropriée pour que la situation puisse être résolue
    rapidement. Le répertoire <filename>pg_xlog/</filename> continue à se remplir
    de fichiers de segment WAL jusqu'à la résolution de la situation.
    (Si le système de fichiers contenant <filename>pg_xlog/</filename> se
    remplit, <productname>PostgreSQL</productname> s'arrête en mode PANIC.
    Aucune transaction antérieure n'est perdue mais la base de données est
    indisponible le temps pour l'utilisateur de retrouver de l'espace.)
   </para>

   <para>
    La vitesse de la commande d'archivage n'est pas importante, tant qu'elle
    suit le rythme que la génération de données WAL du serveur. Les
    opérations normales continuent même si le processus d'archivage est un peu
    plus lent. Si l'archivage est significativement plus lent, alors la
    quantité de données qui peut être perdue croît. Cela signifie
    aussi que le répertoire <filename>pg_xlog/</filename> contient un grand nombre
    de fichiers segment non archivés, qui peuvent finir par
    dépasser l'espace disque disponible. Il est conseillé de surveiller
    le processus d'archivage pour s'assurer que tout fonctionne
    normalement.
   </para>

   <para>
    Lors de l'écriture de la commande d'archivage, il faut garder à l'esprit que les
    noms de fichier à archiver peuvent contenir jusqu'à 64 caractères et 
    être composés de toute combinaison de lettres ASCII, de chiffres et de points.
    Il n'est pas nécessaire de retenir le chemin relatif original
    (<literal>%p</literal>) mais il est nécessaire de rappeler le nom du fichier
    (<literal>%f</literal>).
   </para>

   <para>
    Bien que l'archivage WAL autorise à restaurer toute
    modification réalisée sur les données de la base 
    <productname>PostgreSQL</productname>, il ne restaure pas les modifications
    effectuées sur les fichiers de configuration (c'est-à-dire
    <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename> et
    <filename>pg_ident.conf</filename>) car ceux-ci sont édités manuellement
    et non au travers d'opérations SQL. Il est souhaitable de conserver les
    fichiers de configuration à un endroit où ils sont sauvegardés par les
    procédures standard de sauvegarde du système de fichiers. Voir la
    <xref linkend="runtime-config-file-locations"/> pour savoir comment
    modifier l'emplacement des fichiers de configuration.
   </para>

   <para>
    La commande d'archivage n'est appelée que sur les segments WAL complets.
    Du coup, si le serveur engendre peu de trafic WAL (ou qu'il y a des périodes
    de calme où le trafic WAL est léger), il peut y avoir une longue période
    entre la fin d'une transaction et son enregistrement sûr dans le stockage
    d'archive. Pour placer une limite sur l'ancienneté des données archivées,
    on configure <xref linkend="guc-archive-timeout"/> qui force le
    serveur à changer de fichier segment WAL passé ce délai. Les
    fichiers archivés lors d'un tel forçage ont toujours
    la même taille que les fichiers complets. Il est donc déconseillé de configurer
    un délai <varname>archive_timeout</varname> trop court &mdash; cela fait
    grossir anormalement le stockage. Une minute pour <varname>archive_timeout</varname>
    est généralement raisonnable.
   </para>

   <para>
    De plus, le changement d'un segment peut être forcé manuellement avec
    <function>pg_switch_xlog</function>. Cela permet de s'assurer qu'une
    transaction tout juste terminée est archivée aussi vite que possible.
    D'autres fonctions utilitaires relatives à la gestion des WAL sont
    disponibles dans <xref linkend="functions-admin-backup-table"/>.
   </para>

   <para>
    Quand <varname>archive_mode</varname> est désactivé
    (<literal>off</literal>), certaines commandes SQL sont optimisées pour
    éviter la journalisation des transactions, de la façon décrite dans
    <xref linkend="populate-pitr"/>. Si l'archivage est activé lors de
    l'exécution d'une de ces instructions, les journaux de transaction ne
    contiennent pas d'informations suffisantes pour une récupération via les
    archives mais la récupération après un arrêt brutal n'est pas affectée.
    Pour cette raison, <varname>archive_mode</varname> ne peut être
    modifié qu'au lancement du serveur. Néanmoins,
    <varname>archive_command</varname> peut être modifié avec un
    rechargement du fichier de configuration. Pour arrêter
    temporairement l'archivage, on peut placer une
    chaîne vide (<literal>''</literal>) pour
    <varname>archive_command</varname>. Les journaux de transaction sont alors
    accumulés dans <filename>pg_xlog/</filename> jusqu'au rétablissement
    d'un paramètre <varname>archive_command</varname> fonctionnel.
   </para>
  </sect2>

  <sect2 id="backup-base-backup">
   <title>Réaliser une sauvegarde de base</title>

   <para>
    La procédure pour réaliser une sauvegarde de base est relativement
    simple&nbsp;:
  <orderedlist>
   <listitem>
    <para>
     S'assurer que l'archivage WAL est activé et fonctionnel.
    </para>
   </listitem>
   <listitem>
    <para>
     Se connecter à la base de données en tant que superutilisateur et
     lancer la commande&nbsp;:
<programlisting>SELECT pg_start_backup('label');</programlisting>
     où <literal>label</literal> est une chaîne utilisée pour
     identifier de façon unique l'opération de sauvegarde (une bonne pratique
     est d'utiliser le chemin complet du
     fichier de sauvegarde). <function>pg_start_backup</function> crée un fichier
     <firstterm>de label de sauvegarde</firstterm> nommé
     <filename>backup_label</filename> dans
     le répertoire du cluster. Ce fichier contient les informations de la sauvegarde.
    </para>

    <para>
     La base de données de connexion utilisée pour lancer
     cette commande n'a aucune importance. Le résultat de la fonction peut
     être ignoré, mais il faut gérer l'erreur éventuelle avant
     de continuer.
    </para>

    <para>
     <function>pg_start_backup</function> peut prendre beaucoup de temps
     pour arriver à son terme. Ceci est dû au fait qu'il réalise un
     point de retournement, et que les entrées/sorties pour l'établissement
     de ce point de retournement seront réparties sur une grande période
     de temps, par défaut la moitié de l'intervalle d'un point de
     retournement (voir le paramètre de configuration
     <xref linkend="guc-checkpoint-completion-target"/>). Habituellement,
     ce comportement est appréciable car il minimise l'impact du traitement
     des requêtes. Pour commencer la sauvegarde aussi rapidement
     que possible, on exécute la commande <command>CHECKPOINT</command> (qui
     déclenche un point de vérification dès que possible), puis
     on exécute immédiatement <function>pg_start_backup</function>. Le point
     de vérification de <function>pg_start_backup</function> n'a alors plus
     grand chose à faire, et s'exécute donc rapidement.
    </para>
   </listitem>
   <listitem>
    <para>
     Effectuer la sauvegarde à l'aide de tout outil de sauvegarde du
     système de fichiers, tel <application>tar</application> ou
     <application>cpio</application>. Il
     n'est ni nécessaire ni désirable de stopper les opérations normales de
     la base de données pour cela.
    </para>
   </listitem>
   <listitem>
    <para>
     Se connecter à nouveau à la base de données en tant que
     superutilisateur et lancer la commande&nbsp;:
<programlisting>SELECT pg_stop_backup();</programlisting>
     Cela met fin au processus de sauvegarde et réalise un basculement
     automatique vers le prochain segment WAL. Ce basculement est nécessaire
     pour permettre au dernier fichier de segment WAL écrit pendant la
     sauvegarde d'être immédiatement archivable.
    </para>
   </listitem>
   <listitem>
    <para>
     Une fois que les fichiers des segments WAL utilisés lors de la sauvegarde
     sont archivés, c'est terminé. Le fichier identifié par le résultat de
     <function>pg_stop_backup</function> est le dernier segment à archiver pour
     terminer la sauvegarde. L'archivage de ces fichiers intervient automatiquement
     car <varname>archive_command</varname> est déjà configuré. Dans de
     nombreux cas, c'est assez rapide mais il est conseillé de
     surveiller le système d'archivage pour s'assurer que celui-ci s'effectue
     correctement et que la sauvegarde est complète.
    </para>
   </listitem>
  </orderedlist>
   </para>

   <para>
    Certains outils de sauvegarde émettent des
    messages d'avertissements ou d'erreurs si les fichiers qu'ils essaient de
    copier sont modifiés au cours de la copie. Cette situation, normale lors
    de la sauvegarde d'une base active, ne doit pas être considérée comme 
    une erreur&nbsp;; il suffit de s'assurer que ces messages peuvent être
    distingués des autres messages. Certaines versions de
    <application>rsync</application>, par exemple, renvoient un code de sortie
    distinct en cas de <quote>disparition de fichiers source</quote>. Il est
    possible d'écrire un script qui considère ce code de sortie comme normal.
   </para>

   <para>
    De plus, certaines versions de GNU <application>tar</application>
    retournent un code d'erreur qu'on peut confondre avec une erreur fatale si
    le fichier a été tronqué pendant sa copie par
    <application>tar</application>. Heureusement, les versions 1.16 et
    suivantes de GNU <application>tar</application> retournent
    <literal>1</literal> si le fichier a été modifié pendant la sauvegarde et
    <literal>2</literal> pour les autres erreurs.
   </para>

   <para>
    Il n'est pas utile d'accorder de l'importance au temps passé entre
    <function>pg_start_backup</function> et le début réel de la sauvegarde, pas
    plus qu'entre la fin de la sauvegarde et
    <function>pg_stop_backup</function>&nbsp;; un délai de quelques minutes ne
    pose pas de problème. (Néanmoins, si le serveur est normalement utilisé
    alors que <varname>full_page_writes</varname> est désactivé, une perte de
    performances entre <function>pg_start_backup</function> et
    <function>pg_stop_backup</function> peut être constatée car l'activation du
    paramètre <varname>full_page_writes</varname> est forcée lors du mode de
    sauvegarde.) Il convient toutefois de s'assurer que ces étapes sont
    effectuées séquentiellement, sans chevauchement. Dans le cas contraire, la
    sauvegarde est invalidée.
   </para>

   <para>
    La sauvegarde doit inclure tous les fichiers du répertoire
    du groupe de bases de données
    (<filename>/usr/local/pgsql/data</filename>, par exemple). Si des
    <foreignphrase>tablespace</foreignphrase> 
    qui ne se trouvent pas dans ce répertoire sont utilisés, il ne faut pas
    oublier de les inclure (et s'assurer également que la sauvegarde archive les liens
    symboliques comme des liens, sans quoi la restauration des
    <foreignphrase>tablespace</foreignphrase> sera problématique).
   </para>

   <para>
    Néanmoins, les fichiers du sous-répertoire
    <filename>pg_xlog/</filename>,
    contenu dans le répertoire du cluster, peuvent être omis. Cette petite
    complication permet de réduire le risque d'erreurs lors de la restauration.
    C'est facile à réaliser si <filename>pg_xlog/</filename> est un lien
    symbolique vers quelque endroit extérieur au répertoire du cluster, 
    ce qui est toutefois une configuration courante, pour des raisons de performance.
   </para>

   <para>
    La sauvegarde n'est utilisable que si les fichiers de segment WAL
    engendrés pendant ou après cette sauvegarde sont préservés.
    Pour faciliter cela, la fonction 
    <function>pg_stop_backup</function> crée un <firstterm>fichier d'historique de la
    sauvegarde</firstterm> immédiatement stocké dans la zone d'archivage des WAL.
    Ce fichier est nommé d'après le nom du premier fichier segment WAL
    nécessaire à l'utilisation de la sauvegarde. Ainsi, si le fichier
    WAL de démarrage est <literal>0000000100001234000055CD</literal>, le nom
    du fichier d'historique ressemble à 
    <literal>0000000100001234000055CD.007C9330.backup</literal> (le deuxième nombre
    dans le nom de ce fichier contient la position exacte à l'intérieur du fichier
    WAL et peut en général être ignoré). Une fois que la sauvegarde du
    système de fichiers et des segments WAL utilisés
    pendant celle-ci (comme précisé dans le fichier d'historique des sauvegardes) 
    est archivée de façon sûre,   
    tous les segments WAL archivés de noms numériquement plus
    petits ne sont plus nécessaires à la récupération de la sauvegarde du
    système de fichiers et peuvent être supprimés. Toutefois, il est
    préférable de conserver plusieurs jeux de sauvegarde pour être absolument
    certain de pouvoir récupérer les données.
   </para>

   <para>
    Le fichier d'historique de la sauvegarde est un simple fichier texte. Il
    contient le label passé à <function>pg_start_backup</function>,
    l'heure et les segments WAL de début et de fin de la sauvegarde.
    Si le label est utilisé pour identifier l'endroit où le fichier de sauvegarde associé
    est conservé, alors le fichier d'historique archivé est suffisant pour
    savoir quel fichier de sauvegarde restaurer, en cas de besoin.
   </para>

   <para>
    Puisqu'il faut conserver tous les fichiers WAL archivés depuis la
    dernière sauvegarde de base, l'intervalle entre les sauvegardes de base
    est habituellement choisi en fonction de l'espace de stockage qu'on
    accepte de consommer en fichiers d'archives WAL. Il faut également
    considérer le temps à dépenser pour la
    récupération, si celle-ci s'avère nécessaire &mdash; le système doit rejouer
    tous les segments WAL et ceci peut prendre beaucoup de temps si la
    dernière sauvegarde de base est ancienne.
   </para>

   <para>
    La fonction
    <function>pg_start_backup</function> crée un fichier nommé 
    <filename>backup_label</filename> dans le répertoire du cluster de bases
    de données. Ce fichier est ensuite supprimé par
    <function>pg_stop_backup</function>. Ce fichier est bien sûr archivé
    comme faisant parti du fichier de
    sauvegarde. Le fichier de label de la sauvegarde inclut la chaîne de label
    passée à <function>pg_start_backup</function>, l'heure à
    laquelle <function>pg_start_backup</function> a été exécuté et le nom du fichier
    WAL initial. En cas de confusion, il est ainsi possible de regarder
    dans le fichier sauvegarde et de déterminer avec précision de quelle session
    de sauvegarde provient ce fichier.
   </para>

   <para>
    Il est aussi possible de faire une sauvegarde alors que le serveur est
    arrêté. Dans ce cas, <function>pg_start_backup</function> et
    <function>pg_stop_backup</function> ne peuvent évidemment pas être
    utilisés. L'utilisateur doit alors se débrouiller pour identifier les
    fichiers de sauvegarde et déterminer jusqu'où remonter avec les fichiers
    WAL associés. Il est généralement préférable de
    suivre la procédure d'archivage en ligne décrite ci-dessus.
   </para>
  </sect2>

  <sect2 id="backup-pitr-recovery">
   <title>Récupération d'une sauvegarde en ligne</title>

   <para>
    Le pire est arrivé et il faut maintenant repartir d'une sauvegarde.
    Voici la procédure&nbsp;:
  <orderedlist>
   <listitem>
    <para>
     Arrêter le serveur s'il est en cours d'exécution.
    </para>
   </listitem>
   <listitem>
    <para>
     Si la place nécessaire est disponible, copier le répertoire complet de
     données du cluster et tous les <foreignphrase>tablespaces</foreignphrase>
     dans un emplacement temporaire en prévision d'un éventuel besoin
     ultérieur. Cette précaution nécessite qu'un espace suffisant sur le
     système soit disponible pour contenir deux copies de la base de données
     existante. S'il n'y a pas assez de place disponible, il faut au minimum 
     copier le contenu du sous-répertoire <filename>pg_xlog</filename> du
     répertoire des données du cluster car il peut contenir des journaux
     qui n'ont pas été archivés avant l'arrêt du serveur.
    </para>
   </listitem>
   <listitem>
    <para>
     Effacer tous les fichiers et sous-répertoires existant sous le
     répertoire des données du cluster et sous les répertoires racines des
     <foreignphrase>tablespaces</foreignphrase>.
    </para>
   </listitem>
   <listitem>
    <para>
     Restaurer les fichiers de la base de données à partir de la
     sauvegarde. Il faut veiller à ce qu'ils soient restaurés avec le bon
     propriétaire (l'utilisateur système de la base de données, et non pas
     <literal>root</literal>&nbsp;!) et avec les bons droits. Si des
     <foreignphrase>tablespaces</foreignphrase> sont utilisés, il faut
     s'assurer que les liens symboliques dans
     <filename>pg_tblspc/</filename> ont été correctement restaurés.
    </para>
   </listitem>
   <listitem>
    <para>
     Supprimer tout fichier présent dans <filename>pg_xlog/</filename>&nbsp;;
     ils proviennent de la sauvegarde et sont du coup probablement obsolètes.
     Si <filename>pg_xlog/</filename> n'a pas été archivé, il suffit de 
     recréer ce répertoire en faisant attention à le créer en tant que
     lien symbolique si c'était le cas auparavant.
     Le sous-répertoire
     <filename>pg_xlog/archive_status/</filename> doit aussi être créé.
    </para>
   </listitem>
   &l