|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.88 2006/09/19 19:04:51 neilc Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.89 2006/10/02 22:33:02 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="backup"> |
4 | 4 | <title>Backup and Restore</title> |
@@ -1167,6 +1167,48 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows |
1167 | 1167 | </para> |
1168 | 1168 | </sect2> |
1169 | 1169 |
|
| 1170 | + <sect2 id="backup-incremental-updated"> |
| 1171 | + <title>Incrementally Updated Backups</title> |
| 1172 | + |
| 1173 | + <indexterm zone="backup"> |
| 1174 | + <primary>incrementally updated backups</primary> |
| 1175 | + </indexterm> |
| 1176 | + |
| 1177 | + <indexterm zone="backup"> |
| 1178 | + <primary>change accumulation</primary> |
| 1179 | + </indexterm> |
| 1180 | + |
| 1181 | + <para> |
| 1182 | + Restartable Recovery can also be utilised to offload the expense of |
| 1183 | + taking periodic base backups from a main server, by instead backing |
| 1184 | + up a Standby server's files. This concept is also generally known as |
| 1185 | + incrementally updated backups, log change accumulation or more simply, |
| 1186 | + change accumulation. |
| 1187 | + </para> |
| 1188 | + |
| 1189 | + <para> |
| 1190 | + If we take a backup of the server files whilst a recovery is in progress, |
| 1191 | + we will be able to restart the recovery from the last restartpoint. |
| 1192 | + That backup now has many of the changes from previous WAL archive files, |
| 1193 | + so this version is now an updated version of the original base backup. |
| 1194 | + If we need to recover, it will be faster to recover from the |
| 1195 | + incrementally updated backup than from the base backup. |
| 1196 | + </para> |
| 1197 | + |
| 1198 | + <para> |
| 1199 | + To make use of this capability you will need to set up a Standby database |
| 1200 | + on a second system, as described in <xref linkend="warm-standby">. By |
| 1201 | + taking a backup of the Standby server while it is running you will |
| 1202 | + have produced an incrementally updated backup. Once this configuration |
| 1203 | + has been implemented you will no longer need to produce regular base |
| 1204 | + backups of the Primary server: all base backups can be performed on the |
| 1205 | + Standby server. If you wish to do this, it is not a requirement that you |
| 1206 | + also implement the failover features of a Warm Standby configuration, |
| 1207 | + though you may find it desirable to do both. |
| 1208 | + </para> |
| 1209 | + |
| 1210 | + </sect2> |
| 1211 | + |
1170 | 1212 | <sect2 id="continuous-archiving-caveats"> |
1171 | 1213 | <title>Caveats</title> |
1172 | 1214 |
|
@@ -1317,6 +1359,14 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows |
1317 | 1359 | really offers a solution for Disaster Recovery, not HA. |
1318 | 1360 | </para> |
1319 | 1361 |
|
| 1362 | + <para> |
| 1363 | + When running a Standby Server, backups can be performed on the Standby |
| 1364 | + rather than the Primary, thereby offloading the expense of |
| 1365 | + taking periodic base backups. (See |
| 1366 | + <xref linkend="backup-incremental-updated">) |
| 1367 | + </para> |
| 1368 | + |
| 1369 | + |
1320 | 1370 | <para> |
1321 | 1371 | Other mechanisms for High Availability replication are available, both |
1322 | 1372 | commercially and as open-source software. |
|