Bruce Momjian wrote:
> Right now it isn't possible to use file system snapshots a reliable
> backup if you are using multiple file systems for tablespaces because
> most systems don't allow the simultaneous snapshoting of multiple file
> system. Our documentation mentions this:
>
> If your database is spread across multiple file systems, there might not
> be any way to obtain exactly-simultaneous frozen snapshots of all the
> volumes. For example, if your data files and WAL log are on different
> disks, or if tablespaces are on different file systems, it might not be
> possible to use snapshot backup because the snapshots must be
> simultaneous. Read your file system documentation very carefully before
> trusting to the consistent-snapshot technique in such situations. The
> safest approach is to shut down the database server for long enough to
> establish all the frozen snapshots.
>
> 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.
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?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com