backup.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

    </para>
   </listitem>
   <listitem>
    <para>
     Again connect to the database as a superuser, and issue the command
<programlisting>
SELECT pg_stop_backup();
</programlisting>
     This should return successfully.
    </para>
   </listitem>
   <listitem>
    <para>
     Once the WAL segment files used during the backup are archived as part
     of normal database activity, you are done.
    </para>
   </listitem>
  </orderedlist>
   </para>

   <para>
    Some backup tools that you might wish to use emit warnings or errors
    if the files they are trying to copy change while the copy proceeds.
    This situation is normal, and not an error, when taking a base backup of
    an active database; so you need to ensure that you can distinguish
    complaints of this sort from real errors.  For example, some versions
    of <application>rsync</> return a separate exit code for <quote>vanished
    source files</>, and you can write a driver script to accept this exit
    code as a non-error case.  Also,
    some versions of GNU <application>tar</> consider it an error if a file
    is changed while <application>tar</> is copying it.  There does not seem
    to be any very convenient way to distinguish this error from other types
    of errors, other than manual inspection of <application>tar</>'s messages.
    GNU <application>tar</> is therefore not the best tool for making base
    backups.
   </para>

   <para>
    It is not necessary to be very concerned about the amount of time elapsed
    between <function>pg_start_backup</> and the start of the actual backup,
    nor between the end of the backup and <function>pg_stop_backup</>; a
    few minutes' delay won't hurt anything.  You
    must however be quite sure that these operations are carried out in
    sequence and do not overlap.
   </para>

   <para>
    Be certain that your backup dump includes all of the files underneath
    the database cluster directory (e.g., <filename>/usr/local/pgsql/data</>).
    If you are using tablespaces that do not reside underneath this directory,
    be careful to include them as well (and be sure that your backup dump
    archives symbolic links as links, otherwise the restore will mess up
    your tablespaces).
   </para>

   <para>
    You may, however, omit from the backup dump the files within the
    <filename>pg_xlog/</> subdirectory of the cluster directory.  This
    slight complication is worthwhile because it reduces the risk
    of mistakes when restoring.  This is easy to arrange if
    <filename>pg_xlog/</> is a symbolic link pointing to someplace outside
    the cluster directory, which is a common setup anyway for performance
    reasons.
   </para>

   <para>
    To make use of this backup, you will need to keep around all the WAL
    segment files generated during and after the file system backup.
    To aid you in doing this, the <function>pg_stop_backup</> function
    creates a <firstterm>backup history file</> that is immediately
    stored into the WAL archive area. This file is named after the first
    WAL segment file that you need to have to make use of the backup.
    For example, if the starting WAL file is
    <literal>0000000100001234000055CD</> the backup history file will be
    named something like
    <literal>0000000100001234000055CD.007C9330.backup</>. (The second
    number in the file name stands for an exact position within the WAL
    file, and can ordinarily be ignored.) Once you have safely archived
    the file system backup and the WAL segment files used during the
    backup (as specified in the backup history file), all archived WAL
    segments with names numerically less are no longer needed to recover
    the file system backup and may be deleted. However, you should
    consider keeping several backup sets to be absolutely certain that
    you can recover your data. Keep in mind that only completed WAL
    segment files are archived, so there will be delay between running
    <function>pg_stop_backup</> and the archiving of all WAL segment
    files needed to make the file system backup consistent.
   </para>

   <para>
    The backup history file is just a small text file. It contains the
    label string you gave to <function>pg_start_backup</>, as well as
    the starting and ending times and WAL segments of the backup.
    If you used the label to identify where the associated dump file is kept, 
    then the archived history file is enough to tell you which dump file to
    restore, should you need to do so.
   </para>

   <para>
    Since you have to keep around all the archived WAL files back to your
    last base backup, the interval between base backups should usually be
    chosen based on how much storage you want to expend on archived WAL
    files.  You should also consider how long you are prepared to spend
    recovering, if recovery should be necessary &mdash; the system will have to
    replay all those WAL segments, and that could take awhile if it has
    been a long time since the last base backup.
   </para>

   <para>
    It's also worth noting that the <function>pg_start_backup</> function
    makes a file named <filename>backup_label</> in the database cluster
    directory, which is then removed again by <function>pg_stop_backup</>.
    This file will of course be archived as a part of your backup dump file.
    The backup label file includes the label string you gave to
    <function>pg_start_backup</>, as well as the time at which
    <function>pg_start_backup</> was run, and the name of the starting WAL
    file.  In case of confusion it will
    therefore be possible to look inside a backup dump file and determine
    exactly which backup session the dump file came from.
   </para>

   <para>
    It is also possible to make a backup dump while the postmaster is
    stopped.  In this case, you obviously cannot use
    <function>pg_start_backup</> or <function>pg_stop_backup</>, and
    you will therefore be left to your own devices to keep track of which
    backup dump is which and how far back the associated WAL files go.
    It is generally better to follow the on-line backup procedure above.
   </para>
  </sect2>

  <sect2 id="backup-pitr-recovery">
   <title>Recovering with an On-line Backup</title>

   <para>
    Okay, the worst has happened and you need to recover from your backup.
    Here is the procedure:
  <orderedlist>
   <listitem>
    <para>
     Stop the postmaster, if it's running.
    </para>
   </listitem>
   <listitem>
    <para>
     If you have the space to do so,
     copy the whole cluster data directory and any tablespaces to a temporary 
     location in case you need them later. Note that this precaution will
     require that you have enough free space on your system to hold two
     copies of your existing database. If you do not have enough space, 
     you need at the least to copy the contents of the <filename>pg_xlog</>
     subdirectory of the cluster data directory, as it may contain logs which
     were not archived before the system went down.
    </para>
   </listitem>
   <listitem>
    <para>
     Clean out all existing files and subdirectories under the cluster data
     directory and under the root directories of any tablespaces you are using.
    </para>
   </listitem>
   <listitem>
    <para>
     Restore the database files from your backup dump.  Be careful that they
     are restored with the right ownership (the database system user, not
     root!) and with the right permissions.  If you are using tablespaces,
     you may want to verify that the symbolic links in <filename>pg_tblspc/</>
     were correctly restored.
    </para>
   </listitem>
   <listitem>
    <para>
     Remove any files present in <filename>pg_xlog/</>; these came from the
     backup dump and are therefore probably obsolete rather than current.
     If you didn't archive <filename>pg_xlog/</> at all, then re-create it,
     and be sure to re-create the subdirectory
    <filename>pg_xlog/archive_status/</> as well.
    </para>
   </listitem>
   <listitem>
    <para>
     If you had unarchived WAL segment files that you saved in step 2,
     copy them into <filename>pg_xlog/</>.  (It is best to copy them,
     not move them, so that you still have the unmodified files if a
     problem occurs and you have to start over.)
    </para>
   </listitem>
   <listitem>
    <para>
     Create a recovery command file <filename>recovery.conf</> in the cluster
     data directory (see <xref linkend="recovery-config-settings">). You may 
     also want to temporarily modify <filename>pg_hba.conf</> to prevent 
     ordinary users from connecting until you are sure the recovery has worked.
    </para>
   </listitem>
   <listitem>
    <para>
     Start the postmaster.  The postmaster will go into recovery mode and
     proceed to read through the archived WAL files it needs.  Upon completion
     of the recovery process, the postmaster will rename
     <filename>recovery.conf</> to <filename>recovery.done</> (to prevent
     accidentally re-entering recovery mode in case of a crash later) and then
     commence normal database operations.
    </para>
   </listitem>
   <listitem>
    <para>
     Inspect the contents of the database to ensure you have recovered to
     where you want to be.  If not, return to step 1.  If all is well,
     let in your users by restoring <filename>pg_hba.conf</> to normal.
    </para>
   </listitem>
  </orderedlist>
   </para>

   <para>
    The key part of all this is to set up a recovery command file that
    describes how you want to recover and how far the recovery should
    run.  You can use <filename>recovery.conf.sample</> (normally
    installed in the installation <filename>share/</> directory) as a
    prototype.  The one thing that you absolutely must specify in
    <filename>recovery.conf</> is the <varname>restore_command</>,
    which tells <productname>PostgreSQL</> how to get back archived
    WAL file segments.  Like the <varname>archive_command</>, this is
    a shell command string.  It may contain <literal>%f</>, which is
    replaced by the name of the desired log file, and <literal>%p</>,
    which is replaced by the absolute path to copy the log file to.
    Write <literal>%%</> if you need to embed an actual <literal>%</>
    character in the command.  The simplest useful command is
    something like
