backup.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- 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 = 'test ! -f /mnt/serveur/repertoire_archive/%f &amp;&amp; cp %p /mnt/serveur/repertoire_archive/%f'  # Unix
archive_command = 'copy "%p" "C:\\serveur\\repertoire_archive\\%f"'  # Windows</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>test ! -f /mnt/serveur/repertoire_archive/00000001000000A900000065 &amp;&amp; cp pg_xlog/00000001000000A900000065 /mnt/serveur/repertoire_archive/00000001000000A900000065
</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).
   </para>

   <para>
    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>.
    La commande de l'exemple pour Unix ci-dessus s'en assure en ajoutant
    une étape de test séparé. Sur certaines plateformes Unix,
    <command>cp</command> dispose d'options comme <option>-i</option>
    pouvant être utilisées pour obtenir le même résultat, avec une
    commande moins longue, mais vous ne devez pas vous baser sur ces
    options sans tester que le bon code de statut est renvoyé. (En
    particulier, GNU <command>cp</command> renverra toujours le code de
    statut 0 quand l'option <option>-i</option> est utilisée, même si le
    fichier cible existe, ce qui n'est <emphasis>pas</emphasis> le
    comportement désiré.)
   </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>
   <listitem>
    <para>
     Si des fichiers de segment WAL non archivés ont été sauvegardés dans
     l'étape 2, les copier dans <filename>pg_xlog/</filename>. Il
     est préférable de les copier plutôt que de les déplacer afin qu'une
     version non modifiée de ces fichiers soit toujours disponible si un
     problème survient et qu'il faille recommencer.
    </para>
   </listitem>
   <listitem>
    <para>
     Créer un fichier de commandes de récupération 
     <filename>recovery.conf</filename> dans le répertoire des données du
     cluster (voir <xref linkend="recovery-config-settings"/>). Il peut, de
     plus être judicieux de modifier temporairement le fichier 
     <filename>pg_hba.conf</filename> pour empêcher les utilisateurs
     ordinaires de se connecter tant qu'il n'est pas certain que la
     récupération a réussi.
    </para>
   </listitem>
   <listitem>
    <para>
     Démarrer le serveur. Le serveur se trouve alors en mode récupération et
     commence la lecture des fichiers WAL archivés dont il a besoin. Si la
     récupération se termine sur une erreur externe, le serveur peut tout
     simplement être relancé. Il continue alors la récupération. À la
     fin du processus de récupération, le serveur renomme
     <filename>recovery.conf</filename> en <filename>recovery.done</filename>
     (pour empêcher de retourner accidentellement en mode de récupération en
     cas de nouvel arrêt brutal ultérieur), puis passe en mode de
     fonctionnement normal.
    </para>
   </listitem>
   <listitem>
    <para>
     Inspecter le contenu de la base de données pour s'assurer que la
     récupération a bien fonctionné. Dans le cas contraire, retourner
     à l'étape 1. Si tout va bien, le fichier <filename>pg_hba.conf</filename>
     peut-être restauré pour autoriser les utilisateurs à se reconnecter.
    </para>
   </listitem>
  </orderedlist>
   </para>

   <para>
    Le point clé de tout ceci est l'écriture d'un fichier de commandes de
    récupération qui décrit comment et jusqu'où récupérer. Le fichier 
    <filename>recovery.conf.sample</filename> (normalement présent dans le
    répertoire d'installation <filename>share/</filename>) peut être utilisé
    comme prototype. La seule chose qu'il faut absolument préciser dans
    <filename>recovery.conf</filename>, c'est <varname>restore_command</varname>
    qui indique à <productname>PostgreSQL</productname> comment récupérer les
    fichiers de segment WAL archivés. À l'instar 
    d'<varname>archive_command</varname>, c'est une chaîne de commande
    shell. Elle peut contenir <literal>%f</literal>, qui est
    remplacé par le nom du journal souhaité, et <literal>%p</literal>, qui est
    remplacé par le chemin du répertoire où copier le journal.
    (Le nom du chemin est relatif au répertoire de travail du serveur,
    c'est-à-dire le répertoire des données du cluster.) Pour écrire le
    caractère <literal>%</literal> dans la commande, on utilise
    <literal>%%</literal>. La commande la plus simple ressemble à&nbsp;:
<programlisting>restore_command = 'cp /mnt/serveur/répertoire_archive/%f %p'</programlisting>
    qui copie les segments WAL précédemment archivés à partir du répertoire
    <filename>/mnt/serveur/répertoire_archive</filename>.  Il est toujours
    possible d'utiliser une commande plus compliquée, voire même un script shell
    qui demande à l'utilisateur de monter la cassette appropriée.
   </para>

   <para>
    Il est important que la commande retourne un code de sortie différent de
    zéro en cas d'échec. Des journaux absents de l'archive
    <emphasis>seront</emphasis> demandés à la commande&nbsp;; elle doit
    renvoyer autre chose que
    zéro dans ce cas. Ce n'est pas une condition d'erreur. Il faut également
    garder à l'esprit que le nom de base du chemin <literal>%p</literal>
    diffère de <literal>%f</literal>&nbsp;; il ne sont pas interchangeables.
   </para>

   <para>
    Les segments WAL qui ne se trouvent pas dans l'archive sont
    recherchés dans <filename>pg_xlog/</filename>&nbsp;; cela autorise l'utilisation
    de segments récents non archivés. Néanmoins, les segments disponibles
    dans l'archive sont utilisés de préférence aux fichiers contenus dans
    <filename>pg_xlog/</filename>. Le système ne surcharge pas le contenu
    de <filename>pg_xlog/</filename> lors de la récupération des fichiers archivés.
   </para>

   <para>
    Normalement, la récupération traite tous les segments WAL disponibles,
    restaurant du coup la base de données à l'instant présent (ou aussi proche
    que possible, en fonction des segments WAL disponibles). Une
    récupération normale se finit avec un message <quote>fichier non
    trouvé</quote>, le texte exact du message d'erreur dépendant du
    choix de <varname>restore_command</varname>. Un message d'erreur au
    début de la récupération peut également apparaître concernant un fichier nommé
    dont le nom ressemble à <filename>00000001.history</filename>. Ceci est aussi normal et
    n'indique par un problème dans les situations de récupération habituelles. Voir
    <xref linkend="backup-timelines"/> pour plus d'informations.
   </para>

   <para>
    Pour récupérer à un moment précis (avant
    que le DBA junior n'ait supprimé la table principale), il suffit d'indiquer le
    point d'arrêt requis dans <filename>recovery.conf</filename>. Le
    point d'arrêt, aussi nommé <quote>recovery
    target</quote> (cible de récupération), peut être précisé par une
    combinaison date/heure ou par le dernier identifiant de transaction. Actuellement, seule
    l'option date/heure est vraiment utilisable car il n'existe pas d'outils
    permettant d'identifier avec précision l'identifiant de transaction
    à utiliser.
   </para>

   <note>
     <para>
      Le point d'arrêt doit être postérieur à la fin de la sauvegarde
      de la base (le moment où <function>pg_stop_backup</function> a été
      exécuté). Une sauvegarde ne peut pas être utilisée pour repartir d'un
      instant où elle était encore en cours (pour ce faire,
      il faut récupérer la sauvegarde précédente et rejouer à partir de là).
     </para>
    </note>

   <para>
    Si la récupération fait face à une corruption des données WAL,
    elle se termine à ce point et le serveur ne démarre pas. Dans un tel cas,
    le processus de récupération peut alors être ré-exécuté à partir du début
    en précisant une <quote>cible de récupération</quote> antérieure au point de
    récupération pour permettre à cette dernière de se terminer correctement.
    Si la récupération échoue pour une raison externe (arrêt brutal du système
    ou archive WAL devenue inaccessible), la récupération peut être
    simplement relancée. Elle redémarre alors quasiment là où elle a échoué.
    Le redémarrage de la restauration fonctionne comme les points de
    contrôle du déroulement normal&nbsp;: le serveur force une écriture
    régulière de son état sur les disques et actualise alors le fichier
    <filename>pg_control</filename> pour indiquer que les données WAL déjà
    traitées n'ont plus à être parcourues.
   </para>

    <sect3 id="recovery-config-settings" xreflabel="Configuration de la récupération">
     <title>Configuration de la récupération</title>

     <para>
      Ces paramètres de configuration ne peuvent être placées que dans le fichier
      <filename>recovery.conf</filename> et s'appliquent uniquement pour la durée de la
      récupération. Ils doivent être réinitialisés avant toute récupération
      ultérieure. Ils ne peuvent pas être modifiés après le démarrage de la récupération.
     </para>

     <variablelist>

     <varlistentry id="restore-command" xreflabel="restore_command">
      <term><varname>restore_command</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        La commande shell à exécuter pour récupérer un segment archivé de la
        série de fichiers WAL. Ce paramètre est requis. Tout <literal>%f</literal>
        dans la chaîne est remplacé par le nom du fichier à récupérer à
        partir de l'archive. Tout <literal>%p</literal> est remplacé par le
        chemin vers le répertoire de copie sur le serveur. (Le nom du chemin
        est relatif au répertoire de travail du serveur, c'est-à-dire le
        répertoire des données du cluster.)
        Tout <literal>%r</literal> est remplacé par le nom du fichier contenant
	le dernier point de redémarrage valide. C'est le premier fichier à
	conserver pour permettre à une restauration d'être redémarrable, donc
	cette information peut être utilisée pour tronquer l'archive au
	minimum nécessaire pour supporter le redémarrage de la restauration
	en cours. <literal>%r</literal> n'est utilisé que dans le cas
	d'une configuration avec un serveur de secours (voir <xref
        linkend="warm-standby"/>).
        <literal>%%</literal> est utilisé pour écrire le
        caractère <literal>%</literal> dans la commande.
       </para>
       <para>
        Il est impératif que la commande ne renvoie un code de sortie zéro
	que si, et seulement si, elle a réussi. Des noms de fichiers absents
	de l'archive <emphasis>seront demandés</emphasis> à la commande&nbsp;; elle
        doit renvoyer une valeur différente de zéro dans ce cas.
        Exemples&nbsp;:
<programlisting>restore_command = 'cp /mnt/serveur/reparchives/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows</programlisting>
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="recovery-target-time" xreflabel="recovery_target_time">
      <term><varname>recovery_target_time</varname> (<type>timestamp</type>)
      </term>
      <listitem>
       <para>
        L'estampille temporelle au-delà de laquelle arrêter
        la récupération. Seul un des deux paramètres
        <varname>recovery_target_time</varname> et
	<xref linkend="recovery-target-xid"/> peut être précisé. Par défaut, la
        récupération court jusqu'à la fin du journal WAL. Le point
        d'arrêt précis est aussi influencé par
	<xref linkend="recovery-target-inclusive"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="recovery-target-xid" xreflabel="recovery_target_xid">
      <term><varname>recovery_target_xid</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        L'ID de la transaction à laquelle arrêter la récupération.
        Alors que les ID de transactions sont affectés
        séquentiellement au début de la transaction, les transactions peuvent
        se terminer dans un ordre numérique différent. Les transactions qui
        sont récupérées sont celles qui ont été validées avant celle
        indiquée (quelques fois en l'incluant). Seul un des deux
	paramètres <varname>recovery_target_xid</varname> et
	<xref linkend="recovery-target-time"/> peut être indiqué. Par
        défaut, la récupération court jusqu'à la fin du journal WAL. Le point
        d'arrêt précis est aussi influencé par
        <xref linkend="recovery-target-inclusive"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="recovery-target-inclusive" xreflabel="recovery_target_inclusive">
      <term><varname>recovery_target_inclusive</varname> (<type>boolean</type>)
      </term>
      <listitem>
       <para>
        Ce paramètre indique si la récupération doit s'arrêter immédiatement
	après la cible de récupération précisée (<literal>true</literal>)
	ou juste avant (<literal>false</literal>). Il s'applique à
	<xref linkend="recovery-target-time"/> et
	<xref linkend="recovery-target-xid"/>, en fonction de celui qui est
	indiqué pour cette récupération. Il indique si les transactions
	d'instant ou ID cible de validation exact, respectivement,
        sont incluses dans la récupération. La valeur par défaut est
        <literal>true</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="recovery-target-timeline" xreflabel="recovery_target_timeline">
      <term><varname>recovery_target_timeline</varname> (<type>string</type>)
      </term>
      <listitem>
       <para>
        La ligne temporelle 
	(<foreignphrase>timeline</foreignphrase>) à utiliser pour la
	récupération. Par défaut, la récupération s'effectue en utilisant la
	ligne temporelle en cours au moment de la sauvegarde. Ce paramètre
	ne doit être configuré que
	pour les situations de récupération complexes, dans lesquelles
	il est nécessaire de retourner à un état postérieur à une récupération
	d'instantané. Voir la <xref linkend="backup-timelines"/> pour plus
	d'informations.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="log-restartpoints" 
                   xreflabel="log_restartpoints">
      <term><varname>log_restartpoints</varname> 
        (<type>boolean</type>)
      </term>
      <listitem>
       <para>
	Indique si chaque point de redémarrage doit être tracé. Cela peut être
	utile pour suivre la progression d'une restauration longue.
	<literal>false</literal> par défaut.
       </para>
      </listitem>
     </varlistentry>

   </variablelist>

   </sect3>

  </sect2>

<!-- ICI -->
  <sect2 id="backup-timelines">
   <title>Lignes temporelles (<foreignphrase>Timelines</foreignphrase>)</title>

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

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

   <para>
    La possibilité de restaurer la base de données à partir d'un instantané
    crée une complexité digne des histoires de science-fiction traitant
    du voyage dans le temps et des univers parallèles.
   </para>
   <para>
    Dans l'historique
    original de la base de données, une table critique a peut-être été
    supprimée à 17h15 mardi soir, mais personne n'a réalisé cette erreur
    avant mercredi midi. Sans stress, la sauvegarde est récupérée
    et restaurée dans l'état où elle se trouvait à 17h14 mardi soir. La base
    est fonctionnelle. Dans <emphasis>cette</emphasis> histoire de l'univers de la base de
    données, la table n'a jamais été supprimée. Or, l'utilisateur
    réalise peu après que ce n'était pas une si grande idée et veut
    revenir à un quelconque moment du mercredi matin. Cela n'est pas possible,
    si, alors que la base de données est de nouveau fonctionnelle, elle
    réutilise certaines séquences de fichiers WAL qui permettent de
    retourner à ce point. Il est donc nécessaire de pouvoir distinguer les
    séries d'enregistrements WAL engendrées après la récupération de
    l'instantané de celles issues de l'historique originel de la base.
   </para>

   <para>
    Pour gérer ces difficultés, <productname>PostgreSQL</productname> inclut
    la notion de <firstterm>lignes temporelles</firstterm> (ou
    <foreignphrase>timelines</foreignphrase>). Quand une récupération
    d'archive est terminée, une nouvelle ligne temporelle est créée pour
    identifier la série d'enregistrements WAL produits après cette
    restauration. Le numéro d'identifiant de la timeline est inclus dans le
    nom des fichiers de segment WAL. De ce fait, une nouvelle timeline
    ne réécrit pas sur les données engendrées par des timelines précédentes.
    En fait, il est possible d'archiver plusieurs timelines différentes.
    Bien que cela semble être une fonctionnalité inutile, cela peut parfois
    sauver des vies. Dans une situation où l'instantané à récupérer n'est
    pas connu avec certitude, il va falloir tester les récupérations de
    différents instantanés jusqu'à trouver le meilleur.
    Sans les timelines, ce processus engendre vite un bazar ingérable. 
    Avec les timelines, il est possible de récupérer
    <emphasis>n'importe quel</emphasis> état précédent, même les états de
    branches temporelles abandonnées.
   </para>

   <para>
    Chaque fois qu'une nouvelle timeline est créée,
    <productname>PostgreSQL</productname> crée un fichier
    d'<quote>historique des timelines</quote> qui indique à quelle timeline
    il est attaché, et depuis quand. Ces fichiers d'historique sont
    nécessaires pour permettre au système de choisir les bons fichiers de
    segment WAL lors de la récupération à partir d'une archive qui contient
    plusieurs timelines. Ils sont donc archivés comme tout fichier
    de segment WAL. Puisque ce sont de simples fichiers texte,
    il est peu coûteux et même judicieux de les conserver indéfiniment
    (contrairement aux fichiers de segment, volumineux). Il est possible
    d'ajouter des commentaires au fichier d'historique expliquant 
    comment et pourquoi cette timeline a été créée. De tels commentaires
    s'avèrent précieux lorsque l'expérimentation conduit à de nombreuses
    timelines.
   </para>

   <para>
    Par défaut, la récupération s'effectue sur la timeline en vigueur au
    cours de la la sauvegarde. Si l'on souhaite effectuer la récupération
    dans une timeline fille (c'est-à-dire retourner à un état enregistré
    après une tentative de récupération), il faut préciser l'identifiant de la timeline
    dans <filename>recovery.conf</filename>. Il n'est pas possible de
    récupérer dans des timelines antérieures à la sauvegarde.
   </para>
  </sect2>

  <sect2 id="backup-tips">
   <title>Conseils et exemples</title>

   <para>
    Quelques conseils de configuration de l'archivage continue sont donnés
    ici.
   </para>

    <sect3 id="backup-standalone">
     <title>Configuration de la récupération</title>

     <para>
      Il est possible d'utiliser les capacités de sauvegarde de
      <productname>PostgreSQL</productname>
      pour produire des sauvegardes autonomes à chaud. Ce sont des
      sauvegardes qui ne peuvent pas être utilisées pour la récupération
      à un instant donné, mais ce sont des sauvegardes qui sont typiquement
      plus rapide à obtenir et à restaurer que
      ceux issus de <application>pg_dump</application>. (Elles sont aussi bien
      plus volumineuses qu'un export <application>pg_dump</application>, il se
      peut donc que l'avantage de rapidité soit négatif.)
     </para>

     <para>
      En vue d'effectuer des sauvegardes à chaud autonomes, on positionne
      <varname>archive_mode</varname> à <literal>on</literal>, et on configure
      <varname>archive_command</varname> de telle sorte que l'archivage ne soit
      réalisé que lorsqu'un <quote>fichier de bascule</quote> existe. Par
      exemple&nbsp;:
<programlisting>
archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f &amp;&amp; cp %p /var/lib/pgsql/archive/%f)'
</programlisting>
      Cette commande réalise l'archivage dès lors que
      <filename>/var/lib/pgsql/backup_in_progress</filename> existe. Dans le
      cas contraire, elle
      renvoie silencieusement le code de statut zéro (permettant à
      <productname>PostgreSQL</productname> de recycler le journal de
      transactions non désiré).
     </para>

     <para>
      Avec cette préparation, une sauvegarde peut être prise en utilisant un
      script comme celui-ci&nbsp;:
<programlisting>
touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
sleep 20
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
</programlisting>
      Le fichier de bascule,
      <filename>/var/lib/pgsql/backup_in_progress</filename>, est créé en
      premier, activant l'archivage des journaux de transactions pleins.
      Après la sauvegarde, le fichier de bascule est supprimé. Les journaux
      de transaction archivés sont ensuite ajoutés à la sauvegarde pour que
      la sauvegarde de base et les journaux requis fassent partie du même
      fichier <application>tar</application>.
     </para>
    </sect3>

    <sect3 id="backup-scripts">
     <title>Scripts <varname>archive_command</varname></title>

     <para>
      Nombreux sont ceux qui choisissent d'utiliser
      des scripts pour définir leur <varname>archive_command</varname>, de
      sorte que leur <filename>postgresql.conf</filename> semble très simple&nbsp;:
<programlisting>
archive_command = 'local_backup_script.sh "%p" "%f"'
</programlisting>
      Utiliser un script séparé est conseillé à chaque fois qu'il est envisagé
      d'utiliser plusieurs commandes pour le processus d'archivage.
      Ainsi toute la complexité est gérée dans le script qui peut être
      écrit dans un langage de scripts populaires comme
      <application>bash</application> ou <application>perl</application>.
      Tout message écrit sur <literal>stderr</literal> à partir du script
      apparaîtra dans les journaux applicatifs de la base de données, cela
      permettant aux configurations complexes d'être diagnostiquées facilement
      en cas d'échec.
     </para>
     <para>
      Quelques exemples de besoins résolus dans
      un script&nbsp;:
      <itemizedlist>
       <listitem>
        <para>
         copier des données vers un stockage distant&nbsp;;
        </para>
       </listitem>
       <listitem>
        <para>
         copier les journaux de transaction en groupe pour qu'ils soient
	 transférés toutes les trois heures plutôt qu'un à la fois&nbsp;;
        </para>
       </listitem>
       <listitem>
        <para>
         s'interfacer avec d'autres outils de sauvegarde et de
	 récupération&nbsp;;
        </para>
       </listitem>
       <listitem>
        <para>
         s'interfacer avec un outil de surveillance pour y renvoyer
	 les erreurs.
        </para>
       </listitem>
      </itemizedlist>
     </para>
    </sect3>
  </sect2>

  <sect2 id="continuous-archiving-caveats">
   <title>Restrictions</title>

   <para>
    Au moment où ces lignes sont écrites, plusieurs limitations
    de la technique d'achivage continu sont connues. Elles seront probablement
    corrigées dans une prochaine version&nbsp;:

  <itemizedlist>
   <listitem>
    <para>
     Les opérations sur les index de hachage
     ne sont pas tracées dans les WAL. Ces index
     ne sont donc pas actualisés lorsque la sauvegarde est rejouée. Pour
     cela, il est recommandé d'utiliser la commande 
     <xref linkend="sql-reindex" endterm="sql-reindex-title"/> sur chacun
     des index à la fin de la récupération.
    </para>
   </listitem>

   <listitem>
    <para>
     Si une commande
     <xref linkend="sql-createdatabase" endterm="sql-createdatabase-title"/>
     est exécutée alors qu'une sauvegarde est en cours, et que la base de données
     modèle utilisée par l'instruction <command>CREATE DATABASE</command>
     est à son tour modifiée pendant la sauvegarde, il est
     possible que la récupération propage ces modifications
     dans la base de données créée. Pour éviter ce risque, il est préférable de
     ne pas modifier les bases de données modèle lors d'une sauvegarde de base.
    </para>
   </listitem>

   <listitem>
    <para>
     Les commandes
     <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"/>
     sont tracées dans les WAL avec le chemin absolu et sont donc rejouées
     en tant que créations de <foreignphrase>tablespace</foreignphrase>
     suivant le même chemin absolu. Cela n'est pas forcément souhaitable si
     le journal est rejouée sur une autre machine.
     De plus, cela peut s'avérer dangereux même lorsque le journal est rejoué sur la
     même machine, mais dans un répertoire différent&nbsp;: la ré-exécution surcharge
     toujours le contenu du <foreignphrase>tablespace</foreignphrase> original.
     Pour éviter de tels problèmes, la meilleure solution consiste à
     effectuer une nouvelle sauvegarde de la base après la création ou la
     suppression de <foreignphrase>tablespace</foreignphrase>.
    </para>
   </listitem>
  </itemizedlist>
   </para>

   <para>
    Il faut de plus garder à l'esprit que le format actuel des
    <acronym>WAL</acronym> est extrêmement volumineux car il inclut
    de nombreuses images des pages disques. Ces images de page sont conçues
    pour supporter la récupération après un arrêt brutal, puisqu'il peut
    être nécessaire de corriger des pages disque partiellement écrites.
    En fonction du matériel et des logiciels composant le système, 
    le risque d'écriture partielle peut être
    suffisamment faible pour être ignoré, auquel cas le volume total des
    traces archivées peut être considérablement réduit par la désactivation
    des images de page à l'aide du paramètre <xref linkend="guc-full-page-writes"/>
    (lire les notes et avertissements dans <xref linkend="wal"/> avant
    de le faire). Désactiver les images de page n'empêche pas l'utilisation des
    traces pour les opérations PITR. Un piste éventuelle de développement
    futur consiste à compresser les données des WAL archivés en supprimant les copies
    inutiles de pages même si <varname>full_page_writes</varname> est actif. Entre
    temps, les administrateurs peuvent souhaiter réduire le nombre
    d'images de pages inclus dans WAL en augmentant autant que possible les
    paramètres d'intervalle entre les points de vérification.
   </para>
  </sect2>
 </sect1>

<!-- Hot Standby : secours automatique ou reprise immédiate
     Warm standby : secours semi-automatique ou reprise intermédiaire-->
 <sect1 id="warm-standby">
  <title>Serveurs de secours semi-automatique (<foreignphrase>Warm Standby</foreignphrase>) pour la haute disponibilité</title>

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

  <indexterm zone="backup">
   <primary>secours semi-automatique</primary>
  </indexterm>

  <indexterm zone="backup">
   <primary>reprise intermédiaire</primary>
  </indexterm>

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

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

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

  <indexterm zone="backup">
   <primary>serveur de secours</primary>
  </indexterm>

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

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

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

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

  <indexterm zone="backup">
   <primary>haute disponibilité</primary>
  </indexterm>

  <para>
   L'archivage continu peut être utilisé pour créer une configuration de cluster
   de <firstterm>haute disponibilité</firstterm> (HA) avec un (ou plusieurs)
   <firstterm>serveur(s) de secours</firstterm>, prêt(s) à prendre en main les
   opérations en cas de défaillance du serveur principal. Cette fonctionnalité
   est surtout connue sous le nom de
   <firstterm><foreignphrase>Warm Standby</foreignphrase></firstterm> ou
   <firstterm><foreignphrase>Log Shipping</foreignphrase></firstterm>.
  </para>

  <para>
   Le serveur principal et le serveur de secours travaillent ensemble pour
   fournir cette capacité, bien que les serveurs soient très faiblement couplés.
   Le serveur principal opère en mode d'archivage continu alors que chaque
   serveur de secours opère en mode de récupération continue en lisant
   les fichiers WAL du serveur primaire. Aucune modification des tables
   de la base n'est requise pour activer cette capacité. Elle a de ce fait
   un coût modique en terme d'administration supplémentaire en comparaison avec
   d'autres approches de réplication. Cette configuration a également un impact
   relativement faible sur les performances du serveur principal.
  </para>

  <para>
   Le déplacement direct des enregistrements des WAL d'une base à
   une autre est généralement appelé <quote>transfert de journaux</quote>
   (<foreignphrase>log shipping</foreignphrase>).
   Sous <productname>PostgreSQL</productname>, c'est un transfert de
   fichiers, de sorte que les enregistrements
   WAL sont transférés fichier par fichier. Les fichiers WAL peuvent être envoyés
   facilement et sans surcoût quelque soit la distance, que ce soit sur un
   système adjacent, sur un autre système du même site ou sur un autre système
   de l'autre côté du globe. La bande passante requise par cette technique
   varie en fonction du taux de transaction du serveur principal.
   Le transfert de journaux par enregistrement 
   (<foreignphrase>record-based log shipping</foreignphrase>) est également
   réalisable, à l'aide de procédures personnalisées, discutées dans
   <xref linkend="warm-standby-record"/>.
  </para>

  <para>
   L'envoi des journaux est asynchrone, ce qui signifie que les enregistrements
   WAL sont envoyés après validation de la transaction. De ce fait, il y a un
   léger risque de perte de données si le serveur principal est l'objet d'une
   panne catastrophique&nbsp;: les transactions qui ne sont pas encore
   transmises sont perdues. La taille de la fenêtre des données perdues peut
   être réduite par l'utilisation du paramètre
   <varname>archive_timeout</varname>. Celui-ci peut être positionné à une
   valeur de quelques secondes seulement, si nécessaire. Toutefois, une
   valeur aussi faible augmente considérablement les besoins en bande
   passante du transfert de fichiers. Si une valeur aussi basse est
   nécessaire, il peut être préférable de s'intéresser au transfert de
   journaux par enregistrement. 
  </para>

  <para>
   Le serveur de secours n'est pas accessible, car il est en permanence
   occupé par la récupération. Les performances de récupération
   sont suffisamment bonnes pour que l'attente soit réduite 
   avant d'obtenir une disponibilité complète une fois le serveur de secours
   activé. En conséquence, on appelle cela une configuration de reprise
   intermédiaire ou de secours semi-automatique
   (<foreignphrase>warm standby</foreignphrase>), qui permet d'atteindre la
   haute disponibilité.
   La restauration d'un serveur à partir d'une sauvegarde archivée de la
   base et de la relecture des journaux prend considérablement plus de temps.
   Cette technique n'offre qu'une solution de récupération suite à une panne,
   mais pas de la haute disponibilité.
  </para>

  <sect2 id="warm-standby-planning">
   <title>Planification</title>

   <para>
    Il est généralement préférable de créer des serveurs primaire et de
    secours aussi semblables que possible, au moins du point de
    vue du serveur de bases de données. En particulier, les noms des chemins
    associés aux <foreignphrase>tablespaces</foreignphrase> sont passés tels
    quels. Les serveurs doivent donc, tous, posséder les mêmes chemins de
    montage des <foreignphrase>tablespaces</foreignphrase> si cette fonctionnalité
    est utilisée. Si
    <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"/>
    est exécuté sur le serveur principal, tout nouveau point de montage
    nécessaire doit être créé à la fois sur le serveur principal et sur tous les
    serveurs de secours, avant l'exécution de la commande.
    Le matériel ne doit pas obligatoirement être identique mais l'expérience
    prouve qu'il est plus facile de maintenir deux systèmes identiques
    sur la durée de vie de l'application et du système. Dans tous les cas,
    l'architecture du matériel doit être identique
    &mdash; le transfert d'un système 32 bits à un 64 bits ne fonctionne pas.
   </para>

  <para>
   En général, il n'est pas possible d'effectuer le transfert de journaux
   entre serveurs <productname>PostgreSQL</productname> de versions majeures différentes. La politique des
   développeurs du
   <quote>PostgreSQL Global Development Group</quote> consiste à ne pas
   modifier les formats disque lors de mises à jour mineures. De ce fait, il
   est possible d'utiliser des serveurs principal et de secours de versions
   mineures différentes. Toutefois, aucune garantie formelle n'est offerte à
   ce sujet. Il est préférable, dans la mesure du possible, de conserver les
   serveurs
   primaire et de secours au même niveau de version. Lors de la mise à jour
   vers une nouvelle version mineure, la meilleure politique est de mettre
   à jour les serveurs de secours en premier &mdash; il y a plus de chances
   qu'une version mineure sache lire les fichiers WAL d'une version mineure
   précédente que le contraire.
  </para>

  <para>
    Il n'y a pas de mode particulier requis pour activer un serveur de
    secours.
    Les seules opérations sur les serveurs principal et de secours
    sont des tâches normales d'archivage continu et de récupération.
    Le seul point de contact entre les deux serveurs est
    l'archive de fichiers WAL qu'ils partagent&nbsp;: le principal les
    écrit, le serveur de secours les lit. Il est impératif que des
    archives WAL de serveurs primaires différents ne soient pas mélangées.
    L'archive n'est pas nécessairement large, si elle ne sert qu'à
    l'opération de standby.
   </para>

   <para>
    La magie qui permet à deux serveurs faiblement liés de travailler
    ensemble réside dans une simple <varname>restore_command</varname>
    utilisée sur le serveur de secours qui attend la disponibilité du
    prochain fichier WAL en provenance du serveur principal.
    <varname>restore_command</varname> est indiqué dans le fichier
    <filename>recovery.conf</filename> du serveur de secours.
    En fonctionnement normal, le processus de récupération attend un fichier
    dans l'archive WAL, remontant une erreur si le fichier est indisponible.
    Dans le cas du serveur de secours, il est normal que le fichier suivant
    n'existe pas. Il ne reste donc
    qu'à attendre son arrivée. Une <varname>restore_command</varname>
    d'attente peut être obtenue par l'écriture d'un script personnalisé
    qui boucle sur un test d'apparition du prochain fichier WAL. Il faut
    également définir un moyen de déclencher la bascule
    (<foreignphrase>failover</foreignphrase>), ce qui interrompt la
    <varname>restore_command</varname>, sort de la boucle et retourne une
    erreur au serveur de secours indiquant que le fichier n'a pas été
    trouvé. Cela arrête alors la récupération et le serveur de secours devient
    un serveur normal.
   </para>
   
   <para>
    Un exemple de pseudocode de <varname>restore_command</varname>
    peut être&nbsp;:
<programlisting>triggered = false;
while (!NextWALFileReady() &amp;&amp; !triggered)
{
    sleep(100000L);         /* wait for ~0.1 sec */
    if (CheckForExternalTrigger())
        triggered = true;
}
if (!triggered)
        CopyWALFileForRecovery();
</programlisting>
   </para>

   <para>
    Un exemple fonctionnel de <varname>restore_command</varname> 
    d'attente est fourni dans un module <filename>contrib</filename> appelé
    <application>pg_standby</application>. Cet exemple peut être étendu
    si nécessaire pour supporter des configurations ou environnements
    spécifiques.
   </para>

   <para>
    <productname>PostgreSQL</productname> ne fournit pas de logiciel 
    système qui permette d'identifier une panne du serveur principal et d'en
    notifier le système et le serveur de bases de données de secours.
    De nombreux outils de ce type existent et sont bien intégrés incluant d'autres
    aspects nécessaires à la réussite du
    <foreignphrase>failover</foreignphrase>, comme la migration d'adresse IP.
   </para>

   <para>
    Le déclenchement du <foreignphrase>failover</foreignphrase> est une partie
    importante de la planification et de la conception.
    <varname>restore_command</varname> est
    exécutée complètement pour chaque fichier WAL. Le processus
    exécutant <varname>restore_command</varname> est du coup créé et meurt
    pour chaque fichier. Il n'y a, de ce fait, pas de démon ou de processus
    serveur. Il n'est donc pas possible d'utiliser les signaux et un
    gestionnaire de signal. Une notification plus permanente est requise pour
    le déclenchement du <foreignphrase>failover</foreignphrase>. Il est
    possible d'utiliser un simple dépassement de temps d'attente,
    spécialement en conjonction avec un paramètre
    <varname>archive_timeout</varname> défini sur le serveur principal et
    connu. Cela peut toutefois induire des erreurs, car un problème réseau ou
    l'occupation du serveur principal peuvent suffire à provoquer
    un <foreignphrase>failover</foreignphrase>. Un mécanisme de notification
    tel que la création explicite d'un fichier déclencheur, quand cela est
    possible, présente moins de risques d'erreur.
   </para>

   <para>
    La taille de l'archive des journaux de transaction peut être minimisée en passant l'option
    <literal>%r</literal> à <varname>restore_command</varname>. Cette option
    indique le dernier fichier archive à conserver pour permettre un démarrage
    correct de la restauration. Cela peut être utilisé pour tronquer l'archive
    lorsque les fichiers ne sont plus nécessaires, s'il est possible d'écrire
    sur l'archive depuis le serveur de secours.
   </para>
  </sect2>

  <sect2 id="warm-standby-config">
   <title>Mise en place</title>

   <para>
    Une procédure courte de configuration d'un serveur de secours est
    indiquée dans la suite du document. Pour
    les détails complets de chaque étape, on peut se référer aux sections précédentes.
    <orderedlist>
     <listitem>
      <para>
       Préaparer des configurations des serveurs principal et de secours
       aussi proches que possible, 
       ce qui inclut deux copies identiques de <productname>PostgreSQL</productname>,
       dans la même version.
      </para>
     </listitem>
     <listitem>
      <para>
       Configurer l'archivage continu sur le serveur principal vers une archive locale
       située dans un répertoire du serveur de secours. S'assurer que les
       paramètres <xref linkend="guc-archive-mode"/>, 
       <xref linkend="guc-archive-command"/> et
       <xref linkend="guc-archive-timeout"/> sont correctement configurés
       sur le serveur principal (voir <xref linkend="backup-archiving-wal"/>).
      </para>
     </listitem>
     <listitem>
      <para>
       Faire une sauvegarde des bases du serveur principal (voir <xref
       linkend="backup-base-backup"/>) et charger ces données sur le serveur
       de secours.
      </para>
     </listitem>
     <listitem>
      <para>
       Commencer la récupération sur le serveur de secours à partir de l'archive
       WAL locale en utilisant un fichier <filename>recovery.conf</filename>
       qui utilise une <varname>restore_command</varname> d'attente (voir
       <xref linkend="backup-pitr-recovery"/>).
      </para>
     </listitem>
    </orderedlist>
   </para>

   <para>
    La récupération traite l'archive WAL en lecture seule. Ainsi, dès lors
    qu'un fichier WAL est copié sur le système de secours, il peut être
    copié sur une cassette en même temps qu'il est lu pour la
    récupération. De ce fait, un serveur de secours 
    de haute disponibilité peut tourner en parallèle du
    stockage des fichiers en vue de besoins de reprise sur panne à plus long
    terme.
   </para>

   <para>
    Pour les tests, il est possible d'exécuter le serveur principal
    et celui de secours sur le même système. Cela n'apporte aucune amélioration
    à la robustesse du système, et ne peut pas être présenté comme
    de la haute disponibilité.
   </para>
  </sect2>

  <sect2 id="warm-standby-failover">
   <title>Bascule (<foreignphrase>Failover</foreignphrase>)</title>

   <para>
    Si le serveur principal rencontre un problème, le serveur de secours doit commencer
    la procédure de <foreignphrase>failover</foreignphrase>.
   </para>

   <para>
    Si le serveur de secours échoue, alors le 
    <foreignphrase>failover</foreignphrase> n'est plus nécessaire.
    S'il peut être redémarré, même quelque temps après, alors le
    processus de récupération peut être immédiatement relancé en tirant
    parti de la restauration réactivable (<foreignphrase>Restartable
    Recovery</foreignphrase>). Enfin, s'il ne peut être redémarré, un
    nouveau serveur de secours doit être créé.
   </para>

   <para>
    Si le serveur principal tombe et redémarre immédiatement, il faut
    disposer d'un mécanisme l'informant qu'il n'est plus le serveur
    principal. Ce mécanisme, connu sous l'acronyme <acronym>STONITH</acronym>
    (<foreignphrase>Shoot The Other Node In The Head</foreignphrase>), 
    permet d'éviter les situations où les deux systèmes pensent qu'ils sont
    le serveur principal, ce qui engendrerait une certaine confusion et
    conduirait à des pertes irrémédiables de données.
   </para>

   <para>
    Un grand nombre de systèmes de <foreignphrase>failover</foreignphrase>
    utilisent simplement deux systèmes, le principal et celui de secours,
    connectés par un mécanisme appelé <quote>heartbeat</quote> qui vérifie
    en permanence la connectivité entre les deux systèmes et la viabilité
    du principal. Il est aussi possible d'utiliser un troisième système,
    appelé serveur témoin pour éviter tout problème de
    <foreignphrase>failover</foreignphrase> inapproprié. Cependant, 
    la complexité supplémentaire peut s'avérer inutile sauf s'il
    est configuré avec une attention suffisante et des tests rigoureux.
   </para>

   <para>
    Au moment où le <foreignphrase>failover</foreignphrase> est mis en place sur le
    serveur de secours, un seul serveur est opérationnel. On parle alors
    d'état dégénéré. L'ancien serveur de secours est
    devenu serveur principal, mais l'ancien serveur principal est arrêté
    et peut le rester. Pour revenir au fonctionnement normal, il faut
    désormais recréer intégralement un serveur de secours, soit
    sur l'ancien système principal, s'il peut redémarrer, soit sur un
    troisième système, de préférence nouveau. Cela réalisé, on
    peut considérer que les deux serveurs ont échangé leurs rôles.
   </para>
   <para>
    Certains administrateurs choisissent d'utiliser un troisième serveur
    pour servir de sauvegarde au nouveau serveur principal le temps que le
    serveur de secours devienne opérationnel. Toutefois, cela complique
    la configuration du système et des processus opérationnels.
   </para>

   <para>
    La bascule entre le serveur principal et celui de secours peut être
    rapide, mais nécessite quelque temps pour repréparer le cluster de 
    <foreignphrase>failover</foreignphrase>. Une bascule régulière
    est utile car elle permet l'arrêt régulier de chaque système pour
    maintenance.
    Cela permet également de tester les mécanismes de
    <foreignphrase>failover</foreignphrase> pour s'assurer que cela
    fonctionnera toujours en cas de besoin. Il est judicieux de rédiger ces
    procédures.
   </para>
  </sect2>

  <sect2 id="warm-standby-record">
   <title>Transfert de journaux d'après les enregistrements
   (<foreignphrase>Record-based Log Shipping</foreignphrase>)</title>

   <para>
    <productname>PostgreSQL</productname> supporte directement le transfert
    de journaux d'après fichiers (<foreignphrase>file-based
    log shipping</foreignphrase>) tel que décrit plus haut. Il est
    également possible d'implanter le transfert de journaux d'après
    enregistrements, mais cela demande un développement adapté.
   </para>

   <para>
    Un programme externe peut faire appel à la fonction 
    <function>pg_xlogfile_name_offset()</function> (voir à ce propos la
    <xref linkend="functions-admin"/>) pour trouver le nom du fichier et
    l'exact décalage en octets de la fin courante du WAL à l'intérieur de
    celui-ci. Il
    peut alors accéder directement au fichier WAL et copier les données
    depuis la dernière fin connue des WAL jusqu'à l'actuelle vers le(s)
    serveur(s) de secours. Par cette approche, la fenêtre de perte de
    données correspond au temps du cycle d'interrogation du programme
    de copie. Elle peut alors être très courte. Il n'y a, de plus, pas de
    surconsommation de la bande passante du fait de l'archivage de fichiers
    segment partiellement utilisés. Les scripts
    <varname>restore_command</varname> du serveur de secours continuent de
    traiter avec l'ensemble des fichiers WAL. De ce fait, les serveurs de
    secours ne peuvent pas, en fonctionnement normal, disposer des données
    copiées par incréments. Elles n'ont d'intérêt que lorsque le
    serveur principal subit une panne &mdash; le dernier fichier WAL partiel
    est alors chargé dans le serveur de secours avant qu'il puisse démarrer.
    Un codage correct de cette procédure nécessite une réelle coopération
    entre le script de <varname>restore_command</varname> et le programme de
    copie des donneés.
   </para>
  </sect2>

  <sect2 id="backup-incremental-updated">
   <title>Sauvegardes incrémentales</title>

  <indexterm zone="backup">
   <primary>incrementally updated backups</primary>
  </indexterm>

  <indexterm zone="backup">
   <primary>sauvegarde incrémentale</primary>
  </indexterm>

  <indexterm zone="backup">
   <primary>accumulation des modifications</primary>
  </indexterm>

