A Cloud-to-Cloud Backup Intro – What to Look For

When it comes to protecting your critical data, two clouds are better than one! In today’s post we’ll discuss cloud-to-cloud backup and the key features and policies to look for when using one SaaS product to back up another SaaS app.

Why Back Up the Cloud?

Software can’t distinguish between intentional commands and “oops, I didn’t mean to do that” so no amount of hardware redundancy—protection from server crashes or hard drive failures—can save you from yourself. Likewise, if a hacker steals your password and tells Google to delete data, Google will do as its told. Same goes for a third-party app that thinks you want it to overwrite your database with garbage information.

Best (or worst) of all, SaaS vendors like Google usually have respectable privacy policies that really do permanently delete data, so if you accidentally purge it, there’s no getting your information back.

Why Back Up the Cloud with Another Cloud?

Here’s the basic math with all backup systems—cloud, on-premise, or otherwise—the odds of both the main system and the backup losing data or being unavailable at the same time should be practically zero. For example, Google Apps has a service level agreement that promises 99.9% uptime, or one chance in a thousand of the system being unavailable at any moment.

Using a cloud to back up another cloud is perfectly safe, and has all the usual cloud benefits—hardware redundancy, access from anywhere on the web, and ease of maintenance. It’s the best of both worlds.

Do You Need Archive or Backup? (There’s a Difference)

Services like Google Vault, which used to be called Postini, are not backups, they are archives. The difference is important. Vault is designed to ensure that an audit record of your data is always available, so if you’re ever served with an e-discovery request, the complete history of your SaaS data—including who created it, who altered what and who deleted it when, is easily exportable. Archiving services are the cops from Law & Order who tell you who murdered your data. Important, but poor comfort in the aftermath of loss.

You *can* use an archive as a cloud-to-cloud backup system, but data recovery will be slow and complicated. You *can* use backup systems to construct a crude audit trail, but putting together an activity timeline will be slow and complicated. Backup and archive are different, complementary features. Don’t substitute—or confuse—one for the other.

It All Starts with an SLA

A backup service, or any SaaS app, is only as good as its service level agreement. First off, your cloud-to-cloud backup solution must have an SLA.

For example, sometimes a service needs to be taken down for regular maintenance. The SLA should guarantee you get at least 48 hours notice of these outages, and that the downtime will be less than 10 hours per month. Above all, don’t trust an SLA that caps your compensation limits below one-third of your service cost.

What are the Access Controls?

Data should be safer in your cloud-to-cloud backup than in the SaaS app you’re protecting. You should be able to control who has access to the backup system, and who can configure it.

Specifically, your backup app should have a separate administrator login than your SaaS app. First, if someone steals access to your SaaS app, they shouldn’t get access to your backups, too. Second, if the login service from your main app—like Google Oauth—goes down, you shouldn’t lose access to your backup data.

Interested in learning more? Stay tuned for part two in our cloud-to-cloud backup intro series or watch this video on why backing up SaaS applications is critical.

Why Backup Your Google Apps and SaaS Data from Backupify on Vimeo.