What are RTO and RPO, and what should ours be?

RTO, the recovery time objective, is how long a system can be down before the damage is unacceptable. RPO, the recovery point objective, is how much recent work you can afford to lose. Decide both per system, in hours, before buying anything, because together they determine what your backup and recovery setup actually has to be.

The reason these two acronyms are worth learning, when most are not, is that they convert an unanswerable question into two answerable ones. Ask an owner how good their backups should be and you get a shrug or the word bulletproof. Ask how many hours the practice can run without the clinical system, and how much of today's work you could bear to re-enter, and you get real numbers, because those are questions about the business rather than about technology.

Take them one at a time. Recovery time is about downtime: from the moment something fails to the moment people are working again. It includes everything, diagnosis, the decision, the restore itself, verification, and people getting back in, which is why the honest number is always larger than the one on the vendor's datasheet. Recovery point is about data loss, and it is set by how often backups run: nightly backups mean a failure at four in the afternoon costs you the day's work, and whether that is a shrug or a catastrophe depends entirely on what your day's work is.

Setting them is a business conversation, not a technical one, and the useful method is to price the pain. For each critical system, ask what the first hour of downtime costs, then the first day, then three days, in revenue, in wages paid for people who cannot work, in appointments cancelled, in customer trust. The curve is rarely linear: many businesses can absorb a morning and are in real trouble by day three. Where the curve turns sharply upward is where your recovery time objective belongs, and the same logic sets the data-loss number, since re-entering four hours of transactions is an annoyance and re-entering four weeks is an existential problem.

Then tier the systems, because uniform targets are how backup budgets get wasted. Most small businesses land on three tiers: critical systems the business stops without, where hours matter; important systems that can wait a day; and everything else, where a week is survivable. Tiering costs nothing to do and saves real money, because it stops you buying the fastest recovery for the archive nobody has opened since 2019.

What the numbers then buy is straightforward. Loose targets, a day of downtime and a day of data loss, are met by conventional nightly backups and a competent restore process, which is what most small businesses actually have. Tighter targets, a few hours, need more frequent snapshots and faster restore paths, usually cloud-based. Very tight targets, minutes, mean replication and standby infrastructure, and the cost steps up accordingly. This is the whole point of setting the numbers first: you are choosing a tier rather than being sold one, and you can tell whether a proposal is over- or under-specified for your actual tolerance.

There is an external reason to write these numbers down as well as an internal one. The Essential Eight expects backups to be retained, protected and restored to a tested standard, and an assessor or an insurer asking how quickly you could recover is asking for your recovery time objective whether or not they use the phrase. A business that can answer with two numbers and a timed test result is having a different conversation from one that says we have backups, and the difference shows up in renewal questionnaires and tender responses long before it shows up in an incident.

Two things routinely blow real recovery times past the planned ones, and neither is the backup software. The first is dependency order, since restoring the application before the database it needs simply means doing it twice. The second is decision latency: hours disappear while people work out whether this is a real incident and who can authorise the response, which is why the recovery plan names who declares an incident. Both are free to fix and neither shows up on a datasheet.

The honest caveat is that a target is an intention until it is measured. Any provider, ours included, can write four hours into a document; only a timed test restore turns that into a fact, and the gap between the two is the most common unpleasant surprise in this field. Set your numbers, then insist on a test that proves them, at least annually. If you want help setting targets you can defend and building to them, call 1800 456 567.