Heikki Linnakangas wrote:
> > However, it occurred to me that if someone turned on continuous arciving
> > during the file system snapshots, then you could use PITR to recover
> > from file system snapshots that were not simultaneous.
> >
> > Should this be documented?
>
> If you use continuous archiving, the snapshot indeed doesn't need to be
> atomic. In fact, you can use tar instead of filesystem snapshots. And in
> fact, that's exactly how you take the base backup with PITR, and that is
> documented.
Right. My point is that for people who don't want continuous archiving,
doing it _only_ during the snapshots allows multi-filesystem snapshots
to be reliable.
> Incidentally, I looked at this stuff just a couple of days ago, and it
> occurred to me that we really should make it easier to take a hot backup
> with that mechanism. We shouldn't require setting up archive_command,
> and WAL archiving, if all you want is to take a backup from a live
> system. From user point of view, it should be a matter of:
>
> 1. call pg_start_backup('foo')
> 2. tar/etc. the whole data directory, except for pg_xlog
> 3. tar pg_xlog
> 4. call pg_stop_backup()
>
> If we just made sure that we don't delete or recycle any WAL files while
> the backup is being taken, that would work, right?
Yes, agreed. This is exactly the issue I was raising. You are showing
it as tar, but I am showing it as multi-volume snapshots. To do what
you want to do above, you would have to stop doing checkpoints during
the start/stop, which I am a little afraid of with 'tar --- file system
snapshots are much faster. Also, you would have to file system snapshot
the /pg_xlog file system at the end but it is the same logic.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
