<primary>configuration</primary>
     <secondary>of recovery</secondary>
     <tertiary>of a standby server</tertiary>
    </indexterm>

    <para>
     This section describes the settings that apply only for the duration of
     the recovery.  They must be reset for any subsequent recovery you wish to
     perform.
    </para>

    <para>
     <quote>Recovery</quote> covers using the server as a standby or for
     executing a targeted recovery.  Typically, standby mode would be used to
     provide high availability and/or read scalability, whereas a targeted
     recovery is used to recover from data loss.
    </para>

    <para>
     To start the server in standby mode, create a file called
     <filename>standby.signal</filename><indexterm><primary>standby.signal</primary></indexterm>
     in the data directory.  The server will enter recovery and will not stop
     recovery when the end of archived WAL is reached, but will keep trying to
     continue recovery by connecting to the sending server as specified by the
     <varname>primary_conninfo</varname> setting and/or by fetching new WAL
     segments using <varname>restore_command</varname>.  For this mode, the
     parameters from this section and <xref
     linkend="runtime-config-replication-standby"/> are of interest.
     Parameters from <xref linkend="runtime-config-wal-recovery-target"/> will
     also be applied but are typically not useful in this mode.
    </para>

    <para>
     To start the server in targeted recovery mode, create a file called
     <filename>recovery.signal</filename><indexterm><primary>recovery.signal</primary></indexterm>
     in the data directory.  If both <filename>standby.signal</filename> and
     <filename>recovery.signal</filename> files are created, standby mode
     takes precedence.  Targeted recovery mode ends when the archived WAL is
     fully replayed, or when <varname>recovery_target</varname> is reached.
     In this mode, the parameters from both this section and <xref
     linkend="runtime-config-wal-recovery-target"/> will be used.
    </para>

    <variablelist>
     <varlistentry id="guc-restore-command" xreflabel="restore_command">
      <term><varname>restore_command</varname> (<type>string</type>)
      <indexterm>
        <primary><varname>restore_command</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        The local shell command to execute to retrieve an archived segment of
        the WAL file series. This parameter is required for archive recovery,
        but optional for streaming replication.
        Any <literal>%f</literal> in the string is
        replaced by the name of the file to retrieve from the archive,
        and any <literal>%p</literal> is replaced by the copy destination path name
        on the server.
        (The path name is relative to the current working directory,
        i.e., the cluster's data directory.)
        Any <literal>%r</literal> is replaced by the name of the file containing the
        last valid restart point. That is the earliest file that must be kept
        to allow a restore to be restartable, so this information can be used
        to truncate the archive to just the minimum required to support
        restarting from the current restore. <literal>%r</literal> is typically only
        used by warm-standby configurations
        (see <xref linkend="warm-standby"/>).
        Write <literal>%%</literal> to embed an actual <literal>%</literal> character.
       </para>

       <para>
        It is important for the command to return a zero exit status
        only if it succeeds.  The command <emphasis>will</emphasis> be asked for file
        names that are not present in the archive; it must return nonzero
        when so asked.  Examples:
<programlisting>
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
</programlisting>