A server will fail one day. A disk breaks, a provider has an outage, someone deletes the wrong thing, or ransomware encrypts everything it can reach. A disaster recovery plan decides, in advance and in calm, what happens next.
What a disaster recovery plan is (and is not)
A disaster recovery (DR) plan is the written answer to one question: if this system is gone, how do we get it back, and how long will it take? It is not the same as having backups. Backups are the raw material; the plan is the recipe, the kitchen and the cook.
RPO and RTO, in plain words
| RPORecovery Point Objective | RTORecovery Time Objective | |
|---|---|---|
| The question | How much recent data can we afford to lose? | How long can we afford to be without the system? |
| Example | "Up to 24 hours" means a nightly backup is enough. | "Back within 4 hours" means you need a ready place to restore to. |
| What drives it | How often you back up. | How fast you can restore, start and check the system. |
Be honest with the numbers. "Zero data loss and back in five minutes" is possible, but expensive. For most small companies, an RPO of a few hours to one day and an RTO of a few hours to one working day is realistic — and far better than no plan at all.
The seven-step plan
List your important systems
ERP or accounting, email, file server, website, customer portal. Note who uses each one and what stops if it is down.
Set RPO and RTO for each
Agree them with management, not only IT. They decide how much to spend.
Check your backups match
If the RPO is 4 hours, a nightly backup is not enough. Fix the backup schedule first.
Decide where to recover to
Another server at the same provider, a different provider or region, or a ready standby server.
Write the steps
Short, numbered, tested steps: who starts recovery, where the keys and passwords are kept, how to point users to the new server.
Name the people
Who decides to start recovery, who does it, who tells staff and customers. Add a backup person for each role.
Rehearse and update
Practise on a test server at least once a year and after big changes. Update the plan with what you learned.
Where should you recover to?
| How it worksin short | Speedtypical | Costtypical | |
|---|---|---|---|
| Restore to a new server when needed | Create a server and restore the latest backup. | Hours | Lowest — you pay only when it happens. |
| Different provider or region | Same as above, but somewhere not affected by the same outage. | Hours | Low — protects against a whole provider being down. |
| Warm standby | A smaller server kept ready and updated regularly. | Minutes to an hour | Moderate — a second server runs all the time. |
Whatever you choose, make sure the decision to switch over is made by a person. Automatic failover can make a small problem worse if it switches at the wrong moment.
Rehearse it — on purpose
A plan that has never been tried is a guess. A rehearsal means actually restoring a system on a test server, starting it, checking it works, and timing it. Compare the time with your RTO. If it took twice as long, you have learned something valuable — on a quiet day, not during a crisis.
Keep a short record of each rehearsal: date, system, how long it took, what went wrong, what you changed. It is also exactly the evidence auditors and cyber insurers ask for.
Keeping the plan alive
The hardest part of DR is not writing the plan but keeping it true as servers, people and providers change. In TBS Infrastructure, each important server has its recovery plan with RPO and RTO, readiness checks show what is missing, and a rehearsal only passes when TBS Infrastructure itself sees the restored backup and the new server reporting in. Failover is never automatic: it runs a dry-run and checks first, and needs approval.
Want a recovery plan you have actually tested?
We can help you set RPO and RTO, write the steps and run the first rehearsal.
This article is general guidance based on our own experience as of 27 Oct 2026. It is not legal or compliance advice; requirements differ by industry and country.