Changeset 491

Show
Ignore:
Timestamp:
11/17/06 10:13:07 (2 years ago)
Author:
sas
Message:

Relecture en cours

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/backup.xml

    r489 r491  
    723723   </para> 
    724724 
    725 <!-- ICI --> 
    726    <para> 
    727     Certains outils de sauvegarde que vous souhaiteriez utiliser émettent des 
     725   <para> 
     726    Certains outils de sauvegarde émettent des 
    728727    messages d'avertissements ou d'erreurs si les fichiers qu'ils essaient de 
    729     copier changent lors de la copie. Cette situation est normale, ce n'est pas 
    730     une erreur, lors de la création de la sauvegarde de base d'une base de 
    731     données active&nbsp;; vous devez donc vous assurer que vous pouvez 
    732     distinguer les messages de cette sorte des autres messages. Par exemple, 
    733     certaines versions de <application>rsync</application> renvoient un code de sortie 
    734     séparé pour des <quote>fichiers source disparus</quote>, et vous pouvez écrire 
    735     un script qui accepte ce code de sortie comme un cas normal. De plus, 
    736     certaines versions de GNU <application>tar</application> considèrent que la modification 
     728    copier sont modifiés au cours de la copie. Cette situation, normale lors 
     729    de la sauvegarde d'une base active, ne doit pas être considérée comme  
     730    une erreur&nbsp;; il suffit de s'assurer que ces messages peuvent être 
     731    distingués des autres messages.  
     732    Certaines versions de <application>rsync</application>, par exemple, 
     733    renvoient un code de sortie 
     734    distinct en cas de <quote>disparition de fichiers source</quote>. Il est 
     735    possible d'écrire un script qui considère ce code de sortie comme normal. 
     736    De plus, certaines versions de <application>GNU tar</application> 
     737    considèrent que la modification 
    737738    d'un fichier lors de sa copie par <application>tar</application> est une erreur. Il 
    738     ne semble pas exister de moyen simple pour distinguer cette erreur des autres 
    739     types d'erreurs, autrement qu'en inspectant manuellement les messages de 
    740     <application>tar</application>. Du coup, GNU <application>tar</application> n'est pas le meilleur 
     739    ne semble pas exister de moyen simple de distinguer cette erreur des autres 
     740    types d'erreurs, sinon d'inspecter manuellement les messages de 
     741    <application>tar</application>. De ce fait, GNU <application>tar</application> 
     742    n'est pas le meilleur 
    741743    outil pour réaliser des sauvegardes de base. 
    742744   </para> 
    743745 
    744746   <para> 
    745     Il n'est pas nécessaire d'être très concerné sur le temps passé entre 
     747    Il n'est pas utile d'accorder de l'importance au le temps passé entre 
    746748    <function>pg_start_backup</function> et le début réel de la sauvegarde, pas plus 
    747749    qu'entre la fin de la sauvegarde et <function>pg_stop_backup</function>&nbsp;; un 
    748     délai de quelques minutes ne posera pas de problème. Néanmoins, si vous exécutez 
    749     normalement le serveur en désactivant <varname>full_page_writes</varname>, vous 
    750     pouvez noter une perte de performances entre <function>pg_start_backup</function> 
    751     et <function>pg_stop_backup</function>. Vous devez vous assurer que ces 
    752     opérations de sauvegarde sont effectuées en séquence sans croisement possible. 
    753     Dans le ca contraire, vous invaliderez la sauvegarde. 
    754    </para> 
    755  
    756    <para> 
    757     Assurez-vous que votre sauvegarde inclut tous les fichiers du répertoire 
    758     du groupe de bases de données (c'est-à-dire 
    759     <filename>/usr/local/pgsql/data</filename>). Si vous utilisez des espaces logiques 
    760     qui ne se trouvent pas dans ce répertoire, faites attention à bien les 
    761     inclure (et assurez-vous que votre sauvegarde archive les liens 
    762     symboliques comme des liens, sinon la restauration posera problème pour 
    763     les espaces logiques). 
    764    </para> 
    765  
    766    <para> 
    767     Néanmoins, vous devriez omettre de sauvegarder les fichiers du 
    768     sous-répertoire <filename>pg_xlog/</filename> contenu dans le répertoire du 
    769     groupe. Cette petite complication est intéressante parce qu'elle réduit le 
    770     risque d'erreurs lors de la restauration. Ceci est facile à arranger si 
    771     <filename>pg_xlog/</filename> est un lien symbolique pointant quelque part à 
    772     l'extérieur du répertoire du groupe, ce qui est une configuration commune 
    773     pour des raisons de performance. 
    774    </para> 
    775  
    776    <para> 
    777     Pour utiliser cette sauvegarde, vous aurez besoin de conserver les 
    778     fichiers segments WAL générés pendant ou après le lancement de la 
    779     sauvegarde. Pour vous aider dans ce travail, la fonction  
    780     <function>pg_stop_backup</function> crée un <firstterm>fichier historique de la 
    781     sauvegarde</firstterm> qui est immédiatement stocké dans l'aire des archives WAL. 
     750    délai de quelques minutes ne pose pas de problème. Néanmoins, si le 
     751    serveur est normalement utilisé alors que 
     752    <varname>full_page_writes</varname> est désactivé, une perte de 
     753    performances entre <function>pg_start_backup</function> 
     754    et <function>pg_stop_backup</function> peut être constatée. Il convient 
     755    toutefois de s'assurer que les opérations de sauvegarde sont effectuées 
     756    séquentiellement, sans chevauchement. Dans le ca contraire, la 
     757    sauvegarde est invalidée. 
     758   </para> 
     759 
     760   <para> 
     761    La sauvegarde doit inclure tous les fichiers du répertoire 
     762    du groupe de bases de données 
     763    (<filename>/usr/local/pgsql/data</filename>, par exemple). Si des 
     764    <foreignphrase>tablespace</foreignphrase>  
     765    qui ne se trouvent pas dans ce répertoire sont utilisés, il ne faut pas 
     766    oublier de les inclure (et s'assurer également que la sauvegarde archive les liens 
     767    symboliques comme des liens, sans quoi la restauration des 
     768    <foreignphrase>tablespace</foreignphrase> sera problématique). 
     769   </para> 
     770 
     771   <para> 
     772    Néanmoins, les fichiers du sous-répertoire <filename>pg_xlog/</filename> 
     773    contenu dans le répertoire du cluster peuvent être omis. Cette petite 
     774    complication permet de réduire le risque d'erreurs lors de la restauration. 
     775    C'est facile à réaliser si <filename>pg_xlog/</filename> est un lien 
     776    symbolique vers quelque endroit extérieur au répertoire du cluster,  
     777    ce qui est toutefois une configuration courante, pour des raisons de performance. 
     778   </para> 
     779 
     780   <para> 
     781    La sauvegarde n'est utilisable que si les  fichiers de segment WAL 
     782    engendrés pendant ou après cette sauvegarde sont préservés. 
     783    Pour faciliter cela, la fonction  
     784    <function>pg_stop_backup</function> crée un <firstterm>fichier d'historique de la 
     785    sauvegarde</firstterm> immédiatement stocké dans la zone d'archivage des WAL. 
    782786    Ce fichier est nommé d'après le nom du premier fichier segment WAL dont 
    783     vous avez besoin pour utiliser la sauvegarde. Par exemple, si le fichier 
    784     WAL du début est <literal>0000000100001234000055CD</literal>, le fichier 
    785     historique sera nommé quelque chose comme 
     787    nécessaire à l'utilisation de la sauvegarde. Ainsi, si le fichier 
     788    WAL de démarrage est <literal>0000000100001234000055CD</literal>, le nom 
     789    du fichier d'historique ressemble à  
    786790    <literal>0000000100001234000055CD.007C9330.backup</literal> (le deuxième nombre 
    787791    dans le nom de ce fichier contient la position exacte à l'intérieur du fichier 
    788     WAL et peut être habituellement ignorée). Une fois que vous avez archivé de 
    789     façon sûre la sauvegarde du système de fichiers et les segments WAL utilisés 
    790     pendant la sauvegarde (comme spécifié dans le fichier d'historique des 
    791     sauvegardes), tous les segments WAL archivés avec des noms numériquement plus 
    792     petits ne sont plus nécessaires pour la récupération de la sauvegarde du 
    793     système de fichiers et pourraient être supprimés. Néanmoins, vous devriez 
    794     penser à conserver plusieurs ensembles de sauvegarde pour être absolument 
    795     certain de pouvoir récupérer vos données. 
     792    WAL et peut en général être ignoré). Une fois que la sauvegarde du 
     793    système de fichiers et des segments WAL utilisés 
     794    pendant celle-ci (comme précisé dans le fichier d'historique des sauvegardes)  
     795    sont archivés de façon sûre,    
     796    tous les segments WAL archivés de noms numériquement plus 
     797    petits ne sont plus nécessaires à la récupération de la sauvegarde du 
     798    système de fichiers et peuvent être supprimés. Toutefois, il est 
     799    préférable de conserver plusieurs jeux de sauvegarde pour être absolument 
     800    certain de pouvoir récupérer les données. 
    796801   </para> 
    797802 
    798803   <para> 
    799804    Le fichier d'historique de la sauvegarde est un simple fichier texte. Il 
    800     contient le label que vous avez donné à <function>pg_start_backup</function>, 
    801     ainsi que l'heure de début et de fin, et les segments WAL de la sauvegarde. 
    802     Si vous utilisez le label pour identifier où le fichier de sauvegarde associé 
    803     est conservé, alors le fichier historique archivé est suffisant pour vous 
    804     dire quel fichier de sauvegarde restaurer, si vous en avez besoin. 
    805    </para> 
    806  
    807    <para> 
    808     Comme vous devez conserver tous les fichiers WAL archivés depuis votre 
     805    contient le label passé à <function>pg_start_backup</function>, 
     806    l'heure et les segments WAL de début et de fin de la sauvegarde. 
     807    Si le label est utilisé pour identifier l'endroit où le fichier de sauvegarde associé 
     808    est conservé, alors le fichier d'historique archivé est suffisant pour 
     809    savoir quel fichier de sauvegarde restaurer, en cas de besoin. 
     810   </para> 
     811 
     812   <para> 
     813    Puisqu'il faut conserver tous les fichiers WAL archivés depuis la 
    809814    dernière sauvegarde de base, l'intervalle entre les sauvegardes de base 
    810     devrait habituellement être choisie suivant la quantité de stockage que 
    811     vous voulez consommer en fichiers archives WAL. Vous devriez aussi 
    812     considérer combien de temps vous êtes prêt à dépenser pendant la 
    813     récupération, si celle-ci est nécessaire &mdash; le système devra rejouer 
     815    est habituellement choisi en fonction de l'espace de stockage qu'on 
     816    accepte de consommer en fichiers d'archives WAL. Il faut également 
     817    considérer le temps à dépenser pour la 
     818    récupération, si celle-ci s'avère nécessaire &mdash; le système doit rejouer 
    814819    tous les segments WAL et ceci peut prendre beaucoup de temps si la 
    815820    dernière sauvegarde de base est ancienne. 
    …… 
    817822 
    818823   <para> 
    819     Il est aussi important de noter que la fonction 
     824    La fonction 
    820825    <function>pg_start_backup</function> crée un fichier nommé  
    821     <filename>backup_label</filename> dans le répertoire du groupe de bases de données 
    822     qui est ensuite supprimé de nouveau par <function>pg_stop_backup</function>. Ce 
    823     fichier sera bien sûr archivé comme faisant parti du fichier de 
    824     sauvegarde. Le fichier label de la sauvegarde inclut la chaîne label que 
    825     vous avez donné à <function>pg_start_backup</function>, ainsi que l'heure à 
     826    <filename>backup_label</filename> dans le répertoire du cluster de bases 
     827    de données. Ce fichier est ensuite supprimé par 
     828    <function>pg_stop_backup</function>. Ce fichier est bien sûr archivé 
     829    comme faisant parti du fichier de 
     830    sauvegarde. Le fichier de label de la sauvegarde inclut la chaîne de label 
     831    passée à <function>pg_start_backup</function>, l'heure à 
    826832    laquelle <function>pg_start_backup</function> a été exécuté et le nom du fichier 
    827     WAL du début. En cas de confusion, il sera du coup possible de regarder 
    828     dans le fichier sauvegarde et de déterminer exactement de quelle session 
     833    WAL initial. En cas de confusion, il est ainsi possible de regarder 
     834    dans le fichier sauvegarde et de déterminer avec précision de quelle session 
    829835    de sauvegarde provient ce fichier. 
    830836   </para> 
    …… 
    832838   <para> 
    833839    Il est aussi possible de faire une sauvegarde alors que le serveur est 
    834     arrêté. Dans ce cas, vous ne pouvez évidemment pas utiliser 
    835     <function>pg_start_backup</function> ou <function>pg_stop_backup</function> et vous serez 
    836     donc contraint à garder trace vous-même des fichiers de sauvegarde et de 
    837     jusqu'où vont les fichiers WAL associés. Il est généralement mieux de 
    838     suivre la procédure d'archivage continu ci-dessus. 
     840    arrêté. Dans ce cas, <function>pg_start_backup</function> et 
     841    <function>pg_stop_backup</function> ne peuvent évidemment pas être 
     842    utilisés. L'utilisateur doit alors se débrouiller pour identifier les 
     843    fichiers de sauvegarde et déterminer jusqu'où remonter avec les fichiers 
     844    WAL associés. Il est généralement préférable de 
     845    suivre la procédure d'archivage en ligne décrite ci-dessus. 
    839846   </para> 
    840847  </sect2> 
    841848 
    842849  <sect2 id="backup-pitr-recovery"> 
    843    <title>Récupérer à partir d'une sauvegarde de l'archivage continu</title> 
    844  
    845    <para> 
    846     OK, le pire est arrivé et vous avez besoin de récupérer votre sauvegarde. 
     850   <title>Récupération d'une sauvegarde en ligne</title> 
     851 
     852   <para> 
     853    Le pire est arrivé et il faut maintenant repartir d'une sauvegarde. 
    847854    Voici la procédure&nbsp;: 
    848855  <orderedlist> 
    849856   <listitem> 
    850857    <para> 
    851      Arrêtez le serveur s'il est en cours d'exécution. 
    852     </para> 
    853    </listitem> 
    854    <listitem> 
    855     <para> 
    856      Si vous avez de la place pour le faire, copiez le répertoire entier des 
    857      données du groupe et tout espace logique dans un emplacement temporaire 
    858      au cas où vous en auriez besoin plus tard. Notez que cette précaution 
    859      demandera que vous ayez assez de place libre sur votre système pour 
    860      contenir deux copies de votre base de données existante. Si vous n'avez 
    861      pas assez de place, vous devez au moins copier le contenu du 
    862      sous-répertoire <filename>pg_xlog</filename> du répertoire des données car il 
    863      pourrait contenir des journaux qui n'ont pas été archivés avant l'arrêt 
    864      du serveur. 
    865     </para> 
    866    </listitem> 
    867    <listitem> 
    868     <para> 
    869      Effacez tous les fichier et sous-répertoires existants sous le 
    870      répertoire des données du groupe et sous les répertoires racines des 
    871      espaces logiques que vous utilisez. 
    872     </para> 
    873    </listitem> 
    874    <listitem> 
    875     <para> 
    876      Restaurez les fichiers de la base de données à partir de votre 
    877      sauvegarde. Faites attention à ce qu'ils soient restaurés avec le bon 
     858     Arrêter le serveur s'il est en cours d'exécution. 
     859    </para> 
     860   </listitem> 
     861   <listitem> 
     862    <para> 
     863     Si la place nécessaire est disponible, copier le répertoire complet de 
     864     données du cluster et tous les <foreignphrase>tablespaces<foreignphrase> 
     865     dans un emplacement temporaire en prévision d'un éventuel besoin 
     866     ultérieur. Cette précaution nécessite qu'un espace suffisant sur le 
     867     système soit disponible pour contenir deux copies de la base de données 
     868     existante. S'il n'y a pas assez de place disponible, il faut au minimum  
     869     copier le contenu du sous-répertoire <filename>pg_xlog</filename> du 
     870     répertoire des données du cluster car il peut contenir des journaux 
     871     qui n'ont pas été archivés avant l'arrêt du serveur. 
     872    </para> 
     873   </listitem> 
     874   <listitem> 
     875    <para> 
     876     Effacer tous les fichiers et sous-répertoires existant sous le 
     877     répertoire des données du cluster et sous les répertoires racines des 
     878     <foreignphrase>tablespaces<foreignphrase>. 
     879    </para> 
     880   </listitem> 
     881   <listitem> 
     882    <para> 
     883     Restaurer les fichiers de la base de données à partir de la 
     884     sauvegarde. Il faut veiller à ce qu'ils soient restaurés avec le bon 
    878885     propriétaire (l'utilisateur système de la base de données, et non pas 
    879      root&nbsp;!) et avec les bons droits. Si vous utilisez les espaces 
    880      logiques, vous vérifirez que les liens symboliques dans 
     886     root&nbsp;!) et avec les bons droits. Si des 
     887     <foreignphrase>tablespaces<foreignphrase> sont utilisés, il faut 
     888     s'assurer que les liens symboliques dans 
    881889     <filename>pg_tblspc/</filename> ont été correctement restaurés. 
    882890    </para> 
    …… 
    884892   <listitem> 
    885893    <para> 
    886      Supprimez tout fichier présent dans <filename>pg_xlog/</filename>&nbsp;; ils 
     894     Supprimer tout fichier présent dans <filename>pg_xlog/</filename>&nbsp;; ils 
    887895     proviennent de la sauvegarde et sont du coup probablement obsolètes. 
    888      Si vous n'avez pas archivé <filename>pg_xlog/</filename> du tout, alors 
    889      re-créez ce répertoire ainsi que le sous-répertoire 
     896     Si <filename>pg_xlog/</filename> n'a pas été archivé, il suffit de  
     897     recréer ce répertoire ainsi que le sous-répertoire 
    890898     <filename>pg_xlog/archive_status/</filename>. 
    891899    </para> 
    …… 
    893901   <listitem> 
    894902    <para> 
    895      Si vous aviez des fichiers segments WAL non archivés que vous avez 
    896      sauvegardé dans l'étape 2, copiez-les dans <filename>pg_xlog/</filename> (il 
    897      est mieux de les copier, pas de les déplacer, car vous aurez toujours les 
    898      fichiers non modifiés si un problème survient et que vous devez 
    899      recommencer). 
    900     </para> 
    901    </listitem> 
    902    <listitem> 
    903     <para> 
    904      Créez un fichier de commandes de récupération  
    905      <filename>recovery.conf</filename> dans le répertoire des données du groupe 
    906      (voir <xref linkend="recovery-config-settings"/>). De plus, vous pourriez 
    907      vouloir modifier temporairement <filename>pg_hba.conf</filename> pour empêcher 
    908      les utilisateurs ordinaires de se connecter tant que vous n'êtes pas 
    909      certain que la récupération a réussi. 
    910     </para> 
    911    </listitem> 
    912    <listitem> 
    913     <para> 
    914      Lancez le serveur. Le serveur se trouvera en mode récupération et 
    915      commencera la lecture des fichiers WAL archivés dont il a besoin. Si la 
    916      récupération se termine avec une erreur externe, le serveur peut être 
    917      tout simplement relancé et il continuera la récupération. À la 
    918      fin du processus de récupération, le serveur renommera 
    919      <filename>recovery.conf</filename> en <filename>recovery.done</filename> (pour empêcher 
    920      de retourner accidentellement en mode de récupération dans le cas d'un 
    921      arrêt brutal un peu plus tard), puis commencera les opérations normales 
    922      de la base de données. 
    923     </para> 
    924    </listitem> 
    925    <listitem> 
    926     <para> 
    927      Inspectez le contenu de la base de données pour vous assurer que vous 
    928      avez récupéré ce que vous vouliez. Sinon, retournez à l'étape 1. Si 
    929      tout va bien, laissez vos utilisateurs venir en restaurant le fichier 
    930      <filename>pg_hba.conf</filename> à son état normal. 
     903     Si des fichiers de segment WAL non archivés ont été sauvegardés dans 
     904     l'étape 2, les copier dans <filename>pg_xlog/</filename>. Il 
     905     est préférable de les copier plutôt que de les déplacer afin qu'une 
     906     version non modifiée de ces fichiers soit toujours disponible si un 
     907     problème survient et qu'il faille recommencer. 
     908    </para> 
     909   </listitem> 
     910   <listitem> 
     911    <para> 
     912     Créer un fichier de commandes de récupération  
     913     <filename>recovery.conf</filename> dans le répertoire des données du 
     914     cluster (voir <xref linkend="recovery-config-settings"/>). Il peut, de 
     915     plus être judicieux de modifier temporairement le fichier  
     916     <filename>pg_hba.conf</filename> pour empêcher les utilisateurs 
     917     ordinaires de se connecter tant qu'il n'est pas certain que la 
     918     récupération a réussi. 
     919    </para> 
     920   </listitem> 
     921   <listitem> 
     922    <para> 
     923     Démarrer le serveur. Le serveur se trouve alors en mode récupération et 
     924     commence la lecture des fichiers WAL archivés dont il a besoin. Si la 
     925     récupération se termine sur une erreur externe, le serveur peut tout 
     926     simplement être relancé. Il continue alors la récupération. À la 
     927     fin du processus de récupération, le serveur renomme 
     928     <filename>recovery.conf</filename> en <filename>recovery.done</filename> 
     929     (pour empêcher de retourner accidentellement en mode de récupération en 
     930     cas de nouvel arrêt brutal ultérieur), puis passe ne mode de 
     931     fonctionnement normal. 
     932    </para> 
     933   </listitem> 
     934   <listitem> 
     935    <para> 
     936     Inspecter le contenu de la base de données pour s'assurer que la 
     937     récupération a bien fonctionné. Dans le cas contraire, retourner 
     938     à l'étape 1. Si tout va bien, le fichier <filename>pg_hba.conf</filename> 
     939     peut-être restauré pour autoriser les utilisateurs à se reconnecter. 
    931940    </para> 
    932941   </listitem> 
    …… 
    935944 
    936945   <para> 
    937     La partie clé de tout ceci est de configurer le fichier de commandes de 
    938     récupération. Il décrit comment vous voulez récupérer et à quel point la 
    939     récupération doit fonctionner. Vous pouvez utiliser  
     946    Le point clé de tout ceci est l'écriture d'un fichier de commandes de 
     947    récupération qui décrit comment et jusqu'où récupérer. Le fichier  
    940948    <filename>recovery.conf.sample</filename> (normalement présent dans le 
    941     répertoire d'installation <filename>share/</filename>) comme prototype. La seule 
    942     chose que vous devez absolument spécifier dans 
    943     <filename>recovery.conf</filename> est <varname>restore_command</varname> indiquant à 
    944     <productname>PostgreSQL</productname> comment récupérer les fichiers segments WAL 
    945     archivés. Comme <varname>archive_command</varname>, ceci est une chaîne contenant 
    946     le nom de la commande. Elle pourrait contenir <literal>%f</literal>, qui est 
     949    répertoire d'installation <filename>share/</filename>) peut être utilisé 
     950    comme prototype. La seule chose qu'il faut absolument préciser dans 
     951    <filename>recovery.conf</filename>, c'est <varname>restore_command</varname> 
     952    qui indique à <productname>PostgreSQL</productname> comment récupérer les 
     953    fichiers de segment WAL archivés. À l'instar  
     954    d'<varname>archive_command</varname>, c'est une chaîne de commande 
     955    shell. Elle peut contenir <literal>%f</literal>, qui est 
    947956    remplacé par le nom du journal souhaité, et <literal>%p</literal>, qui est 
    948     remplacé par le chemin où copier le journal. (Le nom du chemin est relatif 
    949     au répertoire de travail du serveur, c'est-à-dire le répertoire des données 
    950     du cluster.) Écrivez  <literal>%%</literal> si vous avez besoin d'embarquer 
    951     un vrai caractère <literal>%</literal> dans la commande. La commande utile 
    952     la plus simple est quelque chose comme 
     957    remplacé par le chemin du répertoire où copier le journal. 
     958    (Le nom du chemin est relatif au répertoire de travail du serveur, 
     959    c'est-à-dire le répertoire des données du cluster.) Pour écrire le 
     960    caractère <literal>%</literal> dans la commande, on utilise 
     961    <literal>%%</literal>. La commande utile la plus simple ressemble à 
    953962<programlisting>restore_command = 'cp /mnt/serveur/répertoire_archive/%f %p'</programlisting> 
    954     qui copiera les segments WAL précédemment archivés à partir du répertoire 
    955     <filename>/mnt/serveur/répertoire_archive</filename>.  Vous pourriez bien sûr 
    956     utiliser quelque chose de plus compliqué, peut-être même un script shell 
    957     qui demandera à l'utilisateur de monter la cassette appropriée. 
    958    </para> 
    959  
    960    <para> 
    961     Il est important que la commande renvoie un code de sortie différent de 
    962     zéro en cas d'échec. La commande <emphasis>se verra demander</emphasis> les 
    963     journaux absents de l'archive&nbsp;; il doit renvoyer autre chose que 
    964     zéro dans ce cas. Ceci n'est pas une condition d'erreur. Soyez conscient 
     963    qui copie les segments WAL précédemment archivés à partir du répertoire 
     964    <filename>/mnt/serveur/répertoire_archive</filename>.  Il est toujours 
     965    possible d'utiliser une commande plus compliquée, voire même un script shell 
     966    qui demande à l'utilisateur de monter la cassette appropriée. 
     967   </para> 
     968 
     969<!-- ICI /home/sas/documentations/pg82/continuous-archiving.html --> 
     970   <para> 
     971    Il est important que la commande retourne un code de sortie différent de 
     972    zéro en cas d'échec. Des journaux absents de l'archive 
     973    <emphasis>seront</emphasis> demandés à la commande&nbsp;; elle doit 
     974    renvoyer autre chose que 
     975    zéro dans ce cas. Ce n'est pas une condition d'erreur. Soyez conscient 
    965976    que le nom de base du chemin <literal>%p</literal> sera différent de 
    966977    <literal>%f</literal>&nbsp;; ne vous attendez pas à ce qu'ils soient