8000 Remove inaccurate "Incrementally Updated Backups" documentation section; · SudhirLonkar/postgres@8b81217 · GitHub
[go: up one dir, main page]

Skip to content

Commit 8b81217

Browse files
committed
Remove inaccurate "Incrementally Updated Backups" documentation section;
already removed from 9.0+. Applied to 8.3 and 8.4.
1 parent 336bc0d commit 8b81217

File tree

1 file changed

+0
-40
lines changed

1 file changed

+0
-40
lines changed

doc/src/sgml/backup.sgml

Lines changed: 0 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)
0