Evaluating DR Criteria - Part 4

Part IV: Backup Versus Disaster Recovery

In Part 3 we addressed application categorization and its importance in assessing and determining optimal and economical RPO and RTO. I was originally going to address DR drills in Part 4 but after some consideration it's better to first discuss the dynamics of IT operations and how changes impact the DR plan, the DR configuration and product selection. Additionally, we’ll address the importance of understanding the difference between backup and DR, and whether you should have separate or converged functions for each in the modern world.

A Little History

Datacenters, especially Enterprise datacenters, are not static in their configurations. There are always new demands on the datacenter itself, individual applications and servers, and the often-resulting infrastructure updates. To put all this in context a little history is relevant.

I know I'm going to date myself with this discussion but here goes. Prior to virtualization becoming mainstream and the adoption of Cloud technology, datacenter changes were, by necessity, fewer and less frequent. If one goes back to the 90s, datacenters were very physical. Many changes or updates required new hardware or modifying hardware in existing infrastructure. The idea of a datacenter migration required forklifts and trucks. Similarly, DR strategies were driven by hardware requirements.

Disaster Recovery in this era was extremely expensive and labor intensive. It involved setting up identical hardware in a remote location, manually installing Operating Systems and applications on deployed servers. This era predated the fiber optics revolution in networking and the highest speeds back then were a small fraction of what we consider standard today. With the speeds too slow for full datacenter updates combined with exorbitant costs and reliability issues, updates from the production site to the DR were manual. Backups were taken, typically no more than once per day, and copied, usually, to tape, and the tapes physically transported to the DR site, (gasp!), and applied manually. Worse, server updates required hardware changes, more memory or storage for example. The same, duplicate hardware had to be purchased and manually installed at the DR site.

Towards the end of this era, virtualization and the budding network revolution helped this situation but didn’t substantively change how DR worked. The DR site and operations were still very hardware centered. Companies, such as SunGard, emerged with datacenters and services to mitigate these difficulties but were extremely costly.

Is it Time for Converged Backup and Disaster Recovery?

Relative to this history, the difference between backup and DR bears elaboration. You can see that backup had a very different function from DR. Backup was about replicating data and DR was about maintaining a duplicate, physical datacenter. The backup function was a prerequisite of the hardware centered DR function. It was typical for backups not to be applied frequently to the DR site but to simply be happy that the tapes were safely stored close by and the data protected from an event taking down Production. There was no DR without backup.

But recovery was possible with only a backup function albeit very slow. Many companies, weighing the costs versus benefits of true DR, elected not to incur the costs of a DR site, or did so in a small subset of Production. The longer recovery times were painful but acceptable. A good team might be able to bring up a new site, or the essentials of a new site in 3 to 6 weeks.

Things are very different in the modern world. No company today can tolerate being down for 3 weeks, much less 6 weeks or more while IT operations are resumed. Not having a DR implementation is a disaster waiting to happen (no pun intended).

Setting up DR today is far easier and less costly than what was previously state of the art. Dramatic improvements in virtualization scale, Public and Cloud technology and cost-effective high-speed networking allow IT staff to realize far superior DR strategies than before.

Importantly, with low cost (relatively speaking) high speed networking connectivity standard practice, there is no need to transport tapes or other backup media from Production to DR. And network costs can be offset by the elimination of the hardware required for tape operations. Ask anyone old enough to remember the hassle of ensuring that backup tapes were available for recovery and the hardware was maintained.

While this may seem obvious there are more subtle downstream implications of having cost-effective, high-speed networking. DR products no longer require backup for a DR site to function. DR products have sophisticated delta sync technology themselves with policy engines that keep DR sites updated on a frequent and reliable basis.

It's fair to say that backup, in a canonical form, has a few features not present in a singularly focused DR product, but that list is very small and easily overcome. Granted the user interface is very different and agent based, but the important delta of backup functions is largely single file restore, retention policies for archival, and support for multiple locations.

It begs the question: can you use a converged backup and DR product and/or significantly scale down your backup functions, saving costs and operational needs?

Considering Datacenter Dynamics

An important, related issue involves datacenter dynamics. One thing that hasn't changed is that datacenters change and can change often. In fact, changes can now be instituted at a much faster rate. Adding storage to a server with a new filesystem is literally configured in a few minutes. Compute power can be added or scaled down. Directories and files added or deleted. Servers are added and deprecated. New technologies such as Containers and Kubernetes can fall outside the scope of established products.

In modern times, with DR sites in Cloud or highly virtualized on premises environments datacenter dynamics rarely involve hardware (thankfully). But changes are a burden nonetheless. Many products, with older legacy semantics, are hardwired for backup and/or DR operations. Changes on the origin, regardless of how small, can require manual configuration updates in the DR site and in the DR product. With this in mind, product selection criteria should include requirements for discovery of changes and automated updates on the target where possible. Not all changes can be detected and automatically updated on the DR site but selecting a product that has the framework will save you time and avoid unpleasant surprises when recovering to a DR site.

Final Thoughts

There are many leftover myths about backup and disaster recovery from yesteryears still impacting decisions today. With Cloud, high speed networking, and sophisticated software one should think about backup and DR in a new light. Consider a converged solution, a re-architecting of backup needs and most importantly, ensuring company health and longevity in the event of an extended outage.

From a product selection standpoint, it's highly advantageous having a platform that has converged backup and DR functions and automates discovering and handling as many datacenter changes and updates as possible.

As a peek into Part V, it's notable that in the previous era DR tests were EXCRUCIATING. We'll address considerations for DR drills in the next installment of Evaluating DR Criteria.