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 are able to be run concurrently (both those
     started using this backup API and those started using
     <xref linkend="app-pgbasebackup"/>).
    </para>
    <para>
  <orderedlist>
   <listitem>
    <para>
     Ensure that WAL archiving is enabled and working.
    </para>
   </listitem>
   <listitem>
    <para>
     Connect to the server (it does not matter which database) as a user with
     rights to run <function>pg_backup_start</function> (superuser,
     or a user who has been granted <literal>EXECUTE</literal> on the
     function) and issue the command:
<programlisting>
SELECT pg_backup_start(label => 'label', fast => false);
</programlisting>
     where <literal>label</literal> is any string you want to use to uniquely
     identify this backup operation. The connection
     calling <function>pg_backup_start</function> must be maintained until the end of
     the backup, or the backup will be automatically aborted.
    </para>

    <para>
     Online backups are always started at the beginning of a checkpoint.
     By default, <function>pg_backup_start</function> will wait for the next
     regularly scheduled checkpoint to complete, which may take a long time (see the
     configuration parameters <xref linkend="guc-checkpoint-timeout"/> and
     <xref linkend="guc-checkpoint-completion-target"/>).  This is
     usually preferable as it minimizes the impact on the running system.  If you
     want to start the backup as soon as possible, pass <literal>true</literal> as
     the second parameter to <function>pg_backup_start</function> and it will
     request an immediate checkpoint, which will finish as fast as possible using
     as much I/O as possible.
    </para>

   </listitem>
   <listitem>
    <para>
     Perform the backup, using any convenient file-system-backup tool
     such as <application>tar</application> or <application>cpio</application> (not
     <application>pg_dump</application> or
     <application>pg_dumpall</application>).  It is neither
     necessary nor desirable to stop normal operation of the database
     while you do this. See
     <xref linkend="backup-lowlevel-base-backup-data"/> for things to
     consider during this backup.
    </para>
   </listitem>
   <listitem>
    <para>
     In the same connection as before, issue the command:
<programlisting>
SELECT * FROM pg_backup_stop(wait_for_archive => true);
</programlisting>
     This terminates backup mode. On a primary, it also performs an automatic
     switch to the next WAL segment.  On a standby, it is not possible to
     automatically switch WAL segments, so you may wish to run
     <function>pg_switch_wal</function> on the primary to perform a manual
     switch. The reason for the switch is to arrange for
     the last WAL segment file written during the backup interval to be
     ready to archive.
    </para>
    <para>
     <function>pg_backup_stop</function> will return one row with three
     values. The second of these fields should