Highly Reliable Systems: Removable Disk Backup & Recovery


14 Reasons To Do Reverse Cloud Backup

By Darren McBride
cloudadopt

Reverse Cloud Backup captures corporate data stored in the cloud

Software as a Service (SaaS) applications have  become “cloud backup applications”, and are increasingly popular.  According to a survey of enterprise customers by Aberdeen Group, around 1/2 of firms are using the cloud for Customer Relationship Management (CRM) software and email (with Exchange making up 19%).  The high adoption rate reflects software manufacturer’s focus on recurring monthly revenue models versus the older sales models where software was purchased with yearly support or maintenance fees.  By hosting their applications, software vendors such as Microsoft CRM and Salesforce.com create higher profit margins and create tighter linkage to the end user.  This model will eventually diminish, and disintermediate the importance of trusted consultants and IT resellers which account for approximately 30% of the traditional cost of IT.

Besides cutting out the middle man, cloud apps put cloud providers firmly in control of customer data.  Yet despite substantial investments in redundancy by cloud vendors, the desire by customers to have a copy of their data remains high.  Vendors such as Amazon, Microsoft, and Google invest millions in redundant connections, data, and backups to convince clients that the utility computing model provides an all-in-one solution.  Yet customers remain skittish, trusting data solely to their cloud vendor.  Let’s look at some of the reasons that clients want local copies, despite “best in class” data center investments and data protection promises:

  • —User error.  Employees accidentally delete or modify cloud data all the time.
    The number one reason for data loss is user error.  These mistakes create a vulnerability that cannot be protected without regular versioning.  Local Windows servers easily provided this protection using VSS (Volume Snap Shot) services, but cloud apps don’t provide this functionality.
  • —User 1 overwrites user 2’s data because cloud apps are “stateless” and are more vulnerable to the “last write wins” problem than local databases with record locking functionality.
    Internet applications don’t have the granularity or control of multi-user access that are available with local servers.  This can lead to users overwriting each other and the problem gets worse as  more users access the same data.
error

Users delete or overwrite each others data.

  • Cloud vendor can go down (or worse) go belly up.
    While not a significant issue with the bigger players (Amazon, Google, Microsoft) there are many examples of cloud providers running into financial problems.  This can happen without warning and can leave customers data at risk.
  • —Cloud vendor can have inadequate backup or replication.
    Vertical market applications may be hosted at a single data center.  The backup policies of these smaller players should be looked at closely by the customer.
  • —Cloud vendor has no granular restore.
    “Granular restore” refers to the ability to restore a single record or a piece of data without having to roll back an entire database to a day or two earlier. An example of this is a company with 200 email users where the CEO accidentally deletes 1 email.  In recovering that email requires restore the entire email data base to a last night, the cost to the enterprise of all other users losing their last emails is unacceptable.
  • —Cloud vendor tech support is unavailable.  This makes calling for help and restoring more trouble than it’s worth.
    Have you tried to Google a phone number for Google?  Big cloud companies create a business model that eliminates answering stupid questions.  Unfortunately, that also eliminates your important question when the cloud application isn’t working as expected.
  • —Cloud vendor charges to restore ($10,000 for restoring data from salesforce.com)
    As reported by backupcentral.com, protecting your data is intended to allow your cloud vendor to recover from a data center failure.  They don’t consider an employee mistake the emergency it may be for you.  Asking for a restore can incur significant costs.
  • —Cloud vendor has inadequate versions or ability to save Archive data long term.  Many clients need 7-27 year retention.
    HIPAA, Sarbanes Oxley, Gramm–Leach–Bliley, and other laws may dictate that you retain data for many years.  While your cloud vendor may be happy to retain this data based on monthly fees per GB/Month, it may make sense to move old data to cold storage to eliminate high monthly data fees.
  • —Cloud vendor gets raided by Feds (servers taken) or served by court case demanding data
    On January 19, 2012 following a U.S. indictment accusing MegaUpload of harboring millions of copyrighted files, servers containing 150 million users data were seized.  What if the actions of one user on a particular cloud vendor impacted the up-time of millions of other users?  There are stories of MegaUpload customers trying desperately to get data back that was contained on servers seized by the government.
  • —Hackers. Even if one employee’s credentials get hacked, it could allow access to all cloud data.
    You have 30 employees.  One of them uses the password “password” on a vital service that does 8 character checking but doesn’t bother to check dictionary  hacks.  Your company data is now owned by a 15 year old hacker in Russia who used the most simple dictionary grinder code available.  Congratulations.
  • —Customer forgets to pay monthly bill, credit card# is changed, or there is paperwork confusion, resulting in cloud vendor shutting the account down.
    The story is a common one.  A credit card charge looks unfamiliar.  No one remembers making the charge.  A single call to the credit card company voids one credit card number and a new one is issued.  An unfortunate side effect is the monthly charge of the obscure cloud vendor that is suddenly not being paid.  Emails get diverted to spam filters and suddenly a vital service is shut down.  Ooops.
  • —Forgot password or inexplicably locked out of account after multiple retry attempts.
    We’ve all had it happen.  One night we have a bit too much on our minds and forget a password.  We struggle to log-in to an application we use every day.  We fail to log into  the account we use all the time.  After multiple log-in attempts the entire account is locked out.  Perhaps we are the administrator so the entire cloud infrastructure becomes unavailable until we call tech support.  The feeling of not having a backup at this moment is awful.
  • —Cloud vendor refuses to provide methodology for customer to extract their data and go elsewhere in the event of poor service.
    Lets face it: One of the great things about hosting an application is the complete control it gives over the customer.  In fact, it gives so much control that customer support can slip a bit.  Without a local copy of the data, the client is at the mercy of the SaaS vendor.
  • —Internet connectivity problem on either side (these should be temporary but…)
    Whether the Internet connection is down on the cloud side our your side the result is the same.  A mission critical application is suddenly unavailable.  This situation is uncomfortable but even more so when you realize you have no option but to wait.  Knowing the data is available locally provides incredible peace of mind.

Summary:  A whole host of problems can occur when trusting cloud vendors with valuable corporate data.  While cloud computing is an inevitable part of corporate life and will likely gain traction in years to come, IT professionals should put reverse cloud backup systems in place to provide protection against common problems.  While proprietary data formats remain a significant obstacle to meaningful reverse cloud backup, the ability to retain local control is clearly very important.  Use whatever methods are available to give you compliance and leverage with cloud vendors as  you move into the future.

What do you think?

Your email address will not be published. Required fields are marked *