<programlisting>
restore_command = 'cp /mnt/server/archivedir/%f %p'
</programlisting>
    which will copy previously archived WAL segments from the directory
    <filename>/mnt/server/archivedir</>.  You could of course use something
    much more complicated, perhaps even a shell script that requests the
    operator to mount an appropriate tape.
   </para>

   <para>
    It is important that the command return nonzero exit status on failure.
    The command <emphasis>will</> be asked for log files that are not present
    in the archive; it must return nonzero when so asked.  This is not an
    error condition.  Be aware also that the base name of the <literal>%p</>
    path will be different from <literal>%f</>; do not expect them to be
    interchangeable.
   </para>

   <para>
    WAL segments that cannot be found in the archive will be sought in
    <filename>pg_xlog/</>; this allows use of recent un-archived segments.
    However segments that are available from the archive will be used in
    preference to files in <filename>pg_xlog/</>.  The system will not
    overwrite the existing contents of <filename>pg_xlog/</> when retrieving
    archived files.
   </para>

   <para>
    Normally, recovery will proceed through all available WAL segments,
    thereby restoring the database to the current point in time (or as
    close as we can get given the available WAL segments).  But if you want
    to recover to some previous point in time (say, right before the junior
    DBA dropped your main transaction table), just specify the required
    stopping point in <filename>recovery.conf</>.  You can specify the stop
    point, known as the <quote>recovery target</>, either by date/time or
    by completion of a specific transaction ID.  As of this writing only
    the date/time option is very usable, since there are no tools to help
    you identify with any accuracy which transaction ID to use.
   </para>

   <note>
     <para>
      The stop point must be after the ending time of the base backup (the
      time of <function>pg_stop_backup</>).  You cannot use a base backup
      to recover to a time when that backup was still going on.  (To
      recover to such a time, you must go back to your previous base backup
      and roll forward from there.)
     </para>
    </note>

    <sect3 id="recovery-config-settings" xreflabel="Recovery Settings">
     <title>Recovery Settings</title>

     <para>
      These settings can only be made in the <filename>recovery.conf</>
      file, and apply only for the duration of the recovery. They must be
      reset for any subsequent recovery you wish to perform. They cannot be
      changed once recovery has begun.
     </para>

     <variablelist>

     <varlistentry id="restore-command" xreflabel="restore_command">
      <term><varname>restore_command</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        The shell command to execute to retrieve an archived segment of
        the WAL file series. This parameter is required.
        Any <literal>%f</> in the string is
        replaced by the name of the file to retrieve from the archive,
        and any <literal>%p</> is replaced by the absolute path to copy
        it to on the server.
        Write <literal>%%</> to embed an actual <literal>%</> character
        in the command. 
       </para>
       <para>
        It is important for the command to return a zero exit status if and
        only if it succeeds.  The command <emphasis>will</> 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 /mnt/server/archivedir/%f "%p"'  # Windows
</programlisting>
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="recovery-target-time" xreflabel="recovery_target_time">
      <term><varname>recovery_target_time</varname> 
           (<type>timestamp</type>)
      </term>
      <listitem>
       <para>
        This parameter specifies the time stamp up to which recovery
        will proceed.
        At most one of <varname>recovery_target_time</> and
        <xref linkend="recovery-target-xid"> can be specified.
        The default is to recover to the end of the WAL log.