EBS snapshot backups from a FreeBSD zfs file system: zpool freeze?
Daniel Kalchev
daniel at digsys.bg
Wed Jul 3 13:18:42 UTC 2013
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
More information about the freebsd-fs
mailing list