From owner-freebsd-virtualization@FreeBSD.ORG Mon Dec 8 23:59:39 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94B73363 for ; Mon, 8 Dec 2014 23:59:39 +0000 (UTC) Received: from alto.onthenet.com.au (alto2.onthenet.com.au [203.13.68.14]) by mx1.freebsd.org (Postfix) with ESMTP id 58656358 for ; Mon, 8 Dec 2014 23:59:38 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 4BCBA12555; Tue, 9 Dec 2014 09:59:36 +1000 (EST) Received: from Peters-MacBook-Pro.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.4.4-GA) with ESMTP id CAH76932 (AUTH peterg@ptree32.com.au); Tue, 9 Dec 2014 09:59:35 +1000 Message-ID: <54863B64.5010608@freebsd.org> Date: Mon, 08 Dec 2014 15:59:32 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Subject: Re: backups of bhyve images References: <20141208163358.GA52969@potato.growveg.org> In-Reply-To: <20141208163358.GA52969@potato.growveg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:59:39 -0000 Hi John, > Basically, what I want to do is to run accurate backups without shutting > down and restarting the VM. Is this possible? If it isn't, I think the > only alternative is to make a script that shuts the vm down, copies it, > restarts the vm then runs its compression and backup-over-ssh routine. It's not possible in the general case to take a snapshot of the underlying image since as others have pointed out, it may not be consistent on disk since there are still data/metadata from the guest's filesystem that haven't made it out to disk. Commercial hypervisors provide guest tools that allow a filesystem quiesce/sync that lock-steps with external snapshotting machinery. However, one option that could be worth investigating is using ZFS in the guest with disk images backed by a zvol on the host. ZFS guarantees on-disk consistency, and a zvol provides instantaneous snapshots. Worst case is that some writes are not picked up at snapshot time, but that seems preferable to having to force a full sync in the guest. later, Peter.