<literal>-</literal> (dash), causing the tar file to be
        written to <literal>stdout</literal>.
       </para>
       <para>
        This option is required.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-F <replaceable class="parameter">format</replaceable></option></term>
      <term><option>--format=<replaceable class="parameter">format</replaceable></option></term>
      <listitem>
       <para>
        Selects the format for the output. <replaceable>format</replaceable>
        can be one of the following:

        <variablelist>
         <varlistentry>
          <term><literal>p</literal></term>
          <term><literal>plain</literal></term>
          <listitem>
           <para>
            Write the output as plain files, with the same layout as the
            source server's data directory and tablespaces. When the cluster has
            no additional tablespaces, the whole database will be placed in
            the target directory. If the cluster contains additional
            tablespaces, the main data directory will be placed in the
            target directory, but all other tablespaces will be placed
            in the same absolute path as they have on the source server.
            (See <option>--tablespace-mapping</option> to change that.)
           </para>
           <para>
            This is the default format.
           </para>
          </listitem>
         </varlistentry>

         <varlistentry>
          <term><literal>t</literal></term>
          <term><literal>tar</literal></term>
          <listitem>
           <para>
            Write the output as tar files in the target directory. The main
            data directory's contents will be written to a file named
            <filename>base.tar</filename>, and each other tablespace will be
            written to a separate tar file named after that tablespace's OID.
           </para>
           <para>
            If the target directory is specified as <literal>-</literal>
            (dash), the tar contents will be written to
            standard output, suitable for piping to (for example)
            <productname>gzip</productname>. This is only allowed if
            the cluster has no additional tablespaces and WAL
            streaming is not used.
           </para>
           </listitem>
         </varlistentry>
        </variablelist></para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-i <replaceable class="parameter">old_manifest_file</replaceable></option></term>
      <term><option>--incremental=<replaceable class="parameter">old_manifest_file</replaceable></option></term>
      <listitem>
       <para>
        Performs an <link linkend="backup-incremental-backup">incremental
        backup</link>. The backup manifest for the reference
        backup must be provided, and will be uploaded to the server, which will
        respond by sending the requested incremental backup.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-R</option></term>
      <term><option>--write-recovery-conf</option></term>
      <listitem>

       <para>
        Creates a
        <link linkend="file-standby-signal"><filename>standby.signal</filename></link>
        <indexterm><primary><filename>standby.signal</filename></primary><secondary>pg_basebackup --write-recovery-conf</secondary></indexterm>
        file and appends
        connection settings to the <filename>postgresql.auto.conf</filename>
        file in the target directory (or within the base archive file when
        using tar format).  This eases setting up a standby server using the
        results of the backup.
       </para>
       <para>
        The <filename>postgresql.auto.conf</filename> file will record the connection
        settings and, if specified, the replication slot
        that <application>pg_basebackup</application> is using, so that