can be multiple <command>pg_basebackup</command>s running at the same time, but it is usually
   better from a performance point of view to take only one backup, and copy
   the result.
  </para>

  <para>
   <application>pg_basebackup</application> can make a base backup from
   not only a primary server but also a standby. To take a backup from a standby,
   set up the standby so that it can accept replication connections (that is, set
   <varname>max_wal_senders</varname> and <xref linkend="guc-hot-standby"/>,
   and configure its <filename>pg_hba.conf</filename> appropriately).
   You will also need to enable <xref linkend="guc-full-page-writes"/> on the primary.
  </para>

  <para>
   Note that there are some limitations in taking a backup from a standby:

   <itemizedlist>
    <listitem>
     <para>
      The backup history file is not created in the database cluster backed up.
     </para>
    </listitem>
    <listitem>
     <para>
      <application>pg_basebackup</application> cannot force the standby
      to switch to a new WAL file at the end of backup.
      When you are using <literal>-X none</literal>, if write activity on
      the primary is low, <application>pg_basebackup</application> may
      need to wait a long time for the last WAL file required for the backup
      to be switched and archived.  In this case, it may be useful to run
      <function>pg_switch_wal</function> on the primary in order to
      trigger an immediate WAL file switch.
     </para>
    </listitem>
    <listitem>
     <para>
      If the standby is promoted to be primary during backup, the backup fails.
     </para>
    </listitem>
    <listitem>
     <para>
      All WAL records required for the backup must contain sufficient full-page writes,
      which requires you to enable <varname>full_page_writes</varname> on the primary.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
   Whenever <application>pg_basebackup</application> is taking a base
   backup, the server's <structname>pg_stat_progress_basebackup</structname>
   view will report the progress of the backup.
   See <xref linkend="basebackup-progress-reporting"/> for details.
  </para>
 </refsect1>

 <refsect1>
  <title>Options</title>

   <para>
    The following command-line options control the location and format of the
    output:

    <variablelist>
     <varlistentry>
      <term><option>-D <replaceable class="parameter">directory</replaceable></option></term>
      <term><option>--pgdata=<replaceable class="parameter">directory</replaceable></option></term>
      <listitem>
       <para>
        Sets the target directory to write the output to.
        <application>pg_basebackup</application> will create this directory
        (and any missing parent directories) if it does not exist.  If it
        already exists, it must be empty.
       </para>
       <para>
        When the backup is in tar format, the target directory may be
        specified as <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