are successfully archived then the
     <literal>wait_for_archive</literal> parameter (which defaults to true) can be set
     to false to have
     <function>pg_backup_stop</function> return as soon as the stop backup record is
     written to the WAL.  By default, <function>pg_backup_stop</function> will wait
     until all WAL has been archived, which can take some time.  This option
     must be used with caution: if WAL archiving is not monitored correctly
     then the backup might not include all of the WAL files and will
     therefore be incomplete and not able to be restored.
    </para>
   </listitem>
  </orderedlist>
    </para>
   <sect3 id="backup-lowlevel-base-backup-data">
   <title>Backing Up the Data Directory</title>
   <para>
    Some file system backup tools emit warnings or errors
    if the files they are trying to copy change while the copy proceeds.
    When taking a base backup of an active database, this situation is normal
    and not an error.  However, you need to ensure that you can distinguish
    complaints of this sort from real errors.  For example, some versions
    of <application>rsync</application> return a separate exit code for
    <quote>vanished source files</quote>, and you can write a driver script to
    accept this exit code as a non-error case.  Also, some versions of
    GNU <application>tar</application> return an error code indistinguishable from
    a fatal error if a file was truncated while <application>tar</application> was
    copying it.  Fortunately, GNU <application>tar</application> versions 1.16 and
    later exit with 1 if a file was changed during the backup,
    and 2 for other errors.  With GNU <application>tar</application> version 1.23 and
    later, you can use the warning options <literal>--warning=no-file-changed
    --warning=no-file-removed</literal> to hide the related warning messages.
   </para>

   <para>
    Be certain that your backup includes all of the files under
    the database cluster directory (e.g., <filename>/usr/local/pgsql/data</filename>).
    If you are using tablespaces that do not reside underneath this directory,
    be careful to include them as well (and be sure that your backup
    archives symbolic links as links, otherwise the restore will corrupt
    your tablespaces).
   </para>

   <para>
    You should, however, omit from the backup the files within the
    cluster's <filename>pg_wal/</filename> subdirectory.  This
    slight adjustment is worthwhile because it reduces the risk
    of mistakes when restoring.  This is easy to arrange if
    <filename>pg_wal/</filename> is a symbolic link pointing to someplace outside
    the cluster directory, which is a common setup anyway for performance
    reasons.  You might also want to exclude <filename>postmaster.pid</filename>
    and <filename>postmaster.opts</filename>, which record information
    about the running <application>postmaster</application>, not about the
    <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>