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. However, you should
    consider keeping several backup sets to be absolutely certain that
    you can recover your data.
   </para>

   <para>
    The backup history file is just a small text file. It contains the
    label string you gave to <xref linkend="app-pgbasebackup"/>, as well as
    the starting and ending times and WAL segments of the backup.
    If you used the label to identify the associated dump file,
    then the archived history file is enough to tell you which dump file to
    restore.
   </para>

   <para>
    Since you have to keep around all the archived WAL files back to your
    last base backup, the interval between base backups should usually be
    chosen based on how much storage you want to expend on archived WAL
    files.  You should also consider how long you are prepared to spend
    recovering, if recovery should be necessary &mdash; the system will have to
    replay all those WAL segments, and that could take awhile if it has
    been a long time since the last base backup.
   </para>
  </sect2>

  <sect2 id="backup-incremental-backup">
   <title>Making an Incremental Backup</title>

   <para>
    You can use <xref linkend="app-pgbasebackup"/> to take an incremental
    backup by specifying the <literal>--incremental</literal> option. You must
    supply, as an argument to <literal>--incremental</literal>, the backup
    manifest to an earlier backup from the same server. In the resulting
    backup, non-relation files will be included in their entirety, but some
    relation files may be replaced by smaller incremental files which contain
    only the blocks which have been changed since the earlier backup and enough
    metadata to reconstruct the current version of the file.
   </para>

   <para>
    To figure out which blocks need to be backed up, the server uses WAL
    summaries, which are stored in the data directory, inside the directory
    <literal>pg_wal/summaries</literal>. If the required summary files are not
    present, an attempt to take an incremental backup will fail. The summaries
    present in this directory must cover all LSNs from the start LSN of the
    prior backup to the start LSN of the current backup. Since the server looks
    for WAL summaries just after establishing the start LSN of the current
    backup, the necessary summary files probably won't be instantly present
    on disk, but the server will wait for any missing files to show up.
    This also helps if the WAL summarization process has fallen behind.
    However, if the necessary files have already been removed, or if the WAL
    summarizer doesn't catch up quickly enough, the incremental backup will
    fail.
   </para>

   <para>
    When restoring an incremental backup, it will be necessary to have not
    only the incremental backup itself but also all earlier backups that
    are required to supply the blocks omitted from the incremental backup.
    See <xref linkend="app-pgcombinebackup"/> for further information