RPO and RTO in plain English

RPO: how far back you would have to go

Imagine your file server fails at 3pm. If the last backup ran at midnight, everything changed between midnight and 3pm is gone. Your recovery point was midnight, so you lost fifteen hours of work. An RPO is simply the most data loss, in hours or minutes, you are willing to accept. If you decide your RPO is one hour, your backups must run at least hourly.

Different systems deserve different RPOs. Losing a day of changes to a folder of brochure designs might be annoying but survivable. Losing a day of invoices, bookings or patient notes may mean phoning customers, digging through emails and risking errors. Setting RPO system by system stops you overspending on things that rarely change and underspending on things that change constantly.

RTO: how long you can wait

RTO is about downtime rather than data. If your accounting server dies, how long can the team carry on before it becomes a serious problem? A few hours might be fine on a quiet day. Two days might mean missed payroll, unpaid suppliers and clients chasing invoices. RTO is the target time to get that system working again.

A short RTO needs more than a backup. Restoring a large server from the cloud over business fibre can take a day or more simply because of the volume of data. Achieving an RTO of a few hours might require a local backup appliance that can run a server image directly, spare hardware, or a cloud recovery service that can start your systems in a data centre.

Putting numbers on them

Sit down with the people who rely on each system and ask two questions: if this broke right now, how many hours of changes could we recreate without real damage, and how long could we work without it? Write the answers down plainly, such as 'job management: lose no more than one hour, back within four hours' or 'archive drive: lose up to a day, back within a week'.

Be honest rather than ambitious. Everyone wants zero data loss and instant recovery, but those targets are expensive. The useful question is what the business would really suffer, in money and reputation, at each level of loss or delay, and whether the cost of a faster setup is worth it.

What your current setup actually delivers

Once you have targets, compare them with reality. If your only backup is a nightly cloud copy, your real RPO is up to twenty-four hours, and your real RTO depends on how fast you can download everything onto replacement hardware, which you may not have. Many small businesses discover their actual recovery time for a server is three to five working days when they include ordering hardware, reinstalling and restoring.

Testing is the only way to know your true RTO. Time a full restore and add realistic time for getting hardware, licences and staff ready. That figure is often the motivation for changes such as moving a server workload to the cloud or keeping a spare machine configured and ready.

Ways to shorten each number

To improve RPO, back up more often. Hourly snapshots during business hours are common for busy databases, and cloud services like Microsoft 365 already keep data continuously replicated, so their effective RPO for a platform failure is tiny. For accidental deletion, though, your RPO is still set by how often your separate backup runs.

To improve RTO, reduce the steps between disaster and working. Options include backup appliances that boot a failed server as a virtual machine within minutes, cloud standby copies, documented rebuild procedures, and moving key applications to cloud services that do not depend on a single box in your office. Each step costs money, so prioritise the systems with the tightest targets.

A worked example

Take a fictional twelve-person engineering firm with a local server running a job costing database and file shares, plus Microsoft 365. Talking it through, the directors decide the job costing database needs an RPO of one hour and an RTO of four hours, because invoicing and timesheets stop without it. The file shares can lose half a day and be back within a day. Email in 365 needs to be recoverable for individual items, but the platform itself is Microsoft's job to keep running.

Their current nightly cloud backup misses both server targets. The fix they choose is hourly snapshots of the database during working hours, a small local backup appliance that can boot the server as a virtual machine, and the existing cloud copy for disasters. The 365 backup stays as it is. Writing the targets down first meant they spent money only where the gap actually was, rather than upgrading everything.