It is 3:14 in the morning and the billing system has stopped responding. The clock is ticking, orders are piling up and every minute that passes has a price: sales that don't close, customers who cannot operate, teams paralyzed while they wait for something to come back online. The question that defines an organization in that moment is not whether the failure happened, but how long it takes to recover and how much information was lost along the way. That is the underlying conversation in any disaster recovery plan.
In short: recovery time is money. A serious disaster recovery plan (DRP) is not measured by the number of pages it has, but by two numbers agreed with the business: the RTO (how long a service can be down) and the RPO (how much information can be lost). Defining those numbers by criticality, and backing them with replication and hot recovery, is what separates a scare from a crisis.
When a critical service goes down, the cost is not linear: it grows with every hour. There are visible costs, such as unbilled sales or contractual penalties, and silent costs that weigh more over the long term: eroded trust, teams reassigned to firefighting and decisions made blindly because the data is not available.
The frequent mistake is treating all systems the same. Not everything needs to come back in minutes, but some services cannot wait hours. That is why the first discipline of a DRP is to put a value on time: what does an hour of downtime cost for this particular service? That answer, even if approximate, brings order to everything else.
There are two metrics worth setting before buying technology or designing architectures. They are the backbone of any disaster recovery strategy:
The key is that both numbers are defined by the business, not by technology. The technical area designs the solution to meet them; the process owner decides how much time and how much data are tolerable. When that conversation does not happen, the organization discovers its real RTO and RPO on the day of the incident, and they are almost always worse than imagined.
This is not about demanding "zero downtime and zero loss" for everything, because that is expensive and, in most cases, unnecessary. It is about calibrating. A practical way to do it:
This exercise is, in reality, an extension of the business impact analysis that lives within a business continuity plan. The DRP is the technological leg of that continuity: it translates the priorities of the business into measurable recovery objectives.
With the RTOs and RPOs defined, it is wise to group services into tiers. This avoids overspending on what does not warrant it and underspending on what does. A reference scheme, which each organization adjusts to its reality:
The value of this classification is that it turns an emotional discussion ("everything is urgent!") into a reasoned investment decision. Each tier has an associated cost and architecture, and the business can see what it is paying for every minute it saves.
For critical-tier services, traditional backups rarely suffice: restoring from a copy can take hours the RTO does not allow, and last night's copy may violate an RPO of minutes. This is where two capabilities come in:
These capabilities cost more, which is why they are reserved for what truly needs them. The smart decision is not to "replicate everything" but to align each service's level of protection with the RTO and RPO the business has agreed to pay for. A mature DRP is, at its core, an honest negotiation between the cost of time and the cost of prevention.
One point worth remembering in these year-end months, when budgets are being planned: a DRP is not a deliverable to be filed away. It is a capability that must be kept alive. The RTOs and RPOs defined today must be revisited when the business changes, when systems are added or when an acquisition alters the process map. The number that was tolerable last year may be ruinous today.
The RTO measures downtime: how long a service can be down. The RPO measures data loss: how far back in time you can recover the information. A service can have a high RTO and a low RPO, or vice versa, depending on what the business tolerates.
No. Backups are one piece within the DRP. For deferrable services they may be enough; for critical services you also need replication and hot recovery, because restoring from a copy usually takes longer than the RTO allows.
By starting from the business, not from technology. Map the processes, estimate the cost of having them halted per unit of time and let that impact define criticality. A server that is important to IT may support a deferrable process, and the other way around.
It would be the most expensive, and not necessarily the most sensible. Protection should be proportional to impact. Replication and hot recovery are justified where every minute costs; for the rest, they make the operation more expensive without a clear return.
If your organization still does not have an RTO and RPO agreed in writing for its critical services, that is the place to start: a conversation between the business and technology that puts a number on the cost of time. At SUMāTO we support that exercise, from classifying services into tiers to designing the replication and hot recovery each tier requires. Let's talk about how to ensure that, the next time the clock starts ticking, you know exactly how long you can wait and how much you can afford to lose.