</para>
</sect2>
- <sect2 id="backup-incremental-updated">
- <title>Incrementally Updated Backups</title>
-
- <indexterm zone="backup">
- <primary>incrementally updated backups</primary>
- </indexterm>
-
- <indexterm zone="backup">
- <primary>change accumulation</primary>
- </indexterm>
-
- <para>
- In a warm standby configuration, it is possible to offload the expense of
- taking periodic base backups from the primary server; instead base backups
- can be made by backing
- up a standby server's files. This concept is generally known as
- incrementally updated backups, log change accumulation, or more simply,
- change accumulation.
- </para>
-
- <para>
- If we take a backup of the standby server's data directory while it is processing
- logs shipped from the primary, we will be able to reload that data and
- restart the standby's recovery process from the last restart point.
- We no longer need to keep WAL files from before the restart point.
- If we need to recover, it will be faster to recover from the incrementally
- updated backup than from the original base backup.
- </para>
-
- <para>
- Since the standby server is not <quote>live</>, it is not possible to
- use <function>pg_start_backup()</> and <function>pg_stop_backup()</>
- to manage the backup process; it will be up to you to determine how
- far back you need to keep WAL segment files to have a recoverable
- backup. You can do this by running <application>pg_controldata</>
- on the standby server to inspect the control file and determine the
- current checkpoint WAL location, or by using the
- <varname>log_restartpoints</> option to print values to the server log.
- </para>
- </sect2>
</sect1>
<sect1 id="migration">