Karl Denninger (karl) writes:
>
> I think I'm going to play with this and see what I think of it. One
> thing that is very attractive to this design is to have the receiving
> side be a mirror, then to rotate to the vault copy run a scrub (to
> insure that both members are consistent at a checksum level), break the
> mirror and put one in the vault, replacing it with the drive coming FROM
> the vault, then do a zpool replace and allow it to resilver into the
> other drive. You now have the two in consistent state again locally if
> the pool pukes and one in the vault in the event of a fire or other
> "entire facility is toast" event.
That's one solution.
> The only risk that makes me uncomfortable doing this is that the pool is
> always active when the system is running. With UFS backup disks it's
> not -- except when being actually written to they're unmounted, and this
> materially decreases the risk of an insane adapter scribbling the
> drives, since there is no I/O at all going to them unless mounted.
> While the backup pool would be nominally idle it is probably
> more-exposed to a potential scribble than the UFS-mounted packs would be.
Could "zpool export" in between syncs on the target, assuming that's not
your root pool :)
Cheers,
Phil
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
