RPO vs RTO for small teams: how often should you back up?

A five-person software company runs backups every night because that was the default in an old setup guide. At 16:00 on a busy Monday, a faulty import overwrites customer data. The newest backup is from midnight. The job ran perfectly, yet the team now has to decide whether losing sixteen hours of work is acceptable. Nobody ever made that decision; the schedule made it for them.

“How often should we back up?” cannot be answered from server size alone. It starts with the cost of losing changes. A mostly static documentation site and an order database can live on the same VPS while needing completely different recovery points. One schedule for the entire machine may be simple, but simplicity is not the same as an intentional service level.

Two measures make the conversation concrete: recovery point objective and recovery time objective. They are often presented together, then blurred into a vague promise that backups are “frequent.” Keeping them separate prevents a great deal of false confidence.

The recovery point objective, or RPO, is the maximum acceptable time between the last usable recovery point and the disruption. If the RPO is four hours, the business is accepting the possibility of recreating up to four hours of changes after a severe incident. It does not promise that exactly four hours will be lost; it sets the outer tolerance the design should meet.

Ask about business events rather than abstract minutes. How many paid orders can be reconstructed? Are support replies also stored in a separate system? Can uploaded legal documents be requested again? Could staff replay a day of content changes from version control? The answers often produce different RPOs for different parts of one product.

Meeting the RPO requires accounting for detection and job reliability. A backup every hour does not deliver a one-hour recovery point if failures remain unnoticed for six hours. The usable recovery point is the newest successful, reachable, application-consistent backup—not the most recent scheduled start time.

The recovery time objective, or RTO, is the maximum acceptable delay between disruption and restoration of the agreed service. It includes more than copying data: someone must recognize the incident, decide to recover, obtain access, provision a target, restore dependencies, validate the result, and reopen the service.

A team can have a one-hour RPO and a twelve-hour RTO. That means it wants little data loss but can tolerate a working day to rebuild. The reverse can also occur, although a very short RTO with a long RPO creates an odd promise: the service returns quickly, but with old data. Writing both values exposes that tradeoff before an incident does.

Backups alone tend to support recovery measured in hours, especially when infrastructure must be rebuilt. If the business truly needs seconds or minutes, it may need replication, standby capacity, automated failover, or a different application architecture. Those measures solve availability problems that a more frequent backup job does not.

Start with the shortest accepted data-loss window among the components in a backup set. Then account for backup duration, scheduling uncertainty, and the time required to detect failure. If a service can lose at most four hours of data, a backup that starts every four hours and sometimes runs for ninety minutes leaves no safety margin.

Do not reduce every interval automatically. More runs create more opportunities for contention, spend, retention mistakes, and noisy alerts. Database dumps can consume CPU and I/O; repository maintenance can overlap with other jobs. The sensible interval is the one that meets the agreed RPO with evidence, while leaving the production service healthy.

For high-change data, consider whether a nightly logical dump plus transaction-log or application-level recovery is more suitable than increasingly frequent full dumps. The choice depends on the database and operating capacity. The important distinction is between a recovery requirement and the mechanism chosen to meet it.

Small teams often avoid recovery planning because it sounds like every folder needs a bespoke policy. A few tiers are enough. For example, customer transactions may need a short RPO and same-day RTO; user uploads may accept a longer RPO but still need same-day recovery; rebuildable caches may need no backup at all.

Assign each service or data set an owner, RPO, RTO, backup method, and validation method. The owner is the person who can say whether restored data is useful, not necessarily the person who maintains the scheduler. Revisit the tier when revenue, data volume, contractual obligations, or business processes change.

Keep dependencies visible. Restoring the database in two hours is not a two-hour RTO if DNS, secrets, container definitions, and storage access take another day. The service target covers the complete customer-facing outcome, so component targets must fit inside it.

Lower RPO and RTO values generally cost more. More frequent recovery points use compute, bandwidth, storage operations, and operator attention. Faster recovery may require pre-provisioned infrastructure, replicated data, maintained automation, or people available outside office hours. A target without the resources to support it is only optimistic wording.

Estimate the business loss of an outage and compare it with the ongoing recovery cost. A two-hour delay for an internal analytics tool may be harmless. The same delay during checkout could be material. Right-sizing is not negligence; it is how a small team protects critical services without building an expensive disaster-recovery platform for every experiment.

Be precise about support hours. “Four-hour RTO” means something different if the recovery clock runs only during staffed hours. Write the assumption next to the target and make sure stakeholders understand it. Otherwise a Friday-night incident will reveal two incompatible interpretations.

Track the age of the newest usable recovery point. That single observation tells you more about RPO performance than a screenshot of a schedule. Alert when it approaches the agreed limit, including when a job never starts. Review sustained misses instead of normalizing them as harmless backup noise.

For RTO, run timed restore exercises. Separate access, provisioning, transfer, database recovery, service startup, and validation. The result may show that download speed is not the constraint at all. A missing secret, incompatible dependency, or approval bottleneck is often harder to solve during an outage.

Treat an objective as provisional until a test supports it. If the team promises four hours and the rehearsal takes seven, either improve the system or renegotiate the target. Quietly keeping the old number gives planning the appearance of certainty while leaving the operational risk unchanged.

Begin with three questions for each workload: what events create data that cannot be recreated, how much of that work can be lost, and how long can users wait for the service to return? Record the answers in plain language before converting them into time values.

Choose a backup interval with margin, monitor the newest successful recovery point externally, and test the complete restore. Start with the highest-impact system rather than trying to classify everything in one meeting. The second system will be easier because the team now understands what the terms mean in its own business.

Revisit the decision after incidents and major changes. RPO and RTO are not properties of a backup tool. They are business choices that a combination of storage, automation, architecture, documentation, and people must demonstrate over time.