From owner-freebsd-fs@FreeBSD.ORG Wed Jul 3 13:18:42 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24D851C2 for ; Wed, 3 Jul 2013 13:18:42 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) by mx1.freebsd.org (Postfix) with ESMTP id 81CDE1C21 for ; Wed, 3 Jul 2013 13:18:41 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r63D0P1V036196 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 3 Jul 2013 16:00:26 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <51D42069.5060409@digsys.bg> Date: Wed, 03 Jul 2013 16:00:25 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? References: <87li5o5tz2.wl%berend@pobox.com> <87ehbg5raq.wl%berend@pobox.com> <20130703055047.GA54853@icarus.home.lan> <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> <14A2336A-969C-4A13-9EFA-C0C42A12039F@hostpoint.ch> <87zju43sxl.wl%berend@pobox.com> <87ppuz51os.wl%berend@pobox.com> In-Reply-To: <87ppuz51os.wl%berend@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 13:18:42 -0000 On 03.07.13 14:21, Berend de Boer wrote: > And after you have done your zfs snapshot, you're not done either! You > have to transfer it somewhere, probably compressed, so your (p)bzip2 > dominates your CPUs, your network bandwidth is gone, etc. The idea that was proposed was to create an local ZFS snapshot, that is not being sent anywhere. Because the ZFS snapshot is a ZIL commit, it can be very fast. Well, how fast, depends on some conditions - I have an system that sometimes takes minutes for a snapshot, but .. I am really torturing ZFS there. With the local ZFS snapshot, you then trigger an EBS snapshot of your disks. That is more or less identical to your server losing power and then coming back -- you only are sure there is a consistent snapshot of the filesystem available. However, whether this suits you or not is another matter. Do you want to essentially emulate power loss/restart of the server when you revert to use those snapshots? If so, then you are ok. ZFS has you covered. Perhaps even without making the snapshot in the first place. But, if you want your application data consistent on disk, then temporarily stopping the applications is the only safe way -- FreeBSD/ZFS, Linux or what you have won't make any difference. > So a backup starts to becomes a really high impact event, while an EBS > snapshot today isn't a big deal. Slightly degraded performance > perhaps, but not much. It seems, Amazon uses some sort of ZFS (volume) snapshots in order to implement the functionality of EBS. Why it would take hours to complete is hard to understand, perhaps they are actually backing it up somewhere too, using ZFS send/receive (or equivalents if they don't use ZFS). Daniel