Cloud backups: Where's my get out of jail card? It is time for your reminder to review, test and otherwise care about backups. Today's twist is probing the cloud to see if we need to worry about cloudy backup ourselves. If so, how exactly do we do it? The more I delve into the state of cloud services the more I am disturbed by what I see. Every vendor has a completely …
I have just completed a review of an (unnamed) UK government departments proposal to shift some of their service out to a 'cloudish' provider. The statements about availability, recovery time and recovery point objectives made by the vendor were balls. Bringing the vendor up to the standard apparently (I use this term reservedly - much of the customers requirements seem to come more from a heavy session in a pub near Whitehall than needs) almost tripled the cost of the service.
The problem is that the bean counters just don't understand the business and also have little idea about valuing lost time and lost data (provided it does not embarrass too much a junior minister).
All these articles critical about cloud storage being not as safe as you might like keep ignoring the biggest issue entirely.
Uncle Sam could declare martial law any day, and all your cloud data is hosed or at least inaccessible for an indefinite period of time, unless your data actually happens to reside outside of the U.S., which isn't very likely.
On another note, the NSA should start offering cloud storage. They are competent, have unlimited capacity, and could get all our data voluntarily, rather than having to steal it.
Someone needs to say this, as the small print of all cloud services I've seen, no one guarantees backups.
We use Google Apps a lot and have been saved by a small utility called Syncdocs which backs up everything on Google to our local servers every night. Google loses data now and then, although they won't admit it.
For the braver souls there is "Backupify" which backs up all your Google Apps to Amazon.
I'm waiting for "Backupsky" which backs up all your Amazon data to Microsoft, then "Goobackify" ..........
On a personal level, I use Insync on Win7 and Linux for local to Google Drive mirroring. Single payment of $10 per google account gets you mirrored on as many computers as you like. (I am not affiliated with them in any way.)
The whole point of outsourcing is that someone else can do it better and/or cheaper than you can.
If that isn't really the case, then there's no point in putting your trust in someone else. You could go back to being responsible for your own problems and ignore the cloud hype entirely.
In this article you have managed to confirm my conclusions and sanity check my proposed solution (Unitrends, fyi they have just opened a UK office).. Its a shame this was not published 4 weeks ago, might have saved me days of justifying the reasons and grovelling at the feet of the bean counters.
Folks - to throw in another 2 cents worth (or twopence if you prefer) one thing people looking at service providers might want to think about is the relationship between you, the service provider and the back-end infrastructure provider. In many cases the service provider does not own their own hardware but uses another organisation - as has been pointed out this may be Amazon or one of the other major players. In any event the issue is that often you will not have any contractual relationship with the company on which your data actually resides. Most contracts have a nasty set of clauses that boil down to a situation where if your service provider does not pay their bills to the back end infrastructure provider then the service is firstly switched off and then 30-60 days later the infrastructure provider have the right to delete the data. In this case even proving that you have your data on their infrastructure is a problem (assuming of course you know who to contact and are actually aware that there is even an issue in the first place) and getting it back is a nightmare scenario. I accept than finance people tend not to get the technical stuff but they sure as heck understand contracts and who owns what so this might ring a few alarm bells before you are forced off down the cloud route.
Personally I generally advise against encrypted backup, for the sole reason that most backup administrators know nothing about key management.
I used to design backup for a large TLA bank, we opted for a policy of "No tapes offsite, data only moves through networks" option for backup - cloud, if you like, but our own private cloud.
There is nothing worse than knowing you have the backups, but that you can't access them because your keys are backed up in the encrypted backup or some such problem.
Recently I needed to find a better way of storing about 40,000 individual files (with the number going upwards continuously). Looked at various "cloud" services but reached two conclusions :
1. I dont trust them or their government, so all files are encrypted *by default*
2. I dont trust their reliability record so I'm storing these files in 2 separate machines geographically located that my employer controls, plus a daily offsite backup.
3. If I every use a cloud service it will be in as an additional backup layer only.
You might as well call the Cloud the Wild West because it's largely cowboys today.
I remember the very old saying "There are only two types of computer user. Those who have lost data in a crash and those who are going to lose data in a crash". But with 'cloud' we seem to be saying "There is only ONE type of cloud user. Those for whom their cloud provider will lose data." It seems to me that if data is stored in the cloud then some of it WILL be lost and that does not even take into account those cloud providers who simply scrap the cloud offering that you or I subscribe to (think BT and their scrapped Vault service).
I started my IT career when the IBM's of the world were offering up data centers for service, i.e.: companies just didn't have internal computing capability. Their centers provided service; sometimes good, sometimes terrible. I cannot count how many times we lost information for various, unaccountable (acts of God), reasons.
We made the decision to bring computing services in-house as soon as we could justify the cost. That reasoning still holds true 40+ years later. If you want security, control and access to YOUR data, do it yourself and do it well. The computer services of today are no better, and may even be worse, than those provided by data centers of the 1970's+. And the excuses for poor service, security breaches, unaccountable loses are still "Acts of God"...
What actually constituted a "data center" in the 1970s? Most of what passed for "data centers" back then were IBM mainframe (System 360) time share services. Interactive computing was being offered by DEC, but you generally bought or leased DEC mini-computers and kept them on your own premises. Everything having to do with the actual computation and storage of data was generally installed in "glass rooms" that were temperature and humidity controlled but I don't think they fit the modern definition of a data center. Data storage on rotating magnetic disks or removable "disk packs" was only available for small amounts of data because it was limited in capacity and very expensive. Lots of data was stored on magnetic tapes, which were mounted and read/written when the data was needed. Human beings had to mount and dismount tapes from the tape drives. It all seems quaint by today's standards and it was probably glitchy and unreliable at times too.
>The price for this service is a minimum of $10K (Ten Thousand US Dollars).
> The work involved actually costs us much more than that, but we pay for a portion of the service.
That's either some really bad design or bullshit of the highest order.
Considering it's SalesForce, I don't know which one is more likely.
Let's take out the c word (cloud) and think about what is really happening here. Offsite backups to an external vendor. I can envisage similar risks and potential impact with backup to tape and having tapes picked up in a lorry for secure storage in a remote location.. Does the company storing tapes provide a 100% SLA against data integrity or confidentiality failures? Even if they do an SLA is just a statement that says " if we do bad you get something back" but money can't always replace data. Also, if a 3rd party (for example a government) wants that data what's the difference? (Yes, both tape and online can be encrypted in such a way that you are the only person with the private key). What happens if they have a fire?
My point is that each and every company is responsible for their own data and must carry out their own risk assessment. Allowing a 3rd party to look after you data in a remote facility isn't new, companies have been storing boxes of documents at the bottom of Iron mines for years now and their charging mechanisms have always made restoration more expensive and time consuming than ingestion. What's changing is that people are coming up with different ways of moving that data around
I totally agree with points regarding vendor lock in and the financial stability of the supplier and their hosting centre, that's just means that you need to choose your vendor carefully. I've got a leaky garage at the bottom of my garden that I'd be happy to charge a couple of quid for keeping your tapes in :)
I do work for an online and offline backup vendor and I'm sad enough to have thought about minimising risk and it comes down to money. How safe do you want to be is a direct function of how much you want to spend.
Do full local backups. Keep a copy of the key tapes locally ( for fast restore) and remotely (to protect against the local disaster). Also use an online backup service for real time backup and backup of hard to reach data (contents of laptops of remote and roaming workers).
All the different mechanisms play a part. There is no "best" just most appropriate for a specific task.
I think there are some good cloud backup service providers out there, yes data loss is an issue and thats why a lot of IT firms create their own private clouds, but even they are begining to look into Azure and Adobe to host some of the 'lower risk' apps. I believe you need to a co-existence of both public and private clouds, that way you can choose what data goes where, and accept the risks of the public cloud.
Theres an interesting site for new comers to cloud based services here: www.backuptoclouduk.co.uk if anyone wants get a good grounding on what this cloud business is all about
As a peddler of 'cloud backup solutions' I can fully understand the authors concerns. Unsurprisingly, we use Amazon Web Services as our backend because it'd be sheer madness to make our own infrastructure for only one or two products. No one is going to invest in doing that themselves and if they did, it wouldn't be as good as Amazon. Data loss is a very unlikely scenario. You're much more likely to suffer an Internet outage than Amazon going down at the moment you want to restore your backup.
The main problems we face are: a) people don't trust third parties with their private data (encrypted or not) b) most countries won't let you store certain types of data on foreign servers and Amazon's DCs are all over the world. c) our service is tailored for databases and some people want a unified solution for all their stuff.
I don't want to come off as insincere since I'm somewhat invested in this industry, but cloud backup isn't that bad. It's much better than shipping tapes around..
We have been running a backup service for 17 years. We have always stored the data in our own data centre for accessability and the issues discussed above. We charge a bit more because of this, but our clients know where their data is and our T's and C's have always said that it is their property (but not the actual media).
Whilst implementing a backup strategy is a good first step, we shouldn't forget the real reason we are doing it, namely business continuity.
When you have full control, you can run the same application in several datacentres or 'service providers' and hence you can back data up from one site and run it at another. With cloud you really need to be looking to achieve a similar level of application service redundancy, particularly as we have seen individual cloud service providers bite the dust (eg. MegaUpload and in the UK, 2e2.
So the acid test is to export data from say Saleforce.com and import it into another provider's service and see if you can continue to use it and then do the whole thing in reverse... If you still have a fully operational application then congratulations as you have achieved a major step forward in business continuity.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
