What RPO Means for an MSP
Recovery point objective measures loss in time: the gap between the last good copy of the data and the moment it was lost. The client sets it by asking how much work they could afford to redo. You then build a backup schedule that meets it. It sits beside RTO, which covers how long the system can be down, and the two together shape every backup design you quote.
Set RPO per system. A finance database that changes all day and a file share of signed contracts rarely need the same schedule, and pricing them the same wastes money on one or risks the other.
Ask the question in the client's terms: if this system lost everything since the last copy, how much work would people have to redo, and could they redo it at all? Orders taken over the phone and never written down cannot be recreated, which pushes the RPO for that system down sharply.
How RPO Sets the Backup Schedule
| If the RPO is | The design usually needs |
|---|---|
| Near zero | Replication or journaling to a second copy |
| An hour | Frequent snapshots or incremental backups through the day |
| A day | A nightly backup job |
A tighter RPO means more frequent jobs, more storage and often more bandwidth to the cloud copy. That is why it belongs in the quote and in the agreement, and why how to price security services treats backup tiers as a line the client chooses.
Why a Green Backup Report Can Still Miss It
Backup success only proves the RPO holds if the jobs that succeeded ran often enough. A nightly job that never fails still misses a one hour RPO. Watch for these gaps:
- Jobs that skip open files or databases and report success anyway.
- Retries that push a job past its window, so the real gap is longer than the schedule suggests.
- SaaS data such as Microsoft 365 that sits outside the backup scope entirely.
- Ransomware that encrypts data before the backup runs, which makes the latest copy the wrong one to restore.
Track Backup Success Rate and Restore Test Pass Rate together, and when you test a restore, note how old the recovered data was compared with the RPO.
Keeping RPO Current
A client's RPO changes when they add a system, move to a new app or start taking payments online. Review it at the QBR and update the schedule and the agreement together.
Common Questions
Is a longer retention period a better RPO?
No. Retention is how far back you can restore; RPO is how recent the newest copy is. You need both, set separately.
Does replication alone meet a near-zero RPO?
It keeps a current copy, but it also copies corruption and encryption. Pair it with point-in-time snapshots you can roll back to.
Should I write RPO into the agreement?
Yes, per system, along with what the client declined. It turns a vague backup promise into one you can measure.