[email protected]
[Top] [All Lists]

Re: [zfs-discuss] "zfs send -i A B" with B older than A

Subject: Re: [zfs-discuss] "zfs send -i A B" with B older than A
From: Matthew Ahrens
Date: Mon, 18 Jun 2007 21:37:49 -0700
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!

zfs-discuss mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>