Skip to content
2026

Now taking on 4 new clients this year — white-glove onboarding, month to month.

Book a call
HomeGlossaryRecovery Point Objective (RPO)
Glossary

Recovery Point Objective (RPO)

A recovery point objective (RPO) is the maximum amount of data, measured in time, that a business can afford to lose between its last backup and a failure.

Definition

What is Recovery Point Objective?

A Recovery Point Objective (RPO) is the maximum amount of data loss a business is willing to accept when a system fails, expressed as a span of time. If the RPO for the accounting server is four hours, then a backup must be taken at least every four hours, because anything entered after the last successful backup is gone when the server is restored. The RPO is a business decision first and a technical setting second: it answers the question of how much re-entry or lost work the company can tolerate.

The figure drives the backup design. A nightly backup gives an RPO of roughly a day. Hourly snapshots give an hour. Continuous replication to a second site or a cloud platform brings the RPO close to zero, at a cost in bandwidth, storage, and licensing that many small firms do not need for every system. Different systems can and should carry different RPOs. A file server full of scanned contracts can lose a day without harm if the originals exist on paper; a practice management database that takes appointments all day cannot. Microsoft 365 mailboxes and SharePoint libraries have an RPO too, and Microsoft's built-in retention is not a backup, so a separate backup product is needed to set one.

The RPO also has to survive a bad actor. Ransomware crews look for backups and delete or encrypt them before they trigger, so a backup taken every hour but stored on a share the domain administrator can reach may leave the real RPO at whatever the oldest offline or immutable copy happens to be. Testing a restore is the only way to know the number is real.

NetSys includes disaster recovery planning in every managed agreement, and setting an RPO per system is one of the first steps in that plan. The firm works through each application with the client and records how much loss is acceptable, then configures backup frequency and immutable retention to match. Its FAQ on backup and disaster recovery for small businesses covers the questions owners ask most often.

Why it matters for a small business

RPO is the number that decides how much of your work disappears on the worst day. Owners often assume a backup exists and never ask how old it will be when they need it. A nightly copy means a full day of invoices, orders, emails, and appointments can vanish, and a copy the attacker could reach means the loss may be far larger. Deciding the RPO for each system forces a plain conversation about what the business can re-enter by hand and what it cannot. That conversation costs nothing and usually changes the backup schedule.

Common Questions

Recovery Point Objective (RPO): FAQs

What is a recovery point objective in simple terms?

It is how much data you are willing to lose, stated as a period of time. An RPO of one hour means the business accepts losing up to an hour of work when a system fails, so backups must happen at least hourly. An RPO of a day means a nightly backup is enough. The number is chosen by the business based on how painful re-entering that work would be, and then the backup schedule is built to meet it.

What is the difference between RPO and RTO?

RPO is about data: how far back in time the restored system will be, which is set by how often you back up. RTO is about time: how long the system can stay down before the business is harmed, which is set by how quickly you can restore. The two are independent. A firm can have a short RPO and a long RTO if it backs up hourly but takes two days to rebuild a server, and a disaster recovery plan has to address both.

How often should a small business back up its data?

As often as its recovery point objective requires, which differs by system. Line-of-business databases that change all day usually justify hourly or more frequent snapshots. Document stores and file servers often do well with several backups a day. Static archives can be backed up nightly or less. Whatever the schedule, at least one copy should be immutable or offline so an intruder cannot delete it, and restores should be tested on a calendar rather than assumed to work.

Reading this because of a questionnaire or a renewal?

Get the controls, not just the definition.

A NetSys engineer can tell you in fifteen minutes whether you have this covered, and what it would take if you do not. Month to month, no long-term contract.