Slashdot Mirror
If Your Cloud Vendor Goes Out of Business, Are You Ready?
storagedude writes: With Amazon Web Services losing an estimated $2 billion a year, it's not inconceivable that the cloud industry could go the way of storage service providers (remember them?). So any plan for cloud services must include a way to retrieve your data quickly in case your cloud service provider goes belly up without much notice (think Nirvanix). In an article at Enterprise Storage Forum, Henry Newman notes that recovering your data from the cloud quickly is a lot harder than you might think. Even if you have a dedicated OC-192 channel, it would take 11 days to move a petabyte of data – and that's with no contention or other latency. One possible solution: a failover agreement with a second cloud provider – and make sure it's legally binding.
This is the same problem we've always had, whether its someone's website on a shared host or a colo server. You need to back it all up and doing a naive dump of the entire thing will take too long and cost too much in bandwidth, so you take a dump of the entire thing once (preferably when you have the thing you're deploying locally) and then take incremental backups from there.
The big question is what's the best backup tools to do this, and do they work on cloud systems that don't look like real servers? eg. I recall rsoft that did very good incrementals based on disk blocks changing so the backups were also continuous. Not sure if that'd fly on AWS.
i suspect they'd get *everybody's* data, not just theirs.
Legally binding?
...which you should have backed up somewhere obviously, not only on a single cloud storage location
I thought the goal was to get your data back*, not to start a lawsuit.
*
I hate hardware and for all intents and purposes it can go shove itself up its own ass. As a result I very much love the cloud, no matter how much of a buzzword it is. Let someone else worry about the tedious busywork it is to get one piece of hardware to talk to another. Oh what's that? A disk died? I don't give a damn because I don't have to drive 30 minutes each direction just to change it. Ha!
You missed the point of the article then.
What if your cloud service provider goes down? How you going to get all your data if you get only 1 day, or a week notice? How about if you get no notice, the shit just stops working? The company goes poof! So does all your data.
And you think that won't happen? Please, it is going to happen, sooner or later. Why do you think it's named The Cloud? Because clouds evaporate and disappear.
Be seeing you...
Cloud offers a lot of real advantages over doing it all yourself.
1. Having resources when you need it. Lets say you have some seasonal tasks that needs extra horse power (Quarterly Reports, Christmas Rush, Back To School, Exam Time...) so you can request short term extra power to keep up. Without having all this extra equipment running nearly idle for 3/4 of the year.
2. Hardware upgrade, maintenance, backups... Keeping your hardware up to date is expensive, if you are keeping your old servers you will try to keep them for 6-8 years normally as to get the most out of them. However that means your servers are getting behind the times and are at risk of breaking. As well having to pay for redundant backup servers. Managing good data backup and storage policies. While might be easy for a couple of servers for larger demand it could become a huge waste of your time. The cloud company should be doing this maintenance. They get the advantage of dealing with a larger set.
But I don't like cloud for the sake of cloud. Adobe Cloud, Office 365 and most of your software that you really just want on your PC and not pay a monthly fee for. Sure cloud backup such as Google Drive but your device has adequate power to run these apps without a huge server farm in the background.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I find that local backups are better than cloud backups. I have a 1TB external hard drive that's nearly filled up. This drive cost me around $100 a few years ago. To get 1TB of backup from Google, for example, I would need to pay $9.99 a month. So I can either pay $120 yearly for 1TB of storage space or I can buy a new hard drive every year with increasing disk space. (Currently, $120 will get me a 3TB external hard drive.) With two of the drives, I can have one located somewhere "off-site" in case something happens to the location of my primary hard drive (fire, theft, etc).
Don't get me wrong, cloud backups can be useful. I can have my phone auto-backup photos and videos to the cloud which is helpful in case something happens to my phone. It also means I don't need to worry about backing up my phone as often. Still, for the most part, I've found local backups to be easier to manage and less expensive than cloud backups.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
Do those actually accomplish anything when the entity who signed teh agreement just when bankrupt and disappeared? I cannot imagine there is anyway to enforce any agreement on an entity who is legally dead and without any remaining assets of any kind.
Troll is not a replacement for I disagree.
Even if a large cloud provider were to get out of the business they are going to handle things in a responsible way and move their datacenter, hardware and data to someone else. And that's almost certainly true for the smaller players as well. That hardware and data is worth money even if not as much as it cost to buy. The bondholders are going to want $.60 on the dollar rather than $.00 on dollar if they can. But even if we assume that weren't true there are still options. Many of the colo companies which remember sell 30% of their space to the telcos are already using their cross connects for cloud-to-cloud moves the same way they do now for carrier-to-carrier. So for example from Equinix you can go between AWS, Azure and Verizon (Tarramark).
Almost all the small cloud players are renting space and will move data to physical drive or DAS or SAN. If they are growing broke just find out where they host, buy their hardware storage and keep it in the same colo your data is at now as a colo deal.
This is the sort of thing your cloud agent can handle for your company for free. I get that Joe-IT manager isn't plugged in enough to the industry to know whose hosting what where and what interconnects they have but that doesn't mean the data isn't readily available. This article is mainly just ignorant of how the industry works.
Make sure you keep your resume up to date and on local storage. When your company's cloud vendor fails...print your resume and use it to get a job somewhere else.
There is no God, and Dirac is his prophet.
This should be part of any companies DR strategy. If they don't have the provider going down, the same way they assume a DC goes down, then they aren't doing their job.
We use DropBox, and we keep a local mirror sync'ed within our own servers. We use the service for the efficiency, but if they went belly up, we already have all our own data and would just be looking for a way to fill the efficiency gap.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
Citation please.
Mostly clouds are more expensive than doing it yourself, unless you fire your sysadmin(s) as part of the deal.
Korma: Good
Why would you want it to die? What was the upside of company's having to constantly worry about hardware budgeting when they wanted to do software projects?
while not a complete data center, we do have a few racks.
The mentality you have to have when dealing with the "cloud" is how can i utilize it to make things better. Not "lets just shove it all up there" just like having that one box in the back-office that is the only one that can do something, you have to treat the cloud as a point of failure. When you design IT systems, you to the best of your budget try to mitigate single points of failure. Your budget is what limits the bounds in which you can do that, and the impact to the business should justify the budget.
For dropbox what we did was setup a synology san unit with with Cloud Sync attached to a single admin account. We then implemented a business process for creation of dropbox folders for use with clients (we are a consulting firm). When a folder needs to be created, it is created on that account, and then shared out. This ensures that it gets a local copy of all dropbox folders used for clients. We then back the synology unit to our normal in-house back.
We didn't go to dropbox because we wanted to replace our san or our local file storage abilities (honestly having everyone sync over the net connection vs local lan would be horrid). But rather wanted the convenience of their service, and the ease of use for the end users. But having that be the only centralized place anything existed would cause a single point of failure and should not be acceptable. It's the difference between leveraging something and relying on something.
We also use AWS for outward facing web services, But we have our own IP Block with addresses reserved for fallback, anything we push to out is first pushed to a local production system for final QA then to AWS production. If AWS would disappear, we would just update DNS settings and be back on-line within a MAX of 24 hours. Now our local pipe and production system couldn't handle the same load that AWS would in the same manner but would be functional (stress test shows page loads going from ~.1 to 4-5 sec), but that is ok as the risk is low and the impact is only moderate so ultimately it's a risk we are willing to accept.
Too many places now days don't do proper risk analysis and mitigation, and very few companies have real DR strategies. DR doesn't have to be expensive or complex, but it must be planned for and maintained, else you will be bitten when the disaster happens.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
when Netflix stops using AWS. And Expedia. And NASA. And the CIA, fer cryin' out loud.
Sheesh.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
I think the best of both worlds is to have the live system in the cloud, but have on site backups of all those systems.
That way if/when the cloud dies, you can still have access to all your data.