<emphasis>any</emphasis> prior state, including
    states in timeline branches that you abandoned earlier.
   </para>

   <para>
    Every time a new timeline is created, <productname>PostgreSQL</productname> creates
    a <quote>timeline history</quote> file that shows which timeline it branched
    off from and when.  These history files are necessary to allow the system
    to pick the right WAL segment files when recovering from an archive that
    contains multiple timelines.  Therefore, they are archived into the WAL
    archive area just like WAL segment files.  The history files are just
    small text files, so it's cheap and appropriate to keep them around
    indefinitely (unlike the segment files which are large).  You can, if
    you like, add comments to a history file to record your own notes about
    how and why this particular timeline was created.  Such comments will be
    especially valuable when you have a thicket of different timelines as
    a result of experimentation.
   </para>

   <para>
    The default behavior of recovery is to recover to the latest timeline found
    in the archive. If you wish to recover to the timeline that was current
    when the base backup was taken or into a specific child timeline (that
    is, you want to return to some state that was itself generated after a
    recovery attempt), you need to specify <literal>current</literal> or the
    target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You
    cannot recover into timelines that branched off earlier than the base backup.
   </para>
  </sect2>

  <sect2 id="backup-tips">
   <title>Tips and Examples</title>

   <para>
    Some tips for configuring continuous archiving are given here.
   </para>

    <sect3 id="backup-standalone">
     <title>Standalone Hot Backups</title>

     <para>
      It is possible to use <productname>PostgreSQL</productname>'s backup facilities to
      produce standalone hot backups. These are backups that cannot be used
      for point-in-time recovery, yet are typically much faster to backup and
      restore than <application>pg_dump</application> dumps.  (They are also much larger
      than <application>pg_dump</application> dumps, so in some cases the speed advantage
      might be negated.)
     </para>

     <para>
      As with base backups, the easiest way to produce a standalone
      hot backup is to use the <xref linkend="app-pgbasebackup"/>
      tool. If you include the <literal>-X</literal> parameter when calling
      it, all the write-ahead log required to use the backup will be
      included in the backup automatically, and no special action is
      required to restore the backup.
     </para>
    </sect3>

    <sect3 id="compressed-archive-logs">
     <title>Compressed Archive Logs</title>

     <para>
      If archive storage size is a concern, you can use
      <application>gzip</application> to compress the archive files:
<programlisting>
archive_command = 'gzip &lt; %p &gt; /mnt/server/archivedir/%f.gz'
</programlisting>
      You will then need to use <application>gunzip</application> during recovery:
<programlisting>
restore_command = 'gunzip &lt; /mnt/server/archivedir/%f.gz &gt; %p'
</programlisting>
     </para>
    </sect3>

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

     <para>
      Many people choose to use scripts to define their
      <varname>archive_command</varname>, so that their
      <filename>postgresql.conf</filename> entry looks very simple:
<programlisting>
archive_command = 'local_backup_script.sh "%p" "%f"'
</programlisting>
      Using a separate script file is advisable any time you want to use
      more than a single command in the archiving process.
      This allows all complexity to be managed within the script, which
      can be written in a popular scripting language such as
      <application>bash</application>