Date: Tue, 17 May 2016 16:46:53 +0200 From: Ben RUBSON <ben.rubson@gmail.com> To: freebsd-fs@freebsd.org Subject: Re: Best practice for high availability ZFS pool Message-ID: <40C35566-B7FB-4F59-BB41-D43BC0362C26@gmail.com> In-Reply-To: <alpine.GSO.2.20.1605170819220.7756@freddy.simplesystems.org> References: <5E69742D-D2E0-437F-B4A9-A71508C370F9@FreeBSD.org> <alpine.GSO.2.20.1605162034170.7756@freddy.simplesystems.org> <AB71607F-7048-404E-AFE3-D448823BB768@gmail.com> <alpine.GSO.2.20.1605170819220.7756@freddy.simplesystems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 17 may 2016 at 15:24, Bob Friesenhahn = <bfriesen@simple.dallas.tx.us> wrote: >=20 > On Tue, 17 May 2016, Ben RUBSON wrote: >>>=20 >>> Without completely isolated systems there is always the risk of = total failure. Even with zfs send there is the risk of total failure if = the sent data results in corruption on the receiving side. >>=20 >> In this case rollback one of the previous snapshots on the receiving = side ? >> Did you mean the sent data can totally brake the receiving pool = making it unusable / unable to import ? Did we already see this ? >=20 > 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 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. With send/receive, you have a second / different ZFS pool / data = "envelope", which could (I think) mitigate the "chance" of a broken / = dead pool. Mirror over 2 different JBOD boxes, and send/receive to a third one, is = I think a nice solution. 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... Ben=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40C35566-B7FB-4F59-BB41-D43BC0362C26>