links instead of copying files to the synthetic backup.
        Reconstruction of the synthetic backup might be faster (no file copying)
        and use less disk space, but care must be taken when using the output
        directory, because any modifications to that directory (for example,
        starting the server) can also affect the input directories. Likewise,
        changes to the input directories (for example, starting the server on
        the full backup) could affect the output directory. Thus, this option
        is best used when the input directories are only copies that will be
        removed after <application>pg_combinebackup</application> has completed.
       </para>

       <para>
        Requires that the input backups and the output directory are in the
        same file system.
       </para>

       <para>
        If a backup manifest is not available or does not contain checksum of
        the right type, hard links will still be created, but the file will be
        also read block-by-block for the checksum calculation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-n</option></term>
      <term><option>--dry-run</option></term>
      <listitem>
       <para>
        The <option>-n</option>/<option>--dry-run</option> option instructs
        <command>pg_combinebackup</command> to figure out what would be done
        without actually creating the target directory or any output files.
        It is particularly useful in combination with <option>--debug</option>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-N</option></term>
      <term><option>--no-sync</option></term>
      <listitem>
       <para>
        By default, <command>pg_combinebackup</command> will wait for all files
        to be written safely to disk.  This option causes
        <command>pg_combinebackup</command> to return without waiting, which is
        faster, but means that a subsequent operating system crash can leave
        the output backup corrupt.  Generally, this option is useful for testing
        but should not be used when creating a production installation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-o <replaceable class="parameter">outputdir</replaceable></option></term>
      <term><option>--output=<replaceable class="parameter">outputdir</replaceable></option></term>
      <listitem>
       <para>
        Specifies the output directory to which the synthetic full backup
        should be written. Currently, this argument is required.
       </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.
        <replaceable>olddir</replaceable> is the absolute path of the tablespace
        as it exists in the final backup specified on the command line,
        and <replaceable>newdir</replaceable> is the absolute path to use for the
        tablespace in the reconstructed backup.  If either path needs to contain
        an equal sign (<literal>=</literal>), precede that with a backslash.
        This option can be specified multiple times for multiple tablespaces.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--clone</option></term>
      <listitem>
       <para>
        Use efficient file cloning (also known as <quote>reflinks</quote> on
        some systems) instead of copying files to the new data directory,
        which can result in near-instantaneous