Cheryl Grant wrote: >>> 2844LOG: starting point-in-time recovery to 2013-02-26 12:53:00+11 >>> 2844LOG: restored log file "000000010000017D00000056" from archive >>> 2844LOG: unexpected pageaddr 17D/2E000000 in log file 381, segment 86, >>> offset 0 >>> 2844LOG: invalid checkpoint record >>> 2844FATAL: could not locate required checkpoint record
>> That indicates that the WAL file 000000010000017D00000056 is >> broken. Are you sure that it is from the PostgreSQL server >> you backed up? How did you archive the WAL files? > I'm doing a pg_basebackup to create the instance with -x specified so some of > the logs are in the > pg_xlog directory after the backup. It always seems to fall over with the > same error on the first log. > I've tried this numerous times with different backups and it always fails on > the first log. Ah, but what the above log entry says is that it took the WAL file from the archive location and copied it into pg_xlog. So the WAL file created by the -x switch of pg_basebackup was overwritten with a file from the archive. Does the archive contain a different (= wrong) copy of the WAL file? > I've used the same method to create a hot standby which works, but only > because streaming replication > is getting the data across. But this won't work in a disaster recovery > situation. Even with streaming replication that should not work, if the problem is a bad WAL file in the archive. > My backup command for the primary WAL logs is a script. Here is the contents > of the script: > > ls -1 $PGDATA/pg_xlog | while read f; do > { > if [ -f $PGDATA/pg_xlog/$f ] ; then > if [ ! -f $LOGPATH/$f ] ; then > echo "$PGDATA/pg_xlog/$f" >> $LOGFILE > cp $PGDATA/pg_xlog/$f $LOGPATH > status=$? > echo status=$status >> $LOGFILE > scp $LOGPATH/$f $SCPHOST:$LOGPATH & > fi > fi > } done; That's not your archive_command, right? At what points is this script run? Could it have copied an incomplete WAL file to the archive? The good way to archive WAL files is to specify an appropriate archive_command in postgresql.conf. Then each WAL file is archived as soon as it is full, and the PostgreSQL server knows if archiving worked or not. Yours, Laurenz Albe -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin