In-Depth

The Changing Face of Disaster Recovery in the Cloud Age

A stagnant and feature-poor market has grown into a rich and vibrant ecosystem filled with a variety of offerings to meet any need.

• By Trevor Pott
• 03/21/2018

I've been having something of a debate with myself as of late. Does systems administration ingrain a deep sense of paranoia and laziness into practitioners, or does it attract people who possess these traits? More important: How does this impact real-world systems administration responsibilities, such as configuring and managing data protection?

Systems administrators are trained -- either formally or through the school of hard knocks -- to prepare for the worst. We must plan for any eventuality. We must constantly think about data protection, disaster planning and the depths of human inability.

We are also lazy. If we're asked to do a job more than a handful of times we'll seek to automate it. Few things are more annoying to a sysadmin than repeating some mundane task that could be accomplished by a shell script.

Despite all of this -- and perhaps because all of this -- sysadmins as a group aren't very comfortable with the public cloud. The cloud certainly speaks to the lazy in us: Look at all the pretty automation! But something about having someone else control the infrastructure we run on grinds the paranoia in us the wrong way.

I've traditionally been one of the public cloud's biggest skeptics. Cost has always been part of this skepticism. Lock-in another very serious consideration. But under it all is the matter of trust. Who can I trust? Can I trust anyone? And if I can't trust anyone, how do I engineer a cloud solution so that I can withstand a cloud provider going sideways on me?

I don't have satisfactory answers to all of these questions. But what I do know is that the world is a different place today than it was 10 years ago. The Amazon Web Services (AWS) public cloud is more than an online empire; it marked the beginning of a revolution in how vendors of all sizes ply their wares.

The public cloud changed not only how software is sold to individuals and organizations, it changed the dynamics of hardware sales, of support contracts and especially of data protection. More important, AWS lit a fire under the services provider space. A stagnant and feature-poor market has grown into a rich and vibrant ecosystem filled with a variety of offerings to meet any need.

Somewhere in all of this, there's a path to daylight.

Data Protection Is More Important
Data protection in my world used to be simple. The cron server would run a script each night. This script would copy relevant files into the backup folder, pause the financials server and copy its database, release the financials server, and then zip the whole backup directory up. This would then be pushed to a tape, the tape would be verified, and a little old man would come by once a day to courier it off to some shelf in a building on the other side of the city.

Transmitting the data over the terrible ADSL connection that small businesses could afford in my city wasn't going to happen. Hard drives were too expensive to use as rotating media, and too fragile. So tapes it was.

All of which was great, until the time came to restore from those tapes. It may come as no surprise to those who have had to rely on tape backups before, but tapes aren't exactly the most reliable backup media. Our success rate was somewhere around 75 percent, which wasn't acceptable back then, let alone once all this newfangled cloud stuff came about.

Eventually, Internet connectivity got better. Backing up over the Internet became feasible. I dipped my toe into the cloud with backups. My zip ball got pushed into the cloud instead of onto tape. Restores were successful every single time. I slept better. I still do.

But backups are not disaster recovery, and one day, a river flooded. So did one of my datacenters.

It took me two weeks to return all workloads to full functionality. I was unimpressed. The customers were even less so. The boss was significantly less than impressed, and was unwilling to listen to any conversations about his being unwilling to buy adequate backup equipment.

Rock, meet hard place. That was six years ago. The world has changed since then.

Disaster Recovery to the Cloud
What if you didn't have to buy adequate backup equipment? What if you didn't pay any more for your disaster recovery capabilities than you do your raw backups? Or, at most, you pay a completely negligible amount more? What if, in the unlikely event that things go boom, you could simply turn your backups on as easily as turning on virtual machines, and only be charged for the time that those workloads are in use, serving their disaster recovery purpose?

This was fantasy six years ago. Oh, the large-and-in-charge could do it. The Fortune 2000, working in concert with a variety of startups and paying ridiculous amounts of money for the software to make it all go could do it. But not small business. We were left out in the cold.

Slowly, piece by each, this changed. At first, the public cloud vendors opened up, and an increasing number of solutions started to offer the ability to affordably do disaster recovery to the public cloud. It wasn't easy. Workload conversion was a bit of a crapshoot, networking was a problem and the lack of VM consoles made troubleshooting a nightmare.

Software evolved. Now you can take your VMware, Hyper-V, or even bare metal workloads and send them up to a public cloud, or virtually any services provider cloud of your choice. Lock-in is functionally gone. Conversion is no longer a problem. Networking got solved, and services providers figured out VM consoles are kind of important.

Today, you can back your data up to a services provider over the Internet for prices that small businesses can afford, and in the case of disaster, light your workloads up at the services provider. You can do so only for as long as you need, only pay the compute charges for the duration of the event, and fail back to your on-premises infrastructure (should you choose) when it's all over.

And you hardly need to know a thing about how data protection software works to make it go. I find my cloud skepticism increasingly hard to maintain. Not impossible, mind you, but increasingly difficult.

Caveats and Addendums
The flag to wave for cloud skeptics is, of course, cost control. Lighting up Infrastructure-as-a-Service (IaaS) workloads 24x7 gets costly in a right hurry. Ease of use also plays a factor: As backing up our workloads and data to the cloud gets easier, so, too, does the temptation to back up that which we don't absolutely need to backup, or to never delete anything. That laziness thing again.

What's also worth bearing in mind is that the instant you fail over to a cloud provider, those workloads then need to be backed up somewhere else. Cloud-to-cloud backups are increasingly easy, so it's not that this is difficult, but it needs to be kept in mind.

Personal experience has taught me that failing over to the cloud often becomes an "out of sight, out of mind" affair. During a disaster event, the systems administrator -- and everyone else -- is usually so focused on dealing with whatever the disaster is to bother thinking, "Oh, my disaster recovery copies of the workloads are now my primaries, maybe I should add some data protection to those."

This is where a good services provider comes in. Services providers can and do cultivate much closer relationships with their customers than the major public cloud providers. In my experience, there's real value in being able to pick up the phone, tell them one of your datacenters melted, and ask for help not only in making sure all the workloads come up, but in making sure that you didn't miss anything as part of your response to the event.

Over the past 10 years, those who have embraced the cloud have predominantly been developers. Freeing themselves from the shackles of systems administrators, they found happiness in the cloud. As the disaster recovery capabilities of cloud providers -- big and small -- become more capable, inexpensive and all-encompassing, slowly but surely even the most paranoid systems administrators are joining them.

None of this settles my personal debate over which came first, the paranoia or the job, but at least I can stop worrying about being left behind.