I have been experimenting with a number of things in Linux as of late. Breaking out my mad scientist cap– did I ever put it away?– one such thing I started screwing with was software-based RAID arrays in Linux. I wanted to see if I could create a number of encrypted, compressed files, spread them all over the world, and mount them in an RAID array (there is no way to say that any simpler without taking away from it). I put together a little plan in my head and I was off.
I stuck a bunch of Ubuntu installations all over different geographical locations and connected them via OpenVPN and NFS (CIFS would also have worked although probably with a noticeable performance hit). Using dd I created a 1GB file on each of them. Using losetup and its built-in encryption I mounted them all as loopback devices on my local machine. Using mdadm I turned the loopback devices into a RAID array and stuck ext4 on it. Using fusecompress I mounted said ext4 volume to compress everything on the fly.
What possible use could this serve? Well, there is the reason I did it: it is jawesome sauce and I wanted to see if I could. Those reasons, of course, are not a purpose. I suppose, if one really wanted to hide their data, they could use this in a RAID0– or a RAID5/6, even– to spread the data around using a very small cluster size. Theoretically, no two "neighbouring" clusters on the filesystem would be at the same geographical location. This means that if one– or more– sites were compromised not only would the attacker have so little of the data as to be useless but due to the way encryption tends to work (it is nearly impossible to unencrypted anything without the "neighbouring" data) it would be extra useless to them.
Like so many of my experiments this was never meant to be a practical anything. Yeah, I got it working with little difficulty– the real problem was driving around and convincing my friends to let me use their houses and bandwidth– but I can think of a number of issue that would arise in real-world use. First off, the whole concept is predicated on the use of files mounted on network exports. Files on exports potentially far, far away from you. If a network link goes down– or hiccups– you would probably have a bit of an issue. Sure it is all in a RAID but your NFS– or CIFS– mounts are going to wait a bit before they decide to let you know they have gone down. I imagine this would manifest itself as a temporary “freeze” of the filesystem but I have not tested it. A second issue is if you are using a RAID0 for maximum security (as mentioned above) losing anything at all would kill the whole setup. Consider that if your backup is not as secure as your primary then what is the point? Thirdly, depending on which RAID level you choose, you may quickly realise that not all link bandwidth or latency is created equal. I did run into a common mdadm issue where it did not release the devices but did not put any effort into fixing it.
All-in-all I am pretty excited for no good reason; I suppose I just thought it was neat. I do not recommend relying on this unless you can solve the above problems. iSCSI was designed for such things so if you are hell-bent on implementing this idea I suggest you use that instead of the loopback devices. You might have to find a new way to encrypt everything (I bet TrueCrypt would work).
I did write a few short scripts to make my lifer easier but they have no error checking so I decided not to post them. If there is enough interest I could finish them (IE add the error checking) and post them.