to follow the continuous archiving procedure above.
   </para>
   </sect3>
  </sect2>

  <sect2 id="backup-pitr-recovery">
   <title>Recovering Using a Continuous Archive Backup</title>

   <para>
    Okay, the worst has happened and you need to recover from your backup.
    Here is the procedure:
  <orderedlist>
   <listitem>
    <para>
     Stop the server, if it's running.
    </para>
   </listitem>
   <listitem>
    <para>
     If you have the space to do so,
     copy the whole cluster data directory and any tablespaces to a temporary
     location in case you need them later. Note that this precaution will
     require that you have enough free space on your system to hold two
     copies of your existing database. If you do not have enough space,
     you should at least save the contents of the cluster's <filename>pg_wal</filename>
     subdirectory, as it might contain WAL files which
     were not archived before the system went down.
    </para>
   </listitem>
   <listitem>
    <para>
     Remove all existing files and subdirectories under the cluster data
     directory and under the root directories of any tablespaces you are using.
    </para>
   </listitem>
   <listitem>
    <para>
     If you're restoring a full backup, you can restore the database files
     directly into the target directories.  Be sure that they
     are restored with the right ownership (the database system user, not
     <literal>root</literal>!) and with the right permissions.  If you are using
     tablespaces,
     you should verify that the symbolic links in <filename>pg_tblspc/</filename>
     were correctly restored.
    </para>
   </listitem>
   <listitem>
    <para>
     If you're restoring an incremental backup, you'll need to restore the
     incremental backup and all earlier backups upon which it directly or
     indirectly depends to the machine where you are performing the restore.
     These backups will need to be placed in separate directories, not the
     target directories where you want the running server to end up.
     Once this is done, use <xref linkend="app-pgcombinebackup"/> to pull
     data from the full backup and all of the subsequent incremental backups
     and write out a synthetic full backup to the target directories. As above,
     verify that permissions and tablespace links are correct.
    </para>
   </listitem>
   <listitem>
    <para>
     Remove any files present in <filename>pg_wal/</filename>; these came from the
     file system backup and are therefore probably obsolete rather than current.
     If you didn't archive <filename>pg_wal/</filename> at all, then recreate
     it with proper permissions,
     being careful to ensure that you re-establish it as a symbolic link
     if you had it set up that way before.
    </para>
   </listitem>
   <listitem>
    <para>
     If you have unarchived WAL segment files that you saved in step 2,
     copy them into <filename>pg_wal/</filename>.  (It is best to copy them,
     not move them, so you still have the unmodified files if a
     problem occurs and you have to start over.)
    </para>
   </listitem>
   <listitem>
    <para>
     Set recovery configuration settings in
     <filename>postgresql.conf</filename> (see <xref
     linkend="runtime-config-wal-archive-recovery"/>) and create a file
     <filename>recovery.signal</filename> in the cluster
     data directory. You might
     also want to temporarily modify <filename>pg_hba.conf</filename> to prevent
     ordinary users from connecting until you are sure the recovery was successful.
    </para>
   </listitem>
   <listitem>
    <para>
     Start the server.  The server will go into recovery mode and
     proceed to read through the archived WAL files it needs.  Should the
     recovery be terminated because of an external error, the server can
     simply be restarted and it will continue recovery.  Upon completion
     of the recovery process, the server will remove
     <filename>recovery.signal</filename>