Disaster recovery vs. backup: Plan for and prioritize VM workloads
Before admins design a recovery plan, they must plan out which VM workloads need a disaster recovery environment and which need backups. Weigh these factors before making the call.
IT administrators must prioritize the criticality of VM workloads to plan recovery strategies that make sense. Before making a decision, consider the benefits and drawbacks of disaster recovery vs. backup.
Recovery isn't a task admins should take lightly. Outages can cost anywhere from tens to hundreds of thousands of dollars, so effective recovery methods are critical to the overall organization. The primary challenge is that different VMs have different levels of importance, and using the same protection service for all workloads can be expensive.
Admins should prioritize whether to use disaster recovery vs. backup before designing a comprehensive disaster recovery plan. Backups are designed to recover virtual workloads through a process that might take hours or days, and it typically occurs in the same location. Disaster recovery should be quicker and typically occurs at a different location from the primary site on different hardware or in the cloud.
Beyond the technical and logistical aspects, cost is another issue to consider in the disaster recovery vs. backup debate. Disaster recovery services are often significantly more expensive than backups because they typically duplicate entire production environments, but they aren't used daily.
Most companies have both disaster recovery and backup strategies. It's important to understand how workloads fit into each so admins can optimize these environments. Fundamentally, backups should protect all workloads. This makes sense for the primary data center, but what about the disaster recovery site?
Many people would argue that if admins have the ability to fail over the primary site to a disaster recovery environment through data replication, then they don't need to back up those virtual workloads again because they are essentially a clone of the primary site. This tactic can lead to problems if the workloads run longer than expected at the disaster recovery site. If the workloads are there for more than 24 hours, the disaster recovery site could end up containing a sizable amount of primary data, which is an issue if it's not protected.
Duplicating a backup environment isn't going to be easy or cheap, but most organizations can't afford to be rash with data. It's critical to understand which virtual workloads are going to a disaster recovery environment and which aren't. A disaster recovery site needs some level of backup, and those costs can add up quickly.
Evaluate dependencies when debating disaster recovery vs. backup
Admins must prioritize which workloads require disaster recovery and which don't. This decision isn't always easy because modern applications can have many dependencies.
While it might be nice to have every single VM and application at the disaster recovery location, the simple fact is that some applications aren't worth the effort and cost.
Virtualization enables applications to scale out horizontally. This application stack might include databases and web servers that support the application and other services, such as authentication and reporting servers. All of these components, including the primary storage for them, need to exist and replicate to the disaster recovery site.
Infrastructure servers pose another relevant challenge to the disaster recovery vs. backup decision. Infrastructure servers don't have to replicate to the disaster recovery site, but they need to exist and run at the disaster recovery site. Most of these include domain name and dynamic host configuration protocol servers, Active Directory, single sign-on and other backup management servers that may stretch across data centers. These infrastructure components must be available for the application servers to run properly.
If there are limited host resources at the disaster recovery site, it might be better to run these virtual infrastructure workloads lean. Use OSes such as Windows Server Core rather than a GUI to reduce the resource overhead.
A lean mindset can also help admins navigate the disaster recovery vs. backup decision. While it might be nice to have every single VM and application at the disaster recovery location, the simple fact is that some applications aren't worth the effort and cost. This is more of a business decision than a technical one.
For example, admins may have to abandon some important servers that the organization considers critical when all systems are running normally, such as print or file servers. In the middle of a data center outage, is it really critical to print? Printing is important, but if admins are trying to keep core systems online, then limited disaster recovery resources might be more useful elsewhere.
Whether to use disaster recovery vs. backup isn't an easy issue to resolve, and it often inspires multiple answers depending on the stakeholder. Everyone needs backups, and everyone wants disaster recovery. The challenge is that admins rarely have enough resources for both.
Use a lean mindset when it comes to VMs, investigate the criticality of different workloads, and always test and optimize chosen workloads so that if disaster recovery becomes necessary, workload performance meets expectations.
