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 about
    this requirement. Note that there are restrictions on the use of
    <literal>pg_combinebackup</literal> when the checksum status of the
    cluster has been changed; see
    <link linkend="app-pgcombinebackup-limitations">pg_combinebackup
    limitations</link>.
   </para>

   <para>
    Note that all of the requirements for making use of a full backup also
    apply to an incremental backup. For instance, you still need all of the
    WAL segment files generated during and after the file system backup, and
    any relevant WAL history files. And you still need to create a
    <literal>recovery.signal</literal> (or <literal>standby.signal</literal>)
    and perform recovery, as described in
    <xref linkend="backup-pitr-recovery" />. The requirement to have earlier
    backups available at restore time and to use
    <literal>pg_combinebackup</literal> is an additional requirement on top of
    everything else. Keep in mind that <application>PostgreSQL</application>
    has no built-in mechanism to figure out which backups are still needed as
    a basis for restoring later incremental backups. You must keep track of
    the relationships between your full and incremental backups on your own,
    and be certain not to remove earlier backups if they might be needed when
    restoring later incremental backups.
   </para>

   <para>
    Incremental backups typically only make sense for relatively large
    databases where a significant portion of the data does not change, or only
    changes slowly. For a small database, it's simpler to ignore the existence
    of incremental backups and simply take full backups, which are simpler
    to manage. For a large database all of which is heavily modified,
    incremental backups won't be much smaller than full backups.
   </para>

   <para>
    An incremental backup is only possible if replay would begin from a later
    checkpoint than for the previous backup upon which it depends.  If you
    take the incremental backup on the primary, this condition is always
    satisfied, because each backup triggers a new checkpoint.  On a standby,
    replay begins from the most recent restartpoint.  Therefore, an
    incremental backup of a standby server can fail if there has been very
    little activity since the previous backup, since no new restartpoint might
    have been created.
   </para>
  </sect2>

  <sect2 id="backup-lowlevel-base-backup">
   <title>Making a Base Backup Using the Low Level API</title>
   <para>
    Instead of taking a full or incremental base backup using
    <xref linkend="app-pgbasebackup"/>, you can take a base backup using the
    low-level API. This procedure contains a few more steps than
    the <application>pg_basebackup</application> method, but is relatively
    simple. It is very important that these steps are executed in
    sequence, and that the success of a step is verified before
    proceeding to the next step.
   </para>
    <para>
     Multiple backups