diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 6eaed1e..09f0787 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -587,7 +587,8 @@ tar -cf backup.tar /usr/local/pgsql/data the administrator specify a shell command to be executed to copy a completed segment file to wherever it needs to go. The command could be as simple as a cp, or it could invoke a complex shell - script — it's all up to you. + script — it's all up to you. There however are some things to consider + when creating such a command, most of which are covered below. @@ -636,7 +637,11 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0 PostgreSQL will assume that the file has been successfully archived, and will remove or recycle it. However, a nonzero status tells PostgreSQL that the file was not archived; - it will try again periodically until it succeeds. + it will try again periodically until it succeeds. Note that an exit + status of 128 or higher will cause the archiver to exit (and restart), + resulting in a (potentially misleading) FATAL error in the server log. + E.g., rsync tends to return exit statuses of 255 on network + issues. @@ -696,6 +701,14 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0 preserve the file name (%f). + + Depending on your specific requirements (and datacenter layout), you may + want to make sure that the archived WAL segments have been written out to + persistent storage before the archive_command returns. + Otherwise, a WAL segment that is assumed to be archived could be recycled + prematurely, rendering your archive incomplete in case of a power outage. + + Note that although WAL archiving will allow you to restore any modifications made to the data in your PostgreSQL database,