Why is a disaster recovery plan necessary?

Having a backup does not mean the business will pick up where it left off. Disaster recovery means writing down, in advance, which system will be brought back by whom, and how soon, when an outage happens.

A backup is not a plan

A backup is a copy of the data. The 3-2-1 arrangement described in our article on the 3-2-1 backup rule explains how those copies should be kept. Disaster recovery explains how the business continues with those copies: which system starts first, who makes the call, who tells the customer, and what the target time is.

Even if the copy is sound, recovery takes longer when order, authority and communication are not written down. In a small team, the one person who knows the server is often on leave. A plan turns the knowledge in that person's pocket into the company's knowledge.

Why should an SMB write one too?

An outage is not only a data-centre problem. Ransomware locks files. A fire or a flood makes the room unusable. A long power or internet cut, or a single server failure, ends the same way: accounting, email or shared files will not open.

You do not need to put a number on how likely these scenarios are. The question is simpler. If these systems were down tomorrow morning, what would you do by noon, and who would know?

RTO and RPO

Two targets are enough. Write both of them in hours or days.

The recovery point objective (RPO) is how much data loss you accept. It is the time since the last good copy.

The recovery time objective (RTO) is the time you accept before the system is usable again. Writing "as soon as possible" is not a target.

In the same company these two numbers change from system to system. In day-to-day accounting, losing yesterday's vouchers breaks the month-end close; the RPO there needs to be shorter than one business day. The application itself can wait until the next morning, and the cash desk can cope for a day, so the RTO can be one business day. For company email, losing a few hours of messages is often tolerable, so the RPO is looser. By contrast, the screen where a customer order lands is measured in hours for the RTO. Write the list system by system. Do not give every system the same time.

Five items in a minimum plan

A thick folder is not required. The first version consists of:

1. Critical systems: accounting, email, the file area, and production or order software if you have it.
2. Owners: one name for each system, and a second name for when that person is away.
3. Recovery order: authentication and the network first, then the application the business stops without, and the archive last.
4. Communication: who tells employees, customers and, if there is one, the supplier; through which channel; and what they will say.
5. A tabletop exercise once a year: the team talks through a scenario, for example ransomware or an unusable server room, step by step. The missing decision and the missing person show up there.

An exercise does not replace a restore test that shows the copy actually opens. They are separate jobs. One shows that the copy is sound. The other shows that the plan works.

An untested plan is not a plan.

Where you get stuck in the exercise is where you will get stuck on the real day. Correcting the note and putting the next date on the calendar is better than leaving the plan on the shelf.

How can Doğa Network help?

Our team can help you write the disaster recovery plan, set RTO and RPO targets per system, and run a tabletop exercise. Call us on +90 850 888 3642 or email hi@doga.network.