can bring up
     the second machine and it will have a nearly-current copy of the
     database.
    </para>
   </listitem>
  </itemizedlist>
  </para>

  <note>
   <para>
    <application>pg_dump</application> and
    <application>pg_dumpall</application> do not produce file-system-level
    backups and cannot be used as part of a continuous-archiving solution.
    Such dumps are <emphasis>logical</emphasis> and do not contain enough
    information to be used by WAL replay.
   </para>
  </note>

  <para>
   As with the plain file-system-backup technique, this method can only
   support restoration of an entire database cluster, not a subset.
   Also, it requires a lot of archival storage: the base backup might be bulky,
   and a busy system will generate many megabytes of WAL traffic that
   have to be archived.  Still, it is the preferred backup technique in
   many situations where high reliability is needed.
  </para>

  <para>
   To recover successfully using continuous archiving (also called
   <quote>online backup</quote> by many database vendors), you need a continuous
   sequence of archived WAL files that extends back at least as far as the
   start time of your backup.  So to get started, you should set up and test
   your procedure for archiving WAL files <emphasis>before</emphasis> you take your
   first base backup.  Accordingly, we first discuss the mechanics of
   archiving WAL files.
  </para>

  <sect2 id="backup-archiving-wal">
   <title>Setting Up WAL Archiving</title>

   <para>
    In an abstract sense, a running <productname>PostgreSQL</productname> system
    produces an indefinitely long sequence of WAL records.  The system
    physically divides this sequence into WAL <firstterm>segment
    files</firstterm>, which are normally 16MB apiece (although the segment size
    can be altered during <application>initdb</application>).  The segment
    files are given numeric names that reflect their position in the
    abstract WAL sequence.  When not using WAL archiving, the system
    normally creates just a few segment files and then
    <quote>recycles</quote> them by renaming no-longer-needed segment files
    to higher segment numbers.  It's assumed that segment files whose
    contents precede the last checkpoint are no longer of
    interest and can be recycled.
   </para>

   <para>
    When archiving WAL data, we need to capture the contents of each segment
    file once it is filled, and save that data somewhere before the segment
    file is recycled for reuse.  Depending on the application and the
    available hardware, there could be many different ways of <quote>saving
    the data somewhere</quote>: we could copy the segment files to an NFS-mounted
    directory on another machine, write them onto a tape drive (ensuring that
    you have a way of identifying the original name of each file), or batch
    them together and burn them onto CDs, or something else entirely.  To
    provide the database administrator with flexibility,
    <productname>PostgreSQL</productname> tries not to make any assumptions about how
    the archiving will be done.  Instead, <productname>PostgreSQL</productname> lets
    the administrator specify a shell command or an archive library to be executed to copy a
    completed segment file to wherever it needs to go.  This could be as simple
    as a shell command that uses <literal>cp</literal>, or it could invoke a
    complex C function &mdash; it's all up to you.
   </para>

   <para>
    To enable WAL archiving, set the <xref linkend="guc-wal-level"/>
    configuration parameter to <literal>replica</literal> or higher,
    <xref linkend="guc-archive-mode"/> to <literal>on</literal>,
    specify the shell command to use in the <xref
    linkend="guc-archive-command"/> configuration parameter
    or specify the library to use in the <xref
    linkend="guc-archive-library"/> configuration parameter.  In practice
    these settings will always be placed in the
    <filename>postgresql.conf</filename>