Amazon EC2 & S3 disaster planning (what does your disaster recovery plan look like?)
radar.oreilly.com
radar.oreilly.com
Does it really? What if you load the data onto some physical medium and physically move it from wherever it's backed up into the failed data center? The latency of vans with disks or tapes may be high, but the throughput can still way exceed that of networks.
It's a laughable example anyway. Very few sites use anywhere near a petabyte of storage. I think he overshot a bit there. I also think he's generally right about S3.
I can only think of two scenarios where I would recommend S3:
1. You're spending such small amounts of money that buying your own storage servers is out of the question.
2. You don't have anyone qualified to run your storage servers.
If I could search YC I'd point back to an earlier discussion we had on S3. One of the points that came up was how do you know when your uploaded file is "safe", i.e. not when the upload has finished but when all N copies exist so you can go back to your user and say "fear not". A simple fetch of it is insufficient; S3 is selling itself on its redundancy so it needs to prove it. Anyone know of a way to do this?
"... how do you know when your uploaded file is 'safe'? ..."
don't know. might have to find this out.
I don't think most of its users could afford to move things in-house, assuming Amazon would even announce in advance that S3 was shutting down.