From owner-freebsd-fs@FreeBSD.ORG Thu Mar 26 14:52:34 2009 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD281065713; Thu, 26 Mar 2009 14:52:34 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95CAA8FC1A; Thu, 26 Mar 2009 14:52:34 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id E6C2423C4FF; Thu, 26 Mar 2009 15:52:33 +0100 (CET) Date: Thu, 26 Mar 2009 15:52:33 +0100 From: Peter Schuller To: Karl Denninger Message-ID: <20090326145230.GC46345@hyperion.scode.org> References: <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> <49CB8E74.9090508@denninger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <49CB8E74.9090508@denninger.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "Jack L. Stone" , freebsd-stable@freebsd.org, fs@freebsd.org, Mike Tancsa Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 14:52:38 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > The issue with backing up a database live comes in when the filesystem=20 > where the database and transaction log files are DIFFERS. You can get=20 > into a pathological case in that instance. >=20 > If the transaction log and database itself are both on the same=20 > snapshotted entity (that is, the snapshot is pulled at the same instant= =20 > in time for both) what you get BETTER be restorable or your database's=20 > 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). --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknLlq0ACgkQDNor2+l1i31tTgCdFx23SoVJBUKLPlnVAvAGV8rv zrAAoM7Wu7Qb0S8BlRJXsWmtNtOX+Dm6 =5ZS7 -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef--