HAST + ZFS + NFS + CARP

[Borja Marcos]

> On 11 Aug 2016, at 11:10, Julien Cigar <julien at perdition.city> wrote:
> 
> As I said in a previous post I tested the zfs send/receive approach (with
> zrep) and it works (more or less) perfectly.. so I concur in all what you
> said, especially about off-site replicate and synchronous replication.
> 
> Out of curiosity I'm also testing a ZFS + iSCSI + CARP at the moment, 
> I'm in the early tests, haven't done any heavy writes yet, but ATM it 
> works as expected, I havent' managed to corrupt the zpool.

I must be too old school, but I don’t quite like the idea of using an essentially unreliable transport
(Ethernet) for low-level filesystem operations.

In case something went wrong, that approach could risk corrupting a pool. Although, frankly,
ZFS is extremely resilient. One of mine even survived a SAS HBA problem that caused some
silent corruption.

The advantage of ZFS send/receive of datasets is, however, that you can consider it
essentially atomic. A transport corruption should not cause trouble (apart from a failed
"zfs receive") and with snapshot retention you can even roll back. You can’t roll back
zpool replications :)

ZFS receive does a lot of sanity checks as well. As long as your zfs receive doesn’t involve a rollback
to the latest snapshot, it won’t destroy anything by mistake. Just make sure that your replica datasets
aren’t mounted and zfs receive won’t complain.


Cheers,




Borja.