Do you have a disaster recovery plan?

<introEmbed body={<> At some point every business will experience a catastrophic incident. At these times it is important to have a plan that explains who to contact, the priority of restore and how to restore services. At the time of a disaster, you should have a few objectives established and measure some results - The objectives are **RPO** (Recovery Point Objective) and **RTO** (Recovery Time Objective); and the measurements to take are **RPA** (Recovery Point Actual) and **RTA** (Recovery Time Actual). It's recommended to practice your disaster recovery at least once every 12 months. This way you make sure that you are investing in the minimum amount of required resources, and that your plan actually works. </>} />

So what do these terms mean?

RPO

RPO or Recovery Point Objective, is a measure of the maximum tolerable amount of data that the business can afford to lose during a disaster. It also helps you measure how long it can take between the last data backup and a disaster without seriously damaging your business. RPO is useful for determining how often to perform data backups.

RTO

RTO or Recovery Time Objective, is a measure of the amount of time after a disaster in which business operation is retaken, or resources are again available for use. This measurement determines the amount of resources that are required for the recovery to happen within the timeframe required.

RPA

RPA or Recovery Point Actual, is the actual measurement of the amount of data lost during a disaster recovery.

RTA

RTA or Recovery Time Actual, is the actual measurement of downtime during a disaster recovery.

How to calculate these values?

RTO and RPO are determined via a consultation called BIA (Business Impact Analysis). The organization needs to work out what the maximum amount of data that they are prepared to lose and also the maximum amount of time that they are prepared to be without services. These are both measured in time, and could be seconds, minutes, hours or days depending on the organization's requirements. This is a balancing act as generally the shorter the timeframe required, the more resources the organisation will need in order to achieve the target.

After this a disaster should be simulated to test that the RTA/RPA values match the RTO/RPO required by the organization.

---

Example: Mr Bob Northwind experienced a catastrophic incident. The failure occurred at 8pm local time on a Friday night. Their website and sales transaction software were affected.

In his Disaster Recovery Plan he had the following objectives:

Service	RPO	RTO
Northwind Website	2 days	4 hours
North Sales	4 hours	8 hours

::::info

It is important that these objectives are signed off by the Product Owner as per this rule

::::

After the recovery was complete they then analyzed the downtime which showed the following:

Service	RPA	RTA
Northwind Website	8 hours	2 days
North Sales	8 hours	8 hours

After analyzing the data, they discovered a few issues with their Disaster Recovery Plan:

1. They didn't have any spare hardware on premises which meant that to get the website backed up and running they needed to find a shop on a weekend to buy a server and then start the recovery process. This delayed them by an entire day.
2. Mr Northwind's IT Manager had mistakenly set the backups to 12-hour backups (at midnight and midday each day). This meant that the most recent backup for both services had occurred at 12pm on Friday and they had 8 hours of missing transactions. The greatest allowable data loss should have only been 4 hours.

This explains why it is important to practice your disaster recovery plan. A real incident is not the ideal time to realize that your backup/procedures are inadequate.