In-Depth

3 Best Practices for Successful Backup and Disaster Recovery

Here's what to keep in mind when planning your organization's backup and DR capabilities.

• By Brien Posey
• 06/17/2019

The terms backup and disaster recovery (DR) are often used interchangeably. Even so, there's a significant difference between the two. Backups are point-in-time copies that can be used to restore data or a physical or virtual machine to a previous state. In contrast, DR refers to the ability to run a workload in a different location so that the workload will remain online and available in spite of a disaster. Following are some best practices organizations should keep in mind when planning their DR and backup implementations.

One of the most important best practices for organizations that are considering their backup and DR capabilities is to avoid thinking of these two options as being mutually exclusive. Having the ability to perform a DR failover does not render backups obsolete or unnecessary. Disaster recovery operations protect an organization's mission-critical workloads against an infrastructure failure (such as a virtualization host cluster failure or the failure of an entire datacenter). In contrast, backups protect an organization against accidental deletions or modifications, or against ransomware attacks.

An organization needs both DR and backup/restore capabilities. It's important to ensure that mission-critical workloads continue to function in times of crisis, but it's equally important to make sure that your data can be restored to a previous state if the need should arise.

Another best practice is to periodically evaluate the backup and DR mechanisms that your organization has in place, and compare those against the organization's current requirements. Operational requirements tend to change over time, as do legal requirements. A backup solution that was put in place five years ago, for example, might be incapable of adequately protecting some of the workloads that the organization has in place today. Even if the backup solution can protect all of the organization's workloads, the solution may not adhere to the organization's current SLAs.

The same basic principle also applies to DR. Yesterday's DR solution might be ill equipped to handle today's workloads. If an organization originally designed its DR solution to protect virtual machines, for example, that solution might need to be extended to also protect containerized workloads.

One more best practice is to balance your backup and DR efforts between on-premises resources and cloud-based resources. Modern backup solutions, for example, almost always support cloud backups. Cloud-based backups are nice in that they provide physical isolation between the resources that are being protected and the backups of those resources. However, the problem is that large-scale cloud restorations tend to be slow and expensive. As such, it's a good idea to maintain backup copies both on-premises and in the cloud.

The same idea applies, although to a lesser extent, to DR. The cloud is usually going to be the best location for running workloads in a DR situation. Even so, the scope of a disaster can vary widely, and not every event warrants failing workloads over to the cloud. This is especially true of hardware failures when at least some degree of redundancy is in place (such as a cluster node failure, or in the case of a partial failure of a load-balanced application). In such cases, it may be easier and more cost effective to continue operating a workload in its original location -- but at a reduced capacity -- than to initiate a failover to the cloud. As such, the organization should define the circumstances under which a cloud failover is truly justified.