RPO (Recovery Point Objective)

Definition

RPO is the maximum acceptable data loss, expressed as time: a one-hour RPO means that after a failure, no more than the last hour of changes may be gone. In practice it is the required interval between good backups. Where RTO asks how long the client can be down, RPO asks how much work they can afford to redo.

Why it matters to an MSP

RPO sets the backup frequency, and frequency drives storage, bandwidth, licensing, and monitoring load – which is what separates the price tiers. A 24-hour RPO is a nightly job to the cloud; cheap and adequate for general workstations and most Microsoft 365 data, where the SaaS backup itself typically runs 1–3 snapshots a day. A four-hour RPO on a file server means intermittent image backups with change tracking, usually direct-to-cloud. A one-hour RPO on a practice-management or ERP database means a local appliance snapshotting hourly with an immutable cloud copy – the appliance tier, which costs several times more than direct-to-cloud image backup. Tighter than an hour needs application-level replication, which few small clients will pay for.

The client owns this number, but only once you make it concrete: "If the server dies at 4 p.m., are you re-entering the day since last night, or only the last hour?" Ask per system and write the answer into the service agreement and the business continuity plan. Then police it. Last-good-backup age is the RPO metric; anything past the agreed window is an incident to escalate that day, because a Tier 1 client whose hourly job failed quietly a week ago is running on an RPO they are not paying for. How objectives translate into architecture is covered in backup and recovery design.

Related terms: RTO, BDR, Business Continuity Plan, Ransomware