Zettagrid Latest News 5 Reasons Why Backup Is Not Disaster Recovery

Latest Posts

5 Reasons Why Backup Is Not Disaster Recovery

June 21, 2017 09:00AM

We often hear about "Backup and Disaster Recovery" as if they are one in the same. In a way they are. But let's be clear,  backup is not disaster recovery! You can't have disaster recovery (DR) without backup, and you can have backup without DR, but why?

1. Service Levels

Backups typically happen once per day and at night, so your RPO could be 23 hours! When protecting mission-critical applications, 23-hour data loss is not acceptable. Without any recovery orchestration, the RTO will also be significantly higher. Rebuilding a virtual machine and everything that goes with it, from tape, can take days; from disk, it might be slightly faster — a few hours.

2. Application Impact

Backups occur at night because 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.

3. Automated Recovery

Building an environment from a backup, especially a tape backup, is extremely time consuming. This is why the RTOs are so long. With an enterprise-class disaster recovery solution, the entire recovery process can be automated. 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.

4. 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.

5. Reverse Replication

In the event of a disaster, once an application has been made available on a target site, you must extend that application’s protection to include new data being created. However, you must make sure that this application continues to be protected as the users create additional data. A backup solution will not start taking backups and ship them back to the production site. A disaster recovery solution will ensure the application is still protected by replicating back to the source site.

“It’s great to have a backup. But it’s not okay to take a month to get the backups up and running.”   -Matthew Curtin, Interhack

 


Veeam CTA Blog 2.png