George Mitchell posted on Fri, 14 Mar 2014 06:46:19 -0700 as excerpted: > Actually, an interesting concept would be to have the initial two drive > RAID 1 mirrored by 2 additional drives in 4-way configuration on a > second machine at a remote location on a private high speed network with > both machines up 24/7. In that case, if such a configuration would > work, either machine could be obliterated and the data would survive > fully intact in full duplex mode. It would just need to be remounted > from the backup system and away it goes. Just thinking of interesting > possibilities with n-way mirroring. Oh how I would love to have n-way > mirroring to play with! In terms of raid1, mdraid already supports such a concept with its "write mostly" component device designation. A component device designated "write mostly" is never read from unless it becomes the only device available, so it's perfect for such an "over-the-net real-time-online- backup" solution. The other half of the solution are the various block-device-over-network drivers such as BLK_DEV_NBD (see Documentation/blockdev/nbd.txt) for the client side, the server-side of which is in userspace. That lets you have what appears to be a block-device routed over the inet to that remote location. Of course mdraid is lacking btrfs' data integrity features, etc, with its raid1 implementation entirely lacking any data integrity or real-time cross-checking at all, but unlike btrfs' N-way-mirroring it gets points for actually being available right now, so as they say, YMMV. Of course the other notable issue with your idea is that while it DOES address the real-time remote redundancy issue, that doesn't (by itself) deal with fat-fingering or similar issues where real-time actually means the same problem's duplicated to the backup as well. But btrfs snapshots address the fat-fingering issue and can be done on the partially-remote filesystem solution as well, and local or remote- local solutions (like periodic btrfs send to a separate local filesystem at both ends) can deal with the filesystem damage possibilities. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
