Backup VS Disaster Recovery (DR)


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.


Related Articles:

What is Disaster Recovery as a Service?

The differences between Disaster Recovery, Backup and Business Continuity

What is Disaster Recovery as a Service (DRaaS)?

Until the last few years companies wanting quick fail-over to a remote site faced huge costs, time and complexity.  Consequently, only very large companies with deep pockets could afford to implement offsite disaster recovery.

Today, the technology and the internet have enabled highly cost effective methods to provide DR services to organizations that traditionally have not been able to afford such capabilities in the past.  In combination, today’s consumers expect the services they use to always be available, and this drives many companies to look at implementing DR fail-over so business is not interrupted.

The cost of an organization hosting its own disaster recovery site can be cost-prohibitive. Not only in terms of money but also time, and effort. Costs include hosting remote sites, managing servers, managing applications, monitoring the backups and replication, and regular testing. However, it’s possible to offset these costs by utilizing a service provider offering Disaster Recovery as a Service, or DRaaS.

DRaaS is a way for organizations to utilize service providers, like Managecast, who provide protection for virtual servers in a cloud environment by offering infrastructure, software, and management for DR solutions.


Organizations utilizing DRaaS replicate their data continuously or periodically, depending on their desired Recovery Point Objective (RPO), to the service provider. Then, in a DR event, the organization can fail-over all or some of their environment by simply powering on their VMs in the service providers cloud-DR infrastructure and continue to operate.

The organizations have access to failed over replicas through predefined methods. In the event of a partial failover of only some of the organizations servers their local network can be extended to the cloud-DR environment allowing them to access the servers as if they were still hosted locally. Alternatively, in a full failover event an organizations servers can be accessed remotely. E.g. through a web console, VPN or remote desktop services. Service providers and also provide new public IPs to minimize downtime for public facing applications.

An example of a web console used for failover and testing DR.
An example of a web console used for failover and testing DR.

If after the fail-over has been performed the organization is able to get their local infrastructure back up and running, depending on the DR solution, they can also fail back to production. Failing back means replicating any changes made during the fail-over in the DR environment back to the production side.


After replicating to the service provider, it will be necessary to perform regular DR testing to make sure things go smoothly in a DR situation. Most DRaaS providers will allow organizations to perform their own testing which allows them to set test criteria.

Testing can be as simple as logging into the service providers web console, powering on a VM, and verifying application or service functionality.


While not all service providers charge for DRaaS the same, a common model is based on usage per hour. Meaning that the organization will be charged for only what they use.


In some cases the DRaaS provider will offer additional management in terms of the replication process. This can include monitoring the replication, alerting the organization of any potential issues, as well as providing fully-managed service solutions.

While an organization may view DR as an additional cost, for DRaaS service providers providing backup and replication is their sole focus. By using a service provider for DRaaS they gain access to that expertise and can leverage them for any DR needs.