Offline Disk Import for Google Cloud Storage - ship your HDDs to Google(developers.google.com)
developers.google.com
Offline Disk Import for Google Cloud Storage - ship your HDDs to Google
https://developers.google.com/storage/docs/early-access
6 comments
For me to upload 3TB on my shoddy connection would take about 290 days or so. If I ever needed to put that much data in the cloud, you can bet I'd use something like this.
Never underestimate the bandwidth of a jumbo jet full of magnetic tape.
even worse latency/bandwidth payoffs:
1) a hundred car locomotive
2) a cargo ship
3) more fun, if you simply need loads of data at a particular place in the universe at a particular time, and that place and time happens to align with the movement of the Earth, you can just load up a warehouse with the data and just wait. It's a special case that just happens to turn out to be highly optimal.
(it's similar to the theoretical time machine which is just a comfortable chair in a quiet room, it's guaranteed to take you into the future)
1) a hundred car locomotive
2) a cargo ship
3) more fun, if you simply need loads of data at a particular place in the universe at a particular time, and that place and time happens to align with the movement of the Earth, you can just load up a warehouse with the data and just wait. It's a special case that just happens to turn out to be highly optimal.
(it's similar to the theoretical time machine which is just a comfortable chair in a quiet room, it's guaranteed to take you into the future)
If your connection is so bad that you have to resort to shipping physical media to upload data efficiently I wonder how you're going to make effective use of the data once it's loaded into "the cloud". I understand that most consumer Internet connectivity (in the United States, at least) is asymmetric, but it seems like constrained upstream capacity would go hand-in-hand with constrained downstream capacity, too. I understand "seeding" the remote storage for backup applications, where you wouldn't be frequently accessing a large amount of the corpus, but I wonder how this would work with applications like moving your personal media library out to remote servers if you were one of these people with a connection that's so bad that you need to resort to moving physical substrate around to move bits.
Very cool. I would be interested to know how they get the data off the harddrive again. Would this work with a broken harddrive (by swapping the disk) or do they just plug it in somewhere and wait a couple of days while everything copies off. I would probably guess the latter but who knows?
They just plug it in and run an import process, very similar to how Amazon's AWS Import/Export process works:
http://aws.amazon.com/importexport/
If you need data recovered, you're going to have to run ddrescue yourself.
Now, what would be really cool? If they had multiple locations to do the import from (Provo, Austin, KC/MO anyone?), so you could get the data to them quicker when they have a sizable backhaul nearby.
http://aws.amazon.com/importexport/
If you need data recovered, you're going to have to run ddrescue yourself.
Now, what would be really cool? If they had multiple locations to do the import from (Provo, Austin, KC/MO anyone?), so you could get the data to them quicker when they have a sizable backhaul nearby.
I guess the best thing to do is make a copy of your data on a new HD and send that one. If something is wrong with it and they can't read the data: try again.
Their pricing for the hard drive is reasonable but their storage pricing is higher than what I pay with Crashplan ;) I haven't taken advantage of Crashplan's initial drive seeding because my upload speed is fast enough.
2TB uploaded so far to Crashplan in around 3 months.