Marc Bevand wrote:
o In order to restore the latest snapshot T-0, all the zfs streams,
T-2, T-1 and T-0, have to be decrypted, then zfs receive'd. It is
slow and inconvenient.
True, but presumably restoring the snapshots is a rare event.
o My example only backs up the last 3 snapshots, but ideally I would
like to fit as many as possible in the offsite pool. However, because
of the unpredictable compression efficiency, I can't tell which
snapshot I should start from when creating the first full stream.
I thought that your onsite and offsite pools were the same size? If so then
you should be able to fit the entire contents of the onsite pool in one of
the offsite ones ('zfs send' will inflate the data a small bit, but gzip
should more than make up for it).
That said, if you couldn't fit the entire onsite pool in your offiste pool,
then you could make use of some additional space accounting data to tell how
much space the 'zfs send' streams will take. (Although compression
efficiency is still variable, you could probably make a good enough guess.)
That's on our long-term to-do list.
Also, if you can afford to waste some space, you could do something like:
zfs send [EMAIL PROTECTED] | ...
zfs send -i T-100 [EMAIL PROTECTED] | ...
zfs send -i T-100 [EMAIL PROTECTED] | ...
zfs send -i T-99 [EMAIL PROTECTED] | ...
zfs send -i T-98 [EMAIL PROTECTED] | ...
...
until you run out of space. Of course, you need at least enough space for
the oldest and newest snapshots.
Glad to hear that ZFS (and send|recv) is useful to you aside from these
issues, and thanks for letting us know about the difficulties too!
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
