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
        streaming replication and <link linkend="logicaldecoding-replication-slots-synchronization">
        logical replication slot synchronization</link> will use the same
        settings later on. The dbname will be recorded only if the dbname was
        specified explicitly in the connection string or <link linkend="libpq-envars">
        environment variable</link>.
       </para>

      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-t <replaceable class="parameter">target</replaceable></option></term>
      <term><option>--target=<replaceable class="parameter">target</replaceable></option></term>
      <listitem>

       <para>
        Instructs the server where to place the base backup. The default target
        is <literal>client</literal>, which specifies that the backup should
        be sent to the machine where <application>pg_basebackup</application>
        is running. If the target is instead set to
        <literal>server:/some/path</literal>, the backup will be stored on
        the machine where the server is running in the
        <literal>/some/path</literal> directory. Storing a backup on the
        server requires superuser privileges or having privileges of the
        <literal>pg_write_server_files</literal> role. If the target is set to
        <literal>blackhole</literal>, the contents are discarded and not
        stored anywhere. This should only be used for testing purposes, as you
        will not end up with an actual backup.
       </para>

       <para>
        Since WAL streaming is implemented by
        <application>pg_basebackup</application> rather than by the server,
        this option cannot be used together with <literal>-Xstream</literal>.
        Since that is the default, when this option is specified, you must also
        specify either <literal>-Xfetch</literal> or <literal>-Xnone</literal>.
       </para>

      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-T <replaceable class="parameter">olddir</replaceable>=<replaceable class="parameter">newdir</replaceable></option></term>
      <term><option>--tablespace-mapping=<replaceable class="parameter">olddir</replaceable>=<replaceable class="parameter">newdir</replaceable></option></term>
      <listitem>
       <para>
        Relocates the tablespace in directory <replaceable>olddir</replaceable>
        to <replaceable>newdir</replaceable> during the backup.  To be
        effective, <replaceable>olddir</replaceable> must exactly match the
        path specification of the tablespace as it is defined on the source
        server.  (But it is not an error if there is no tablespace
        in <replaceable>olddir</replaceable> on the source server.)
        Meanwhile <replaceable>newdir</replaceable> is a directory in the
        receiving host's filesystem.  As with the main target directory,
        <replaceable>newdir</replaceable> need not exist already, but if
        it does exist it