From: | "John Sidney-Woollett" <johnsw(at)wardbrook(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Cott Lang" <cott(at)internetstaff(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: tablespaces a priority for 7.5? |
Date: | 2004-01-22 17:07:49 |
Message-ID: | 1302.192.168.0.64.1074791269.squirrel@mercury.wardbrook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane said:
> To do these, you would take a *physical* dump of the
> database directory as a baseline, and thereafter copy WAL segments off
> to tape or whatever you are using as archive media. Recovery would
> consist of restoring the physical baseline dump, and then replaying WAL
> against it up to whatever point in time you wanted to recover to. You
> would, therefore, need to keep a continuous sequence of WAL files back
> to the time of your most recent baseline backup.
This is similar to Oracle...
With Oracle you have the option of EITHER exporting the database
(equivalent to doing pg_dump) OR taking the database offline and carrying
out a file system level copy of the database files.
Recovery can be accomplished by either restoring the backup database files
or creating a new database by importing the most recent export/dump file.
After that you apply the archive logs (equivalent to WAL segments) to
bring your database up to date.
One caveat for Oracle (at least in 8.1.x) is that DDL statements are not
recorded in the archive logs, and can screw things up. Best to take a new
export/dump after making DDL changes!
The difference between Oracle and Postgres appears to be that posgres
requires a file system level copy of the database instead of being able to
make use of a dump file for this type of recovery. Is that correct?
John Sidney-Woollett
From | Date | Subject | |
---|---|---|---|
Next Message | Henk van Lingen | 2004-01-22 17:11:36 | Re: trust auth in 7.4 |
Previous Message | Jeff Bowden | 2004-01-22 17:03:13 | Re: embedded/"serverless" (Re: serverless postgresql) |