<!-- Le terme accumulation des modifications ne me semble pas très heureux.
-->
   <para>
    Dans une configuration de reprise intermédiaire (<foreignphrase>warm
    standby</foreignphrase>), il est possible de décharger le serveur
    principal du coût des sauvegardes régulières des bases. Les sauvegardes
    des bases peuvent, pour cela, être effectuées en sauvegardant les fichiers
    d'un serveur de secours. Ce concept prend le nom de sauvegardes
    incrémentales, accumulation des journaux de modifications ou
    accumulation des modifications.
   </para>

   <para>
    Si une sauvegarde du répertoire des données du serveur de secours est
    effectuée alors
    qu'il traite les journaux transférés du serveur principal, il est
    possible de recharger ces données et de redémarrer le processus de
    restauration sur le serveur de secours à partir du dernier point de
    redémarrage. Il n'est alors plus nécessaire de conserver les fichiers
    WAL précédant le point de redémarrage. Si une restauration s'avère
    nécessaire, elle est plus rapide si elle est effectuée à partir d'une
    sauvegarde incrémentale qu'à partir de la
    sauvegarde originale.
   </para>

   <para>
    Puisque le serveur de secours n'est pas <quote>actif</quote>, il n'est
    pas possible d'utiliser <function>pg_start_backup()</function> et
    <function>pg_stop_backup()</function> pour gérer le processus de
    sauvegarde&nbsp;; c'est à l'utilisateur de déterminer le nombre de fichiers
    de segment WAL à conserver pour avoir une sauvegarde
    récupérable. Cela peut se faire en exécutant 
    <application>pg_controldata</application> sur le serveur de secours pour
    inspecter le fichier de contrôle et déterminer
    l'emplacement du point de contrôle WAL courant, ou en utilisant l'option 
    <varname>log_restartpoints</varname> pour afficher les valeurs sur les
    traces du serveur.
   </para>
  </sect2>
 </sect1>

 <sect1 id="migration">
  <title>Migration entre versions</title>

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

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

  <para>
   Cette section discute de la façon de migrer les données de la base vers
   une version plus récente de <productname>PostgreSQL</productname>.
   Le sujet de cette section ne concerne pas la procédure d'installation
   <foreignphrase>per se</foreignphrase> du logiciel&nbsp;; ces détails sont
   dans le <xref linkend="installation"/>.
  </para>

  <para>
   En règle générale, le format interne des données est sujet à modification d'une
   version majeure à l'autre (quand le nombre après le premier point change).
   Ce qui n'est pas le cas pour les versions mineures à l'intérieur d'une
   même version majeure (quand seul le nombre après le deuxième point change)&nbsp;;
   elles ont toujours un format de stockage compatible.
   Par exemple, les versions 8.1.1, 8.2.3 et 8.3 ne sont pas compatibles, alors
   que les versions 8.2.3 et 8.2.4 le sont. Lorsque la mise à jour concerne
   des versions compatibles, les exécutables peuvent simplement être
   remplacés et le répertoire des données sur le disque réutilisé. 
   Dans le cas contraire, il faut sauvegarder les données et les restaurer sur
   le nouveau serveur. <application>pg_dump</application> doit être utilisé
   pour cela&nbsp;; les méthodes de
   sauvegarde au niveau système de fichiers ne fonctionnent évidemment pas.
   Un certain nombre de vérifications est automatiquement effectué pour
   interdire l'utilisation d'un répertoire de données d'une version
   incompatible. Il n'y a donc pas grand risque à lancer une mauvaise
   version de <productname>PostgreSQL</productname> sur un répertoire de
   données.
  </para>

  <para>
   Il est recommandé d'utiliser les programmes <application>pg_dump</application> et
   <application>pg_dumpall</application> issus de la nouvelle version de
   <productname>PostgreSQL</productname>. Ceci permet de tirer parti
   des améliorations de ces programmes. Les versions actuelles des
   programmes de sauvegarde peuvent lire des données sur des serveurs
   de versions anciennes, jusqu'à la 7.0.
  </para>

  <para>
   La durée d'indisponibilité est minimisée par l'installation de nouveau serveur
   dans un répertoire différent et par le lancement en parallèle des deux
   serveurs (ancien et nouveau), sur des ports différents. On peut alors
   utiliser une commande telle que&nbsp;:

