Your recovery time objective is a business decision, not an IT one

When a small business asks us to “sort out the backups,” the first meeting is not about backups. It is about two numbers that only the owner can set, and that quietly determine the entire design and cost of everything downstream.

The two numbers

Recovery point objective, or RPO, is how much data you can afford to lose, measured in time. An RPO of four hours means that in the worst case you redo up to four hours of work. Recovery time objective, or RTO, is how long the business can be down while systems come back. An RTO of two hours means everyone is working again within two hours of the disaster.

Both are business decisions. An engineer can tell you what a given RPO and RTO will cost. Only the owner can say what the business can actually absorb on its worst day.

Ask for zero downtime and zero data loss and you will get a quote that ends the conversation. The useful question is: what does one hour of downtime actually cost us?

Why IT should not set them alone

Left to solve it technically, IT will either over-build, running hot standby on everything, at a cost the business would never have approved if asked plainly, or under-build to hit a budget, and discover the gap only during the outage. Neither is IT's fault. They were handed a business trade-off dressed up as a technical spec.

How to set them in one meeting

Put the owner, the operations lead, and the IT contact in a room and work through three questions per critical system:

• If this were down right now, what stops? Sales, payroll, patient care, nothing until Monday?
• What does an hour of that stopping cost, in money, in obligations, in reputation?
• Given that, how many hours is tolerable, and how much lost work is tolerable?

The answers differ per system, and that is the point. The payment system might need a one-hour RTO; the internal wiki can be down for a day. Designing every system to the strictest number is how backup budgets balloon.

Then, and only then, pick the product

With RPO and RTO written down per system, the technical choice becomes almost mechanical. Daily backups suit a 24-hour RPO; continuous replication is for the one-hour systems. Cold storage suits a relaxed RTO; a warm standby is for the systems that cannot wait. The tooling stops being a religious debate and becomes arithmetic against numbers the business already agreed to. That is the whole trick: decide the tolerance first, buy the technology second.