14 Reasons To Do Reverse Cloud Backup

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, lessening 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 do not 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 do not 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.
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 vendors 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 vendors have 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 one email. In recovering that single email, it requires a restore of the entire email data base to the night prior. The cost to the enterprise, and to all of the other users losing their most recent emails, is unacceptable.
Cloud vendor tech support is unavailable. This makes calling for help and restoring more trouble than it is 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 is not working as expected.
Cloud vendors charges to do restores ($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 do not consider an employee mistake the emergency it may be for you. Asking for a restore can incur significant costs.
Cloud vendors have inadequate versions, or abilities, 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 vendors get raided by Feds (servers taken), or served by a 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 gets 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 an eight character check, but does not 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 number is changed, or there is paperwork confusion, resulting in the 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.
Forgotten password, or inexplicably locked out of account, after multiple retry attempts. We have 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, and 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. Let’s 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 the 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, or 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.

Our Solution:

At Highly Reliable Systems, we provide a solution to all of these significant obstacles of cloud backup, with our new series: the RNAS. The RNAS series is a rapid recovery platform, which utilizes our High-Sync software. Our system is capable of performing reverse cloud backups, from twenty-seven different cloud providers, which consolidates important information in one location. Click here, to view our High-Sync functionality.