slashdot.org/article.pl?sid=03/01/31/1436205&mode=flat&tid=12
Public Terminal Log in 57 Create a new account Related Links 58 Compare the best prices on: Consumer Electronics 59 deadfx 60 The Distributed Internet Backup System 61 More on Technology 62 Also by CmdrTaco This discussion has been archived. Change The Fine Print: The following comments are owned by whoever posted them. Bandwidth is still the most precious commodity in computing. Once we get fibre to every house, then distributed storage will make sense. Ideally you could make one big backup of the data by hand and then start to do incrementals (assuming the diffs were small enough for your bandwidth). Currently, couriers get paid too much money to simply enter a data center, swap out a tape, and take the tape to an offsite storage location. OK so you've got to get your base image uploaded -somehow- but after that, data changes very little on a daily basis and this level of data transfer to some secure backup repository won't be a problem at all with current bandwidth. You might try to counter this by saying, how often do you need to do a complete restore? Usually when you have to go to offsite backup to restore something it is because you had some sort of catastropic failure and need to completely restore your environment. RTO and RPO will always drive the need to actually spend money for DR. I rather spend the cash to test and ensure reasonable recovery in my home (just as, at work), than to take a chance by sharing with the world. If I loose my house do to fire/flood, rebuilding my LAN isn't really a priority at that point. But will have my tape backup sitting in my cubicle to restore from when I am ready to. BTW, if drives are so cheap, then mirroring the rootvg should make perfect sense. Instead of purchase, load, get client and fetch/install (configurations, installed apps, keys, etc). The solution could look a bit better if it was done like this: Those that want to participate in the scheme assign a certain amount of space on their machine for the DIBS system. A client-like applet runs on the machine of the participating user. After the user tells the applet to allow 2GB to be used in this system - the applet registers that space with the DIBS MBDB. When you register the space that you have available to the MBDB - the MBDB allocates an amount of space equal to that which you have reserved for use by others. You decide that you want 500MB of space to store some files. MBDB checks your account and verifies that you have "space credit". The MBDB only provides you with half the amount of space that you have available because the system has to ensurethat your files stripe more than one machine. You could split 1MB of data into 128 chunks of 4KB, now you do a redundant coding of those into 256 chunks of 4KB. Now you have 256 chunks of each 4192 bytes that you store on 256 different computers. You need to store information about the location which could take up 4KB locally. Of course a problem remains, where do you keep the metadata needed to find your data? The answer is to store them by similar means and thus building up a tree of nodes. You of course still need to store the root of this tree in a safe location. But the root is simply encrypted and stored in a lot of locations each containing the full data. This piece of data needs an identifier which could be computed as a hash function of your username and password. If you allocate 2GB for the DIBS - you get 1GB in return That is basically the idea, though I think it is a litle too optimistic. And while we are at it, please mod parent interesting, I cannot do now that I have answered him. People want it distributed (outside of LAN range) to combat the threat of natural disasters, fires, or any other event that can wipe out a building. In certain industries, they expect you to write a disaster recovery plan with just such things in it. But you're right, this is cheaper for some data than RAID. A few 100KByte/day if you use an efficient document format and dont receive movies as attachments. By important I mean stuff you would be missing the day your house burns down. Only backup across the net stuff that isn't on the recovery CD. One option with the collection of CD-RW's would be if you keep them with whomever provides your storage online, the CD-RW's could be put online to download across a broadband connection. This would be faster than overnight delivery, but not as fast as a courier across town. The distributed backup plan seems to have different specific advantages for two specific groups of home users, but has the same overall beneficial results. For the average Joe with only one computer running that ancient copy of Windows98 on a P133, the massive ammount of data-cruft is bound to be the weakest point of upgrading or even backing up. I've found that most families only have that one computer, and only have the option of backing up onto floppies. Usually their data can fit on one or two CDR/CDRW discs, but their system is also usually too old to get a cd burner to work reliably. In addition, they're just too stingy with the purse-strings to shell out the $100 or so for a decent, middle-of-the-pack drive, anyway. Sending critical data over the internet might be a better option, if a bit more time-consuming (no broadband, only 56k modem). Frequent backups like this has the potential to be substantially more reliable, not to mention scores easier, than a pile of floppies as you're ideally only sending the new data. I can't tell you how often I wished for something like this when working on a friend's/family's system across town and away from my own network. And that brings me to my second group that can really take advantage of something like this: Power-users with a small network running at home. My network has a file-server that stores *EVERYTHING* on it for backup purposes. It's got ISO's of all my software and OS's, drivers, stand-alone programs, documents, and media files. Backing up that data is a Travan-5 drive (10GB/tape, native) and 9 cartridges. At about 3 hours per tape, backing up to 9 TR-5 tapes takes days, not hours. There's two additional tapes for backup of the server's OS and configuration and it easily fits on one tape. But if there are any significant changes to the system, I rotate the tape so that there's always a working copy in case things go terribly wrong. They're not exactly cheap, but it's probably the least expensive backup I can find right now without going to removable HDs (I'm avoiding that solution as HDs are, in my opinion, less reliable and durable than tapes). Using this distributed backup plan would allow me to recover my server's OS from the single tape and retrieve the data from the network when I have time. The 2 desktops and 2 laptops can be fully recovered with an OS or system recovery cd and the rest is available on the server. In fact, I usually have one of each type of computer down at any given time for something-or-other. Having the data on the server allows me to blow away any of the systems I run at any time and completely recover the system to a working state in just over an hour. Actually, I had been setting up a distributed backup plan for my own server with some of my friends so we'd all have each others' server's backup. More accurately, the plan was to merge the changes between all the servers' data and share it between all of us in a manner similar to CVS. There's only 3 of us, but we're located all over the state and we all have broadband. Really, though, all we'd be transmitting is the changes we've made which would limit the total bandwidth used. We'd probably only set it up for once per week in automatic mode to further decrease the load with an option to manually update. In the event of a complete failure of one of the systems, there should be a copy from one of the other two servers that's no older than 1 week. As the storage requirements grow, each server can be updated with additional storage in sequence so that it recovers in a manner similar to how a RAID5 array rebuilds the data on a replaced drive. Unfortunately, neither of my two friends in question have the resources to afford the hardware and set up their own...
|
http://csua.com/feed/