EBS snapshot backups from a FreeBSD zfs file system: zpool freeze?

[Markus Gebert]

On 03.07.2013, at 11:15, Berend de Boer <berend at pobox.com> wrote:

>>>>>> "Markus" == Markus Gebert <markus.gebert at hostpoint.ch> writes:
> 
>    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)
> 
> That seems like a very good first step!
> 
> 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.
> 
> 
>    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.
> 
> 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