Peter Schuller wrote:
The issue with backing up a database live comes in when the filesystem
where the database and transaction log files are DIFFERS. You can get
into a pathological case in that instance.
If the transaction log and database itself are both on the same
snapshotted entity (that is, the snapshot is pulled at the same instant
in time for both) what you get BETTER be restorable or your database's
transaction log facility doesn't really do what it promises to do!
Absolutely. Doing things like snapshot based backups of databases
assumes you know what you're doing since it is not something which is
documented as an official procedure in your typical database
administrator guide.
Personally, while I would use such schemes, I would always use a plain
fully supported regular dump as a fallback position. I would only rely
on snapshot based processes to do fancy stuff (such as near-realtime
hot standby with zfs snaps + serialized incrementals).
To add to this what SHOULD (ha!) work is to dump the database partition
FIRST and THEN dump the Transaction Log partition.
If you do it in the other order you WILL get screwed, as you will have
transactions committed in the database that are not in the XLOG. That
is essentially guaranteed to blow up in your face.
As always any backup scheme has to be TESTED so you can prove to your
own satisfaction that it is RESTORABLE. I can't tell you how many
business clients I have run into (and not only on Unix machines) that
have wind up with lots of backups and NONE of them can be restored -
because they never TESTED their backup strategy.
--
--
Karl Denninger
k...@denninger.net
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
