Best practice for high availability ZFS pool

[Bob Friesenhahn]

On Tue, 17 May 2016, Ben RUBSON wrote:

>> On 17 may 2016 at 15:24, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
>>
>> There is at least one case of zfs send propagating a problem into the receiving pool. I don't know if it broke the pool.  Corrupt data may be sent from one pool to another if it passes checksums.
>
> Do you have any link to this problem ? Would be interesting to know if it was possible to come-back to a previous snapshot / consistent pool.

I don't have a link but I recall that it had something to do with the 
ability to send file 'holes' in the stream.

> I think that making ZFS send/receive has a higher security level than mirroring to a second (or third) JBOD box.
> With mirroring you will still have only one ZFS pool.

This is a reasonable assumption.

> However, if send/receive makes the receiving pool the exact 1:1 copy 
> of the sending pool, then the thing which made the sending pool to 
> corrupt could reach (and corrupt) the receiving pool... I don't know 
> whether or not this could occur, and if ever it occurs, if we have 
> the chance to revert to a previous snapshot, at least on the 
> receiving side...

Zfs receive does not result in a 1:1 copy.  The underlying data 
organization can be completely different and compression or other 
options can be changed.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/