particular, GNU <command>cp</command>
    will return status zero when <option>-i</option> is used and the target file
    already exists, which is <emphasis>not</emphasis> the desired behavior.)
   </para>

   <para>
    While designing your archiving setup, consider what will happen if
    the archive command or library fails repeatedly because some aspect requires
    operator intervention or the archive runs out of space. For example, this
    could occur if you write to tape without an autochanger; when the tape
    fills, nothing further can be archived until the tape is swapped.
    You should ensure that any error condition or request to a human operator
    is reported appropriately so that the situation can be
    resolved reasonably quickly. The <filename>pg_wal/</filename> directory will
    continue to fill with WAL segment files until the situation is resolved.
    (If the file system containing <filename>pg_wal/</filename> fills up,
    <productname>PostgreSQL</productname> will do a PANIC shutdown.  No committed
    transactions will be lost, but the database will remain offline until
    you free some space.)
   </para>

   <para>
    The speed of the archive command or library is unimportant as long as it can keep up
    with the average rate at which your server generates WAL data.  Normal
    operation continues even if the archiving process falls a little behind.
    If archiving falls significantly behind, this will increase the amount of
    data that would be lost in the event of a disaster. It will also mean that
    the <filename>pg_wal/</filename> directory will contain large numbers of
    not-yet-archived segment files, which could eventually exceed available
    disk space. You are advised to monitor the archiving process to ensure that
    it is working as you intend.
   </para>

   <para>
    In writing your archive command or library, you should assume that the file names to
    be archived can be up to 64 characters long and can contain any
    combination of ASCII letters, digits, and dots.  It is not necessary to
    preserve the original relative path (<literal>%p</literal>) but it is necessary to
    preserve the file name (<literal>%f</literal>).
   </para>

   <para>
    Note that although WAL archiving will allow you to restore any
    modifications made to the data in your <productname>PostgreSQL</productname> database,
    it will not restore changes made to configuration files (that is,
    <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename> and
    <filename>pg_ident.conf</filename>), since those are edited manually rather
    than through SQL operations.
    You might wish to keep the configuration files in a location that will
    be backed up by your regular file system backup procedures.  See
    <xref linkend="runtime-config-file-locations"/> for how to relocate the
    configuration files.
   </para>

   <para>
    The archive command or function is only invoked on completed WAL segments.  Hence,
    if your server generates only little WAL traffic (or has slack periods
    where it does so), there could be a long delay between the completion
    of a transaction and its safe recording in archive storage.  To put
    a limit on how old unarchived data can be, you can set
    <xref linkend="guc-archive-timeout"/> to force the server to switch
    to a new WAL segment file at least that often.  Note that archived
    files that are archived early due to a forced switch are still the same
    length as completely full files.  It is therefore unwise to set a very
    short <varname>archive_timeout</varname> &mdash; it will bloat your archive
    storage.  <varname>archive_timeout</varname> settings of a minute or so are
    usually reasonable.
   </para>

   <para>
    Also, you can force a segment switch manually with
    <function>pg_switch_wal</function> if you want to ensure that a
    just-finished transaction is archived as soon as possible.  Other utility