Date: Wed, 3 Jul 2013 11:55:51 +0200 From: Markus Gebert <markus.gebert@hostpoint.ch> To: Berend de Boer <berend@pobox.com> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? Message-ID: <FF386ED5-5E9D-4073-9E67-F835BCF5D816@hostpoint.ch> In-Reply-To: <87zju43sxl.wl%berend@pobox.com> References: <87li5o5tz2.wl%berend@pobox.com> <CA%2BtpaK1jQuKneQsxkVfxJGzXdPdLZfqBM1QWQ0e19nK5t71t1Q@mail.gmail.com> <87ehbg5raq.wl%berend@pobox.com> <20130703055047.GA54853@icarus.home.lan> <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> <CADBaqmihCB5JP01hLwXTWHoZiJJ5-jkT-Ro=oDwOcKZT_zvEKA@mail.gmail.com> <A5A66641-5EF9-454E-A767-009480EE404E@dragondata.com> <14A2336A-969C-4A13-9EFA-C0C42A12039F@hostpoint.ch> <87zju43sxl.wl%berend@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03.07.2013, at 11:15, Berend de Boer <berend@pobox.com> wrote: >>>>>> "Markus" =3D=3D Markus Gebert <markus.gebert@hostpoint.ch> = writes: >=20 > Markus> 1. snapshot the zfs at the same point in time you'd issue > Markus> that ioctl on Linux > Markus> 2. take the EBS snapshot at any time > Markus> 3. clone the EBS snapshot to the new/other VM > Markus> 4. zfs import the pool there > Markus> 5. zfs rollback the filesystem to > Markus> the snapshot taken in step 1 (or clone it and use that) >=20 > That seems like a very good first step! >=20 > It's unfortunately not automatic, but for recovery purposes it should > do. This is as automatic as you make it to be :-). But yes, the code that = does that might not exist yet... > Do you think (yes, I will definitely test this), that ZFS can mount a > file system consisting of a couple of disk (raidz2 setup), and access > it even though every disk might be a backup taken at a slighty > different time? I'm not entirely sure. I've written the scenario above with one disk in = mind, which works for sure. I know that zfs keeps around a certain amount of old = transactions/uberblocks, so that in case it finds that the newest = transaction can't be used on import for some reason, it can rollback to = an older transaction (see -F option of zpool import). This usually means = data loss, but I guess that's a non-issue in your scenario, as you'll = throw away data newer than your snapshot anyway and the snapshot should = be on disk when you take the EBS snapshot. Then again, please test this, I'm not sure wether the old transactions = even help in this scenario. And if the time delta gets too big and you = do too many writes in the meantime, zfs might not be able to import the = pool, if no mutual transaction can be found anymore. Of course it'd be safest to EBS snapshot all disk at the same exact = time, but if I understand you correctly, there is no such functionality = and the OS is expected to guarantee some kind of consistency between = multiple related disks. > Obviously I'm going to throw away the mounted state and rollback to my > snapshot, but it has to be able to mount a set of disks which might be > in a terrible state first. >=20 >=20 > Markus> Also, taking the zfs snapshot should take much less time, > Markus> because you don't have to wait for the EBS snapshot to > Markus> complete before you can resume IO on the filesystem. So > Markus> you don't even depend on EBS snapshots being quick when > Markus> using the zfs approach, a big advantage in my opinion. >=20 > You don't have to wait for an EBS snapshot to complete. That can take > hours. EBS simply takes the moment in time you give the command, and > starts the backup from there. Normal I/O to the disk continues (so > uses some kind of COW system I suppose) Yes, but a zfs snapshot is near instant. ioctl, wait for sync, mark = clean, trigger EBS snapshot, ioctl again to resume IO, sounds like more = work. So I wasn't saying EBS snapshots are slow, but the whole process = probably isn't as quick as just taking a zfs snapshot. zfs probably will = loose some time when importing on the new VM, but at that point you = usually don't care. Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF386ED5-5E9D-4073-9E67-F835BCF5D816>