recovery fails for an external reason, such as a system crash or
    if the WAL archive has become inaccessible, then the recovery can simply
    be restarted and it will restart almost from where it failed.
    Recovery restart works much like checkpointing in normal operation:
    the server periodically forces all its state to disk, and then updates
    the <filename>pg_control</filename> file to indicate that the already-processed
    WAL data need not be scanned again.
   </para>

  </sect2>

  <sect2 id="backup-timelines">
   <title>Timelines</title>

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

   <para>
    The ability to restore the database to a previous point in time creates
    some complexities that are akin to science-fiction stories about time
    travel and parallel universes.  For example, in the original history of the database,
    suppose you dropped a critical table at 5:15PM on Tuesday evening, but
    didn't realize your mistake until Wednesday noon.
    Unfazed, you get out your backup, restore to the point-in-time 5:14PM
    Tuesday evening, and are up and running.  In <emphasis>this</emphasis> history of
    the database universe, you never dropped the table.  But suppose
    you later realize this wasn't such a great idea, and would like
    to return to sometime Wednesday morning in the original history.
    You won't be able
    to if, while your database was up-and-running, it overwrote some of the
    WAL segment files that led up to the time you now wish you
    could get back to.  Thus, to avoid this, you need to distinguish the series of
    WAL records generated after you've done a point-in-time recovery from
    those that were generated in the original database history.
   </para>

   <para>
    To deal with this problem, <productname>PostgreSQL</productname> has a notion
    of <firstterm>timelines</firstterm>.  Whenever an archive recovery completes,
    a new timeline is created to identify the series of WAL records
    generated after that recovery.  The timeline
    ID number is part of WAL segment file names so a new timeline does
    not overwrite the WAL data generated by previous timelines.
    For example, in the WAL file name
    <filename>0000000100001234000055CD</filename>, the leading
    <literal>00000001</literal> is the timeline ID in hexadecimal.  (Note that
    in other contexts, such as server log messages, timeline IDs are
    usually printed in decimal.)
   </para>

   <para>
    It is
    in fact possible to archive many different timelines.  While that might
    seem like a useless feature, it's often a lifesaver.  Consider the
    situation where you aren't quite sure what point-in-time to recover to,
    and so have to do several point-in-time recoveries by trial and error
    until you find the best place to branch off from the old history.  Without
    timelines this process would soon generate an unmanageable mess.  With
    timelines, you can recover to <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.