increase the time required to complete
        the backup.
       </para>
       <para>
        Using a SHA hash function provides a cryptographically secure digest
        of each file for users who wish to verify that the backup has not been
        tampered with, while the CRC-32C algorithm provides a checksum that is
        much faster to calculate; it is good at catching errors due to accidental
        changes but is not resistant to malicious modifications.  Note that, to
        be useful against an adversary who has access to the backup, the backup
        manifest would need to be stored securely elsewhere or otherwise
        verified not to have been modified since the backup was taken.
       </para>
       <para>
        <xref linkend="app-pgverifybackup"/> can be used to check the
        integrity of a backup against the backup manifest.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--manifest-force-encode</option></term>
      <listitem>
       <para>
        Forces all filenames in the backup manifest to be hex-encoded.
        If this option is not specified, only non-UTF8 filenames are
        hex-encoded. This option is mostly intended to test that tools which
        read a backup manifest file properly handle this case.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-estimate-size</option></term>
      <listitem>
       <para>
        Prevents the server from estimating the total
        amount of backup data that will be streamed, resulting in the
        <structfield>backup_total</structfield> column in the
        <structname>pg_stat_progress_basebackup</structname> view
        always being <literal>NULL</literal>.
       </para>
       <para>
        Without this option, the backup will start by enumerating
        the size of the entire database, and then go back and send
        the actual contents. This may make the backup take slightly
        longer, and in particular it will take longer before the first
        data is sent. This option is useful to avoid such estimation
        time if it's too long.
       </para>
       <para>
        This option is not allowed when using <option>--progress</option>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-manifest</option></term>
      <listitem>
       <para>
        Disables generation of a backup manifest. If this option is not
        specified, the server will generate and send a backup manifest
        which can be verified using <xref linkend="app-pgverifybackup"/>.
        The manifest is a list of every file present in the backup with the
        exception of any WAL files that may be included. It also stores the
        size, last modification time, and an optional checksum for each file.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-slot</option></term>
      <listitem>
       <para>
        Prevents the creation of a temporary replication slot
        for the backup.
       </para>
       <para>
        By default, if log streaming is selected but no slot name is given
        with the <option>-S</option> option, then a temporary replication
        slot is created (if supported by the source server).
       </para>
       <para>
        The main purpose of this option is to allow taking a base backup when
        the server has no free replication slots.  Using a replication slot
        is almost always preferred, because it prevents needed WAL from being
        removed by the server during the backup.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-verify-checksums</option></term>
      <listitem>
       <para>
        Disables verification of checksums, if they are enabled on the server
        the base backup is taken from.
       </para>
       <para>
        By default, checksums