Top 5 Reasons Why Backup is Not Disaster Recovery

By Zerto, on 28 January, 2013

Today’s post was written by Jennifer Gill, Zerto’s Director of Product Marketing.

Many organizations have a backup strategy but not a disaster recovery strategy, why? Because they think that if they have backup then they have a disaster recovery plan. Not quite. Here are 5 reasons why backup is not disaster recovery.

1. Service levels – low recovery point objectives and recovery time objectives.

Backup products do not deliver recovery point objectives of seconds and recovery time objectives of minutes. Backups typically happen once per day and at night, so your recovery point objective could be 23 hours. If you are protecting a mission critical application, 23 hour data loss is not acceptable. Rebuilding a virtual machine, and everything that goes along with it, from tape can take days. If you are rebuilding from disk, it might be a little faster – a few hours. Again, this is not a service level that a mission critical application can tolerate.

2. Application impact: Performance and backup window.

There is a reason why backups occur at night – making a copy of an application and its data drains the CPU on the server. If you need more aggressive RPOs than 23 hours as stated above, that means you have to create copies more frequently. This is possible, but at the expense of CPU. This significantly impacts end-user productivity. Additionally, the backup window is a fixed period of time. As stated, this occurs overnight so most organizations assign 8 hours for a backup to complete. The application must be quiesced and then copied. As the applications grow and grow, quiescing the application and backing it up cannot be completed in the backup window.

3. Retention.

Backups are typically stored for a very long time for compliance and audit purposes. Disaster recovery information is stored for hours or days. Additionally, for a backup, you will have just one snapshot of the application and data. For an enterprise-class disaster recovery solution, you will have several points in time to failover to, just in case the last point in time is corrupted.

4. Automated recovery.

Building the environment from a backup, especially a tape backup, is extremely time consuming. This is why the recovery time objectives are so long. With an enterprise-class disaster recovery solution, the entire recovery process can be automated. The VMs on the protected site will automatically be shut down, and then the replicated VMs on the replication site will be started. Any re-IPing will happen to ensure end-users have fast access to the application and data. For mission critical applications, this entire process should take just a few minutes. This is a very different service level from a backup solution. Additionally, an automated process is a foolproof process, since every manual step that is introduced is an opportunity for an error. A disaster recovery strategy must eliminate as many opportunities for error as possible – automation accomplishes this and even verifies it through non-disruptive testing. It is critical that testing can be done without impacting the applications and data so that end-user productivity is not affected in anyway. Once the testing is complete, customers know that failover, recovery and failback will perform as the business requires.

5. Reverse replication.

Once an application is available on the replication site, end-users are using it, which is great. However, you must make sure that this application continues to be protected. A backup solution will not start taking backups and ship them back to the production site. A disaster recovery solution will ensure the replicated application is protected by replicating back to the source site.

One of the most recognizable names in IT, this Fortune 100 company had one DR goal: business continuity for their virtualized tier-1 applications such as SAP, Oracle and Microsoft SharePoint.
Find out why this Fortune 100 company chose Zerto over array-based replication.