* Bruce Momjian (bruce@momjian.us) wrote:
> Tom Lane wrote:
> > You are assuming here that the continuous archiving process is identical
> > to the WAL part of the base-backup process. If what you want is an
> > identifiable self-contained base backup then you copy off the WAL files
> > along with the tar dump; there's no need to force a switch of the
> > current WAL file before you copy it.
>
> If you are doing that, I think for consistency you would want a WAL file
> that is completely archived, rather than pulling the current one while
> it is being written to.
I've never been terribly pleased with having to copy the current WAL
while it's being written to. The setup we're using is basically:
On the source system:
pg_start_backup()
rsync
pg_stop_backup()
Figure out the current WAL and do a fake archive of it
On the backup server:
Grab the start/end WAL logs of the backup
Verify that all the WAL logs archived during the backup are available
It sounds like I'd be changing "do a fake-archive of the current WAL" to
"call the archive_wal function". In either case I worry some about a
possible race-condition or something going wrong which invalidates the
backup.
I think it would actually be really nice to have a 'verify_backup' tool
which could be non-interactively run against a backup to check that the
backup was successful. The one we hacked up really just checks that
there are files available with the right names. Something more
substantial than that (but without affecting the actual backup) would be
really nice since it would improve confidence that the backup really can
be restored from.
Thanks,
Stephen
