Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
Cc: Imre Oolberg <imre(at)auul(dot)pri(dot)ee>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal
Date: 2011-01-03 18:42:32
Message-ID: 22500.1294080152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Scott Ribe <scott_ribe(at)elevated-dev(dot)com> writes:
> On Jan 3, 2011, at 11:22 AM, Imre Oolberg wrote:
>> But http://www.postgresql.org/docs/9.0/interactive/continuous-archiving.html suggests to use tar on rsync and i guess that PostgreSQL recovery with wal files takes care of these inconsistencies that are created during copying filesystem, right?

> Yes, but the database is recovered to the consistent state as of the pg_start_backup command, as I pointed out to you before. Results of transactions that commit after the pg_start_backup command will not be in the backed up database.

That's either incorrect or poorly worded. The only way to get a
consistent, usable database is to replay all the WAL that was generated
between pg_start_backup and pg_stop_backup. That will fix up whatever
inconsistencies exist in the base backup fileset. Once you've done
that, you do have the results of transactions that committed after
pg_start_backup (and up to pg_stop_backup). If you haven't done that,
what you have is an inconsistent pile of rather arbitrary bits. The
base backup by itself (without the concurrently-created WAL) is
*useless*.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Scott Ribe 2011-01-03 18:49:37 Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal
Previous Message Kevin Grittner 2011-01-03 18:38:33 Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal