Today we will be diving a bit deeper into the considerations that you must take into account when planning backups (and when creating your disaster recovery plan). We previously discussed separation of command and control of backups versus command and control of the systems being backed up. We also discussed the differences between cloud file sync and share solutions and backup solutions.

Today we take a step back into the backup planning phase and cover two critically important aspects of your backup plan: RTO and RPO

RTO stands for Recovery Time Objective and is a measure of how quickly after an outage a service must be available again. This is basically an indication of how quickly we should be able to get services/operations back online after a disaster event/incident.

RPO stands for Recovery Point Objective and refers to how much data loss your service(s) can tolerate. This is basically an indication of how frequently backups should be taken.

An easy way to think of these two components is on a timeline – see below.

 

 

It’s easy to fall into the trap of simply stating that your RTO is 15 minutes and your RPO is 10 minutes (those are pretty extreme values, by the way). Everyone wants to be able to restore as quickly as possible (RTO) with as little data loss as possible (RPO) but for most organizations that’s not nearly specific enough, not realistic, and is also not economical. You must list out your critical services and put thought into each service and determine what the objectives for each truly are; there should be an RPO and RTO target set for each service listed. Two major factors that play into these decisions include costs and risk tolerance. For each service you must categorize criticality and make decisions involving how much risk your organization is willing to tolerate as it relates to downtime and data loss. You must decide on how frequently disaster recovery testing is performed and to what extent those tests are run. The lower you set RTO/RPO targets and the more frequently you perform testing, the more expensive your backup and recovery solution becomes. Below you can see a diagram that outlines this principle; the closer you get to the center, the more expensive your solution becomes.

 

 

Backups done well is not cheap… Backups done cheap are not worth the money you pay for it.