Several years ago your main, and usually only option for disaster recovery was to take backup media and perform a restore onto new hardware. This means copying a large amount of data from backup media back to a server. We call this “Backup Recovery” or “Standard Recovery”. It’s the process most people are used to and the standard method for decades.
As data volumes have exponentially expanded, combined with an “always on” culture of today’s society, the old means of recovery are no longer adequate for a lot of businesses.
Unfortunately it is sometimes at the worst time, during an actual disaster event, that it is fully realized the current backup solution is no longer meeting the disaster recovery requirements of the business. When management realizes it takes 48 hours to just restore (copy) the data is when the Recovery Time Objective (RTO) is more clearly appreciated! Many times after these events companies update their RTO policies and implement changes. Obviously it would be better to consider this situation and enact changes prior to the disaster.
For organizations that need quicker recovery time the option is to implement some form of “replication” in which all of the production data is replicated to another system for DR purposes. The replication could be local, and/or could be offsite to a service provider. The key to replication is that you are keeping a copy of your entire server in another place so that if your primary server is compromised in some way, you can “turn on” the DR server and be back up and running within minutes, current as of the last backup. This typically allows the organization to resume operations much more quickly since the data did not need to be restored, but rather was already in a state to be used almost immediately. Replication is really the only way to minimize the recovery time since it eliminates the restore process.
On the other hand, backup still serves a valuable service that is not well addressed by disaster recovery (replication). In a disaster situation you are typically most interested in the most recent version of data and not the data from months or years ago. Organizations with retention policies may want months, or even years of past versions of backup data. DR does not address this need, however, backup is used for retrieving data that may have changed in the past. For instance, a user may delete a file, but not notice for months. Backup would be used instead of DR for this older data since DR is focused around the most recent version of data. Typically no one wants to do a disaster recovery with 6 month old data!
Backup is also usually much easier to use for granular restores of a few files or directories. DR is focused around an all or nothing approach. In a DR situation you are typically restoring entire servers. Backup makes a granular recovery easier. For this reason, backup is typically more often utilized than DR.
There is often the need for both backup and DR solutions to address both needs. VEEAM Backup and Replication, for instance, gives you the capability of choosing Backup or Replication (DR), or you can elect to do both. If you can not afford to do both then you will need to contrast the pros and cons of backup and DR and decide on which one best meets your requirements. For example, if you need quick recovery, but do not need long-term retention, it may be possible to use DR as a form of backup. On the other hand, if you do not require quick recovery, but need long-term retention then backup-only may be best. However, if you need both quick recovery and long-term retention then you need both backup AND Disaster Recovery.
The table below contrasts some of the differences between Backup and Disaster Recovery.