From owner-freebsd-stable@FreeBSD.ORG  Thu Mar 26 17:11:15 2009
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 061581065733;
	Thu, 26 Mar 2009 17:11:15 +0000 (UTC)
	(envelope-from petefrench@ticketswitch.com)
Received: from constantine.ticketswitch.com (constantine.ticketswitch.com
	[IPv6:2002:57e0:1d4e:1::3])
	by mx1.freebsd.org (Postfix) with ESMTP id BB79E8FC25;
	Thu, 26 Mar 2009 17:11:14 +0000 (UTC)
	(envelope-from petefrench@ticketswitch.com)
Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com)
	by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD)) (envelope-from <petefrench@ticketswitch.com>)
	id 1Lmt6i-0004rZ-V7; Thu, 26 Mar 2009 17:11:08 +0000
Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69
	(FreeBSD)) (envelope-from <petefrench@ticketswitch.com>)
	id 1Lmt6i-0000PI-T4; Thu, 26 Mar 2009 17:11:08 +0000
To: jake@poptart.org, peter.schuller@infidyne.com
In-Reply-To: <alpine.BSF.2.00.0903261432350.31074@cyhz.syveoyr.bet>
Message-Id: <E1Lmt6i-0000PI-T4@dilbert.ticketswitch.com>
From: Pete French <petefrench@ticketswitch.com>
Date: Thu, 26 Mar 2009 17:11:08 +0000
Cc: jacks@sage-american.com, 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 <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 17:11:16 -0000

> 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.

mysql can do this - you can flush the tables and acuire a lock
simultaneously so that you can then snapshot the uderlying filesystem
and then release the lock to let everything continue. I use this for taking
database snapshots and it works fine. I stop my slaves before snapshotting
to avoid log files changing underneath me too .... like this...

#!/bin/sh
/usr/local/bin/mysql -usnapuser -psnapuser <<EOF
        slave stop;
        flush tables with read lock;
        system /sbin/zfs snapshot archive/mysql@latest;
        unlock tables;
        slave start;
EOF

That appears to work fine. I do also do other dumps, but the above
works nicely for a quick and easy snapshot on a slave which can be
rolled back in the case of a crash (and will then update from the master
properly)

-pete.