Date: Thu, 26 Mar 2009 14:45:45 +0000 (GMT) From: Jake Scott <jake@poptart.org> To: Peter Schuller <peter.schuller@infidyne.com> Cc: "Jack L. Stone" <jacks@sage-american.com>, freebsd-stable@freebsd.org, fs@freebsd.org, Mike Tancsa <mike@sentex.net> Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) Message-ID: <alpine.BSF.2.00.0903261432350.31074@cyhz.syveoyr.bet> In-Reply-To: <20090326140131.GA45201@hyperion.scode.org> References: <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi.. On Thu, 26 Mar 2009, Peter Schuller wrote: >>> Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >>> to that effect and has no effect on solving the problem(s). >> >> Unless the filesystem is very busy, you will get your data backed up. >> If you have things like databases, I still would not trust >> snapshots. > > Uh. If backuping up a live database from a snapshot is not > trustworthy, either the snapshot facility is broken or the database is > broken (i.e., not crash-safe to begin with). Exactly right - if you backup a database by relying on storage snapshots then the best you will end up with is a database that needs to be recovered when you restore those volumes (crash consistent). That's not a good place to be in when your production DB has just blown up. In addition, there are all sorts of complications which mean that you might need to freeze IO on multiple volumes simultaneously in order for this to have a chance of being successful (maintaining write-order-fidelity). I would strongly discourage anyone from using this method of backup for anything that is considered production, thought it might do you for making QA clones of a running database. > That said there are plenty of other reasos to use proper dump tools > (data portability, confirming the ability to actually read all rows > from a table, using a more often exercised code path and perhaps less > likely to have edge case bugs, etc). Absolutely. You really must use a tool that interacts with the database to perform the backup. Most commercial DBs have hooks that allow the backup routines to call out to custom snapshot facilities. One would usually request a backup through the database, which would then freeze IO to its data files and maybe log files, deal with flushing caches etc and then call your snapshot routine. I'm not aware that MySQL and Postgres do though so the best you can do is a dump. Jake
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903261432350.31074>