|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.117 2008/04/05 01:34:05 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.118 2008/04/09 02:52:04 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="backup"> |
4 | 4 | <title>Backup and Restore</title> |
@@ -386,9 +386,17 @@ tar -cf backup.tar /usr/local/pgsql/data |
386 | 386 | not be possible to use snapshot backup because the snapshots |
387 | 387 | <emphasis>must</> be simultaneous. |
388 | 388 | Read your file system documentation very carefully before trusting |
389 | | - to the consistent-snapshot technique in such situations. The safest |
390 | | - approach is to shut down the database server for long enough to |
391 | | - establish all the frozen snapshots. |
| 389 | + to the consistent-snapshot technique in such situations. |
| 390 | + </para> |
| 391 | + |
| 392 | + <para> |
| 393 | + If simultaneous snapshots are not possible, one option is to shut down |
| 394 | + the database server long enough to establish all the frozen snapshots. |
| 395 | + Another option is perform a continuous archiving base backup (<xref |
| 396 | + linkend="backup-base-backup">) because such backups are immune to file |
| 397 | + system changes during the backup. This requires enabling continuous |
| 398 | + archiving just during the backup process; restore is done using |
| 399 | + continuous archive recovery (<xref linkend="backup-pitr-recovery">). |
392 | 400 | </para> |
393 | 401 |
|
394 | 402 | <para> |
|