larger
   than an SQL dump. (<application>pg_dump</application> does not need to dump
   the contents of indexes for example, just the commands to recreate
   them.)  However, taking a file system backup might be faster.
  </para>
 </sect1>

 <sect1 id="continuous-archiving">
  <title>Continuous Archiving and Point-in-Time Recovery (PITR)</title>

  <indexterm zone="backup">
   <primary>continuous archiving</primary>
  </indexterm>

  <indexterm zone="backup">
   <primary>point-in-time recovery</primary>
  </indexterm>

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

  <para>
   At all times, <productname>PostgreSQL</productname> maintains a
   <firstterm>write ahead log</firstterm> (WAL) in the <filename>pg_wal/</filename>
   subdirectory of the cluster's data directory. The log records
   every change made to the database's data files.  This log exists
   primarily for crash-safety purposes: if the system crashes, the
   database can be restored to consistency by <quote>replaying</quote> the
   log entries made since the last checkpoint.  However, the existence
   of the log makes it possible to use a third strategy for backing up
   databases: we can combine a file-system-level backup with backup of
   the WAL files.  If recovery is needed, we restore the file system backup and
   then replay from the backed-up WAL files to bring the system to a
   current state.  This approach is more complex to administer than
   either of the previous approaches, but it has some significant
   benefits:
  <itemizedlist>
   <listitem>
    <para>
     We do not need a perfectly consistent file system backup as the starting point.
     Any internal inconsistency in the backup will be corrected by log
     replay (this is not significantly different from what happens during
     crash recovery).  So we do not need a file system snapshot capability,
     just <application>tar</application> or a similar archiving tool.
    </para>
   </listitem>
   <listitem>
    <para>
     Since we can combine an indefinitely long sequence of WAL files
     for replay, continuous backup can be achieved simply by continuing to archive
     the WAL files.  This is particularly valuable for large databases, where
     it might not be convenient to take a full backup frequently.
    </para>
   </listitem>
   <listitem>
    <para>
     It is not necessary to replay the WAL entries all the
     way to the end.  We could stop the replay at any point and have a
     consistent snapshot of the database as it was at that time.  Thus,
     this technique supports <firstterm>point-in-time recovery</firstterm>: it is
     possible to restore the database to its state at any time since your base
     backup was taken.
    </para>
   </listitem>
   <listitem>
    <para>
     If we continuously feed the series of WAL files to another
     machine that has been loaded with the same base backup file, we
     have a <firstterm>warm standby</firstterm> system: at any point we 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