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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
