On Thursday 29 April 2010 06:24:54 Ron Johnson wrote: > On 04/27/2010 02:51 PM, Boyd Stephen Smith Jr. wrote: > > For "normal" file operations, taking an LVM snapshot of the mounted > > filesystem and then making your backup from that should be sufficient. > > This should even work for postgreSQL database files (though, it is not > > optimal). MySQL has a history of being more flaky, but it might work > > there as well. > > > > If you snapshot a mounted file system, the snapshot will be approximately > > equivalent to the original file system, uncleanly unmounted at that exact > > moment (think: power failure). It's possible to then take backups of an > > active system with no downtime (although I/O load will certainly go up > > during the backup). If you mount the snapshot as part of the backup > > procedure, a journaled file system will want to replay the journal then. > > Otherwise, a journal replay will be required at restore time. PostgreSQL > > (etc.) will also end up doing a journal replay / recovery at restore > > time. > > A proper RDBMS will have a hot-backup feature, so I'd still say that > a file-only backup is the way to go.
Just because something doesn't advertise itself as an RDBMS doesn't mean that it won't be in the middle of doing something "odd"[1] to a file. You should, if at all possible, quiesce the filesystem before you back it up, or at least quiesce the individual files prior to back up. cp -a and rsync will not do either by themselves. Most of what my message said about doing a unmount, snapshot, mount dance would also apply to a remount r/o, snapshot, remount r/w dance and it may be more practical for some file systems. Both MySQL and PostgreSQL have "hot" backup procedures that do not require taking down the database daemon. Having PostgreSQL relocate its journal files rather than delete them can result in a "live" backup, that is literally only a few dozen write-queries behind the production server, at most. [1] I should really be more specific instead of saying "odd" and "normal". "Normal" means writing to the end of a file, truncating a file at any offset, reading from any part of a file. "Odd" means (over) writing at a position that is not the end of the file. RDBMS are more likely to do the last (updating fixed-length records, or the fixed-length parts of records), but they are not the only application that might have a good reason for doing it that way. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
