1
- <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.99 2007/07/16 22:20:51 momjian Exp $ -->
1
+ <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.100 2007/09/14 04:15:50 momjian Exp $ -->
2
2
3
3
<chapter id="backup">
4
4
<title>Backup and Restore</title>
@@ -729,16 +729,17 @@ SELECT pg_stop_backup();
729
729
<para>
730
730
Some backup tools that you might wish to use emit warnings or errors
731
731
if the files they are trying to copy change while the copy proceeds.
732
- This situation is normal, and not an error, when taking a base backup of
733
- an active database; so you need to ensure that you can distinguish
732
+ This situation is normal, and not an error, when taking a base backup
733
+ of an active database; so you need to ensure that you can distinguish
734
734
complaints of this sort from real errors. For example, some versions
735
- of <application>rsync</> return a separate exit code for <quote>vanished
736
- source files</>, and you can write a driver script to accept this exit
737
- code as a non-error case. Also, some versions of GNU
738
- <application>tar</> consider it an error if a file is changed while
739
- <application>tar</> is copying it. Fortunately, GNU
740
- <application>tar</> versions 1.16 and later exit with <literal>1</>
741
- if files changed during the backup, and <literal>2</> for other errors.
735
+ of <application>rsync</> return a separate exit code for
736
+ <quote>vanished source files</>, and you can write a driver script to
737
+ accept this exit code as a non-error case. Also, some versions of
738
+ GNU <application>tar</> consider it an error if a file was truncated
739
+ while <application>tar</> is copying it. Fortunately, GNU
740
+ <application>tar</> versions 1.16 and later exits with <literal>1</>
741
+ if a file was changed during the backup, and <literal>2</> for other
742
+ errors.
742
743
</para>
743
744
744
745
<para>
0 commit comments