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

Back up often enough that the oldest data you might lose is acceptable to the people who depend on it. For many small teams, that does not automatically mean hourly backups—and it does not automatically mean nightly backups either. The right interval follows your recovery point objective (RPO), while the time needed to bring a working service back follows your recovery time objective (RTO).

Consider a five-person software company that runs one backup overnight because an old setup guide recommended it. At 16:00 on a busy Monday, a faulty import overwrites customer data. The latest usable backup is from midnight. The job may have completed correctly, but the team must now decide whether losing sixteen hours of changes is acceptable. In practice, the schedule made that business decision before anyone discussed it.

A documentation site, an order database, uploaded customer files, and a rebuildable cache can live on the same server while needing different recovery plans. Start by identifying the data and service outcome that matter, rather than applying one machine-wide interval by default. For a scope-first inventory, see [what to back up on a Linux server](/blog/what-to-back-up-linux-server).

The **recovery point objective (RPO)** is the maximum acceptable gap between the last usable recovery point and the incident. A four-hour RPO means the business accepts the possibility of recreating up to four hours of changes after a destructive event. It does not guarantee that exactly four hours will be lost; it is the limit the backup and recovery design should be able to meet.

Set RPO by discussing business events, not abstract minutes. Ask how many paid orders staff could reconstruct, whether support messages also exist in another system, whether users can provide an upload again, and whether content changes can be replayed from version control. Different answers commonly produce different RPOs for different components of the same application.

The operational measure is the age of the newest **usable** recovery point—not the age of the most recent scheduled start. A backup scheduled hourly can still miss a one-hour RPO when it fails, cannot read the selected source, writes an unusable database artifact, or completes without anyone noticing. A successful upload alone does not prove the application can be recovered; a restore test is separate evidence.

• For a customer-order database, the relevant change may be each completed order or payment event.
• For uploads, the relevant change may be each newly stored document, image, or export.
• For configuration, the relevant change may be a deployment, credential rotation, DNS update, or infrastructure change.
• For caches and derived assets, the appropriate decision may be to rebuild rather than back up.

The **recovery time objective (RTO)** is the maximum acceptable delay between an incident and restoration of the agreed service. It starts when the incident occurs or is recognized, according to the policy you set, and ends only when the service is usable for its intended purpose.

A realistic RTO includes detection, triage, access to recovery credentials, target provisioning, data transfer, database recovery, application startup, dependency configuration, and validation. It is not just the time shown by a restore command. Missing secrets, blocked storage permissions, an unavailable domain change, or an unpractised approval step can consume more time than downloading the backup.

A team can reasonably have a one-hour RPO and a twelve-hour RTO: it wants little data loss but can tolerate a working day to rebuild. The inverse can also occur, but it means the service returns quickly with potentially older data. Write both targets down so stakeholders see that trade-off before an incident.

RPO and RTO are related, but reducing one does not automatically reduce the other. Running backups more frequently may reduce the potential data-loss window, yet it does not create a ready recovery host, speed a large restore, or prove that the recovered application will start. Conversely, a standby environment can improve service restoration time while still needing backups for accidental deletion, corruption, and older recovery points.

Start with the shortest accepted data-loss window for the workload, then leave room for backup duration, delayed starts, retries, and failure detection. If a service can lose at most four hours of data, a job that starts every four hours and sometimes runs for ninety minutes has no practical margin. The next job may finish well beyond the stated objective even before a failure occurs.

A useful planning rule is to schedule more frequently than the RPO when practical, then verify the actual age of the newest usable point. The margin is not a substitute for monitoring. It is protection against ordinary variation such as a slow source disk, a delayed worker, an object-storage problem, or a backup that needs a retry.

Do not reduce every interval automatically. More runs can increase CPU, disk I/O, database load, storage operations, retention complexity, alert noise, and operator work. Frequent logical database dumps may be inappropriate for a busy workload. Where the business need is tighter than a safe dump schedule can meet, evaluate database-native point-in-time recovery, replication, or application-level mechanisms rather than treating increasingly frequent full backups as the only option.

• Daily or less frequent: often suitable for low-change internal tools, static content, or data that can be recreated with limited effort.
• Every few hours: often a practical starting point for important application data when some manual reconstruction is acceptable.
• Hourly or tighter: requires evidence that source consistency, job runtime, monitoring, storage capacity, and restore handling can sustain the cadence.
• Minutes or seconds: usually moves beyond ordinary backup scheduling into database logs, replication, standby capacity, and failover design.

Small teams do not need a bespoke disaster-recovery design for every directory. A small number of recovery tiers is usually enough to make priorities explicit. For each service or data set, record an owner, RPO, RTO, backup or recovery method, dependencies, and the test that proves the result is useful.

The owner should be able to judge whether the restored data is meaningful. That may be a product owner or application maintainer rather than the person who maintains the scheduler. Technical operators should translate the target into a feasible design, state its costs and limits, and capture evidence from recovery exercises.

Keep service dependencies in the same record. A database restored in two hours does not produce a two-hour service RTO if the application image, environment configuration, secrets, DNS, object storage, or external integrations take another day. Container definitions can recreate containers but not necessarily the state around them; [Docker Compose backup strategy](/blog/docker-compose-backup-strategy) explains how to map that state and recovery order.

• Tier 1: customer-facing transactions or irreplaceable records; short RPO, explicitly tested service RTO.
• Tier 2: important uploads and operational data; moderate RPO and same-day recovery target.
• Tier 3: source-controlled configuration, reports, caches, and derived data; longer RPO or a documented rebuild path.