<programlisting>pg_dumpall -p 5432 | psql -d postgres -p 6543</programlisting>

   pour transférer les données. On peut aussi utiliser un fichier
   intermédiaire. L'ancien serveur peut alors être éteint, et le nouveau
   démarré sur le port utilisé par l'ancien. Il est impératif que la base de
   données ne soit pas modifiée pendant l'exécution de  
   <application>pg_dumpall</application>. Ces modifications seraient, sans
   cela, perdues. Le <xref linkend="client-authentication"/> informe sur la
   façon d'interdire l'accès.
  </para>
  
  <para>
   Il est aussi possible d'utiliser des outils de réplication comme
   <productname>Slony</productname> pour créer un serveur esclave avec la
   nouvelle version de <productname>PostgreSQL</productname>. L'esclave peut
   se trouver sur le même ordinateur ou sur un autre. Une fois qu'il est
   synchronisé avec le serveur maître (utilisant l'ancienne version de
   <productname>PostgreSQL</productname>), le maître et
   l'esclave peuvent être basculés pour que l'esclave devienne le maître.
   L'ancien serveur peut alors être arrêté. Ce basculement intervient en
   quelques secondes dans le cadre d'une mise à jour.
  </para>

  <para>
   En pratique, on souhaite souvent tester son application sur le
   nouveau serveur avant de basculer définitivement. C'est une autre raison
   de configurer des installations concurrentes de l'ancienne et de la nouvelle
   versions.
  </para>

  <para>
   Si n'est pas souhaité, ou pas possible, de lancer les deux serveurs en 
   parallèle, il faut réaliser l'étape de sauvegarde avant d'installer la 
   nouvelle version, éteindre le serveur, déplacer l'ancienne version vers un autre
   endroit, installer la nouvelle, la démarrer et enfin restaurer les données. Par
   exemple&nbsp;:
   
