WAL segments.  Hence,
    if your server generates only little WAL traffic (or has slack periods
    where it does so), there could be a long delay between the completion
    of a transaction and its safe recording in archive storage.  To put
    a limit on how old unarchived data can be, you can set
    <xref linkend="guc-archive-timeout"/> to force the server to switch
    to a new WAL segment file at least that often.  Note that archived
    files that are archived early due to a forced switch are still the same
    length as completely full files.  It is therefore unwise to set a very
    short <varname>archive_timeout</varname> &mdash; it will bloat your archive
    storage.  <varname>archive_timeout</varname> settings of a minute or so are
    usually reasonable.
   </para>

   <para>
    Also, you can force a segment switch manually with
    <function>pg_switch_wal</function> if you want to ensure that a
    just-finished transaction is archived as soon as possible.  Other utility
    functions related to WAL management are listed in <xref
    linkend="functions-admin-backup-table"/>.
   </para>

   <para>
    When <varname>wal_level</varname> is <literal>minimal</literal> some SQL commands
    are optimized to avoid WAL logging, as described in <xref
    linkend="populate-pitr"/>.  If archiving or streaming replication were
    turned on during execution of one of these statements, WAL would not
    contain enough information for archive recovery.  (Crash recovery is
    unaffected.)  For this reason, <varname>wal_level</varname> can only be changed at
    server start.  However, <varname>archive_command</varname> and <varname>archive_library</varname> can be changed with a
    configuration file reload.  If you are archiving via shell and wish to
    temporarily stop archiving,
    one way to do it is to set <varname>archive_command</varname> to the empty
    string (<literal>''</literal>).
    This will cause WAL files to accumulate in <filename>pg_wal/</filename> until a
    working <varname>archive_command</varname> is re-established.
   </para>
  </sect2>

  <sect2 id="backup-base-backup">
   <title>Making a Base Backup</title>

   <para>
    The easiest way to perform a base backup is to use the
    <xref linkend="app-pgbasebackup"/> tool. It can create
    a base backup either as regular files or as a tar archive. If more
    flexibility than <xref linkend="app-pgbasebackup"/> can provide is
    required, you can also make a base backup using the low level API
    (see <xref linkend="backup-lowlevel-base-backup"/>).
   </para>

   <para>
    It is not necessary to be concerned about the amount of time it takes
    to make a base backup. However, if you normally run the
    server with <varname>full_page_writes</varname> disabled, you might notice a drop
    in performance while the backup runs since <varname>full_page_writes</varname> is
    effectively forced on during backup mode.
   </para>

   <para>
    To make use of the backup, you will need to keep all the WAL
    segment files generated during and after the file system backup.
    To aid you in doing this, the base backup process
    creates a <firstterm>backup history file</firstterm> that is immediately
    stored into the WAL archive area. This file is named after the first
    WAL segment file that you need for the file system backup.
    For example, if the starting WAL file is
    <literal>0000000100001234000055CD</literal> the backup history file will be
    named something like
    <literal>0000000100001234000055CD.007C9330.backup</literal>. (The second
    part of the file name stands for an exact position within the WAL
    file, and can ordinarily be ignored.) Once you have safely archived
    the file system backup and the WAL segment files used during the
    backup (as specified in the backup history file), all archived WAL
    segments with names numerically less are no longer needed to recover
    the file system backup and can be deleted.