The disaster recovery plan defines in what order, under whose responsibility and with what resources the systems will be restored after a significant outage. RPO refers to the acceptable data loss range, and RTO refers to the targeted return to service time; these must be verified by the measured result.
In this guide
Start with business impact, not the product list
Determine with the business owners which work stopping will have what consequences. Accounting, production, sales and communication may not be the same priority. Record how staff can work temporarily and for how long.
NIST's disaster planning guidance provides the basis for evaluating business impact and recovery preparedness together. The organization's objectives should be prepared according to its own activities rather than an exact copy of this guide.
Technical reference: NIST — Disaster planning.
How does the RPO and RTO goal become concrete?
| target | question to ask | The result to be seen in the test |
|---|---|---|
| RPO | In what time period is the maximum loss of data acceptable? | Time of recovered data |
| RTO | When should the service be available again? | Turnaround time including preparation |
Example scenario: while a team can recreate the last few hours of work, the same loss may not be acceptable to the ordering system. This is an example of a job evaluation; it is not a specific goal or customer outcome.
What dependencies are the recovery order based on?
Network, identity, DNS, storage or database may be required before the application runs. It will not be enough to turn on virtual machines without these dependencies being sorted. It should be considered that the accounts and keys to be accessed during recovery are also accessible when the production environment is lost.
Backup copies, alternative hardware, licenses, internet lines and external suppliers are part of the plan. Determine who is responsible for each step and who will take over when necessary.
How to separate desk study from practical testing?
In desk work, decisions, communication and responsibilities are reviewed. In practical testing, the selected system is actually restored and its function is checked. The scope, duration, data point, and failed steps of the test should be reported.
Review the plan after each significant application or infrastructure change. With your critical application list and available recovery capabilities backup and recovery You can evaluate its scope.
Related resources
Official sources
Technical documentation and legislation may change; The relevant version and current text should be checked before application.
Frequently Asked Questions
Should the same RPO and RTO be selected for each system?
No. Business impact and cost requirements differ. Priority should be determined with business owners.
Does having a backup service replace a disaster recovery plan?
No. Access, alternative resources, application dependencies and decision process should also be prepared.
