From owner-freebsd-stable@FreeBSD.ORG Thu Mar 26 15:24:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 746071065670; Thu, 26 Mar 2009 15:24:16 +0000 (UTC) (envelope-from jake@poptart.org) Received: from plum.flirble.org (plum.flirble.org [194.70.3.20]) by mx1.freebsd.org (Postfix) with ESMTP id 322EE8FC12; Thu, 26 Mar 2009 15:24:15 +0000 (UTC) (envelope-from jake@poptart.org) Received: from jacob (helo=localhost) by plum.flirble.org with local-esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lmqq2-0005KC-I4; Thu, 26 Mar 2009 14:45:46 +0000 Date: Thu, 26 Mar 2009 14:45:45 +0000 (GMT) From: Jake Scott To: Peter Schuller In-Reply-To: <20090326140131.GA45201@hyperion.scode.org> Message-ID: 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> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Jack L. Stone" , freebsd-stable@freebsd.org, fs@freebsd.org Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:24:17 -0000 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