<application>postmaster</application> which will eventually use this backup.
    (These files can confuse <application>pg_ctl</application>.)
   </para>

   <para>
    It is often a good idea to also omit from the backup the files
    within the cluster's <filename>pg_replslot/</filename> directory, so that
    replication slots that exist on the primary do not become part of the
    backup.  Otherwise, the subsequent use of the backup to create a standby
    may result in indefinite retention of WAL files on the standby, and
    possibly bloat on the primary if hot standby feedback is enabled, because
    the clients that are using those replication slots will still be connecting
    to and updating the slots on the primary, not the standby.  Even if the
    backup is only intended for use in creating a new primary, copying the
    replication slots isn't expected to be particularly useful, since the
    contents of those slots will likely be badly out of date by the time
    the new primary comes on line.
   </para>

   <para>
    The contents of the directories <filename>pg_dynshmem/</filename>,
    <filename>pg_notify/</filename>, <filename>pg_serial/</filename>,
    <filename>pg_snapshots/</filename>, <filename>pg_stat_tmp/</filename>,
    and <filename>pg_subtrans/</filename> (but not the directories themselves) can be
    omitted from the backup as they will be initialized on postmaster startup.
   </para>

   <para>
    Any file or directory beginning with <filename>pgsql_tmp</filename> can be
    omitted from the backup.  These files are removed on postmaster start and
    the directories will be recreated as needed.
   </para>

   <para>
    <filename>pg_internal.init</filename> files can be omitted from the
    backup whenever a file of that name is found.  These files contain
    relation cache data that is always rebuilt when recovering.
   </para>

   <para>
    The backup label
    file includes the label string you gave to <function>pg_backup_start</function>,
    as well as the time at which <function>pg_backup_start</function> was run, and
    the name of the starting WAL file.  In case of confusion it is therefore
    possible to look inside a backup file and determine exactly which
    backup session the dump file came from.  The tablespace map file includes
    the symbolic link names as they exist in the directory
    <filename>pg_tblspc/</filename> and the full path of each symbolic link.
    These files are not merely for your information; their presence and
    contents are critical to the proper operation of the system's recovery
    process.
   </para>

   <para>
    It is also possible to make a backup while the server is
    stopped.  In this case, you obviously cannot use
    <function>pg_backup_start</function> or <function>pg_backup_stop</function>, and
    you will therefore be left to your own devices to keep track of which
    backup is which and how far back the associated WAL files go.
    It is generally better 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>