First: No, the purpose of this post isn't to ask for volunteers.
Second: No, I wouldn't expect (or necessarily want) the average Bittorrent user to participate in the swarm.
Third: Data volume currently sists at 3.5GB uncompressed.
I've been thinking about a recurring issue...Namely that none of RCo's remote backup targets are very good. My home system has a problem remaining alive for any extended duration, and I don't have any other good prospective places to I can trust to send the data. (No offense to anyone who's offered, but it's hard for me to totally trust someone I've never met in person.*)
I may have hit on a novel solution, but I want to run it past a bunch of people (namely, you), before I do something this crazy.
Step 1: Take backup on server
Step 2: Compress backup to tarball.
Step 3: Encrypt tarball using GPG and a long, long public key.
Step 4: Build a torrent.
Step 5: Add torrent to RSS feed.
Step 6: Anyone who wants to help can point their torrent client at the RSS feed. Data's encrypted, so I don't have to worry. With enough seeder boxes out there, there can be several full copies out there.
Bonus: Server data migration happens much, much faster. :)
Steps 2 and 3 can be munched a bit by nesting the encryption in the
tarball, using separate keys for each subdirectory, or even splitting
a .tar.lzma, separately encrypting each chunk with a unique key,
tarring that and using another key for encrypting that final tarball.
And, yes, generating that many keys is problematic; It took me about five minutes to generate a 4kbit key yesterday as a test, as my home system didn't have enough entropy. That's solvable with either bulk data from random.org or using a hardware RNG. There's also key transport, but that's somewhat alleviated if I generate the key pairs at home, and then copy only the public keys to the server.
* Yes, this is me we're talking about, and I realize the irony.