@@ -1803,46 +1803,6 @@ if (!triggered)
18031803 </para>
18041804 </sect2>
18051805
1806- <sect2 id="backup-incremental-updated">
1807- <title>Incrementally Updated Backups</title>
1808-
1809- <indexterm zone="backup">
1810- <primary>incrementally updated backups</primary>
1811- </indexterm>
1812-
1813- <indexterm zone="backup">
1814- <primary>change accumulation</primary>
1815- </indexterm>
1816-
1817- <para>
1818- In a warm standby configuration, it is possible to offload the expense of
1819- taking periodic base backups from the primary server; instead base backups
1820- can be made by backing
1821- up a standby server's files. This concept is generally known as
1822- incrementally updated backups, log change accumulation, or more simply,
1823- change accumulation.
1824- </para>
1825-
1826- <para>
1827- If we take a backup of the standby server's data directory while it is processing
1828- logs shipped from the primary, we will be able to reload that data and
1829- restart the standby's recovery process from the last restart point.
1830- We no longer need to keep WAL files from before the restart point.
1831- If we need to recover, it will be faster to recover from the incrementally
1832- updated backup than from the original base backup.
1833- </para>
1834-
1835- <para>
1836- Since the standby server is not <quote>live</>, it is not possible to
1837- use <function>pg_start_backup()</> and <function>pg_stop_backup()</>
1838- to manage the backup process; it will be up to you to determine how
1839- far back you need to keep WAL segment files to have a recoverable
1840- backup. You can do this by running <application>pg_controldata</>
1841- on the standby server to inspect the control file and determine the
1842- current checkpoint WAL location, or by using the
1843- <varname>log_restartpoints</> option to print values to the server log.
1844- </para>
1845- </sect2>
18461806 </sect1>
18471807
18481808 <sect1 id="migration">
0 commit comments