<programlisting>pg_dumpall &gt; sauvegarde.sql
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-&version;
gmake install
initdb -D /usr/local/pgsql/data
postgres -D /usr/local/pgsql/data
psql -f sauvegarde.sql postgres</programlisting>

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

  <note>
   <para>
    Lorsque <quote>l'ancienne installation est déplacée</quote>, 
    il se peut qu'elle ne soit plus correctement utilisable.
    En effet, certains exécutables contiennent des chemins absolus vers les
    différents programmes et fichiers de données installés. Ce n'est
    habituellement pas un problème insurmontable, mais pour utiliser deux
    installations en parallèle pendant un moment, il faut leur affecter des
    répertoires d'installation différents au moment de la construction. (Ce
    problème est rectifié pour <productname>PostgreSQL</productname> 8.0 et
    suivantes tant que tous les sous-répertoires
    contenant des fichiers installées sont déplacés ensemble&nbsp;; par exemple si
    <filename>/usr/local/postgres/bin/</filename> va dans
    <filename>/usr/local/postgres.old/bin/</filename>, alors
    <filename>/usr/local/postgres/share/</filename> doit aller dans
    <filename>/usr/local/postgres.old/share/</filename>. Dans les versions
    antérieures à la 8.0, déplacer une installation comme ceci n'aurait pas
    fonctionné.)
   </para>
  </note>
 </sect1>
</chapter>