Building a Backup Strategy Around RPO and RTO

Backup is a business decision before it is a technical one

Most backup programs are built backwards. A tool gets bought, a schedule gets set, and jobs run green for years — until a restore is needed and nobody can say how much data will be lost or how long recovery will take. A defensible strategy starts from two commitments the business makes per workload, then engineers backwards to meet them. Those commitments are the Recovery Point Objective and the Recovery Time Objective. Everything else — copy count, media, immutability, test cadence — exists to satisfy them.

• RPO — Recovery Point Objective. The maximum data loss you accept, measured in time. An RPO of 15 minutes means that after a failure you can lose up to the last 15 minutes of work. RPO is set by backup or replication frequency: nightly backups give you an RPO of up to 24 hours; continuous replication pushes it toward zero.
• RTO — Recovery Time Objective. The maximum downtime before the workload is usable again. An RTO of two hours means you must be running within two hours of declaring an incident. RTO is set by how fast you can retrieve data, rebuild or reattach systems, and validate the application.

RPO looks backward at data loss; RTO looks forward at downtime. Write both down for each workload before you design anything, because they dictate the architecture and the cost.

RPO and RTO belong to workloads, not the whole company

The most expensive mistake in backup design is applying one target to everything. Protection cost climbs steeply as both numbers approach zero, so a single aggressive RPO/RTO across the estate means paying premium prices to protect a print server. Tier your workloads instead and buy each the cheapest protection that meets its targets.

A practical three-tier model:

1. Tier 1 — mission-critical. Order entry, the primary database, the ERP, customer-facing services. Target an RPO of minutes and an RTO under a few hours. These justify replication, frequent immutable snapshots, and standby capacity.
2. Tier 2 — important. Internal line-of-business apps, file shares, collaboration tools. An RPO of a few hours and an RTO of a business day is usually acceptable. Frequent backups without full hot standby.
3. Tier 3 — routine. Dev/test, static archives, low-change systems. A 24-hour RPO and a multi-day RTO is fine. Daily backup to inexpensive storage.

Set these numbers with the business owners of each system, not just IT. The finance team, not the backup admin, should decide how many hours of transactions the company can afford to re-key. Once agreed, RPO and RTO become measurable requirements you can test against.

The 3-2-1-1-0 rule

The old 3-2-1 rule — three copies, on two media types, one offsite — predates ransomware and cloud. The modern version adds two critical digits:

• 3 copies of the data (production plus two backups).
• 2 different media or storage types, so one class of failure cannot take both.
• 1 copy offsite, geographically separated from production.
• 1 copy immutable or air-gapped — unreachable and unchangeable by an attacker who owns your network.
• 0 errors, verified by regular restore testing. A backup you have not restored does not count.

The final two digits are what separate a strategy from a hope. The extra "1" answers ransomware; the "0" answers the far more common problem of backups that were quietly broken long before anyone needed them.

Immutable and air-gapped: the copy ransomware cannot destroy

Ransomware crews hunt backups first. They know that if they encrypt or delete your recovery copies, negotiation leverage collapses and payment becomes likely. Online backups reachable with ordinary domain credentials get destroyed alongside production — so the restore data you were counting on disappears at the worst moment.

Immutability defeats this. An immutable backup is written once and cannot be altered or deleted for a defined retention window — not by an administrator, not by stolen credentials, not by the ransomware process itself. Object-lock storage and purpose-built immutable appliances both provide it. Air-gapping — a copy physically or logically disconnected from the network — achieves the same guarantee by removing the path entirely.

Design the immutable copy deliberately:

• Isolate backup credentials from production identity. Backup systems must not authenticate against the same directory that a domain compromise would own. Use separate accounts, separate MFA, and separate administrative planes.
• Set retention longer than attacker dwell time. Human-operated ransomware often lingers for weeks before detonating. If immutable retention is only seven days, a clean pre-intrusion restore point may already be gone. Thirty days or more of immutable retention for tier-1 data is a reasonable floor.
• Protect the backup infrastructure like tier-0. Segment it, restrict who can change retention policy, and alert on any attempt to shorten or disable it.

This is the core of resilient managed backup and disaster recovery: copies you cannot accidentally trust away, held long enough to matter.

An untested backup is a liability, not an asset

The "0" in 3-2-1-1-0 exists because untested backups fail in predictable, avoidable ways. Teams discover during a live incident that:

• A backup job silently failed weeks ago and the alert went to a mailbox nobody reads.
• The restore runs, but at a quarter of the assumed speed — turning a claimed two-hour RTO into a ten-hour outage.
• A dependency the runbook omitted (a certificate, a license server, an authentication service) blocks the whole recovery sequence.
• The backups are intact but the encryption keys, or the credentials to reach the backup system, live only on an encrypted production server.

None of these show up on a green dashboard. They surface only when you attempt a real restore. Testing is the only mechanism that converts an assumed RTO into a proven one and an assumed RPO into a measured one. Verified recovery is also where backup meets business continuity — the broader discipline of keeping people, communications, and priorities running while technical restoration proceeds.

A restore-testing cadence you can actually keep

Testing fails when it is heroic and rare. Make it routine and scoped:

1. Quarterly full-system restores for tier-1 workloads. Recover the whole application to an isolated environment, not a single file. A single-file restore proves the backup exists; a full-system restore proves you can run.
2. Semi-annual restores for tier-2, and an annual sample for tier-3. Match the effort to the workload's importance.
3. Time every drill end to end and compare against the documented RTO. If reality exceeds the objective, the objective is fiction until you close the gap.
4. Rotate responders. Recovery cannot depend on one person who happens to be reachable. Different team members should be able to execute the runbook cold.
5. Test after every significant change — a new application, a migration, a platform upgrade — because that is when silent breakage is introduced.
6. Track findings like incidents. Every drill surfaces gaps; log them and close them on a deadline.

For server-heavy estates, this discipline pairs naturally with server infrastructure management, where patching, monitoring, and backup verification are run as one operational routine rather than disconnected tasks.

The blind spot: your SaaS data in Microsoft 365 and Google

The single most common gap we find is the assumption that SaaS providers back up your data for you. They do not, in the sense you need. Microsoft 365 and Google Workspace operate a shared-responsibility model: they guarantee platform availability, but the data — mail, files, Teams and Chat history, SharePoint sites — is your responsibility. Their native retention and recycle bins are short-window safety nets, not backups. A deleted mailbox, a compromised account that purges files, a malicious insider, or a retention policy misconfiguration can permanently destroy data the provider will not restore.

Treat SaaS with the same RPO/RTO discipline as everything else:

• Back up Microsoft 365 — Exchange Online, OneDrive, SharePoint, and Teams — to independent storage with its own retention, ideally immutable.
• Back up Google Workspace — Gmail, Drive, Shared Drives, and Calendar — likewise.
• Set real objectives. Native "retention" typically means 30 to 93 days of soft deletion. If your RPO for email is one day and your compliance retention is seven years, native tooling does not meet either target.
• Keep the backup outside the same identity boundary. A tenant-wide account compromise should not be able to reach and delete the backups.

For most organizations, the majority of day-to-day work now lives in these platforms, which makes them a primary backup target, not an afterthought.

Start with the numbers, prove them with a restore

A backup strategy is not a product you install once. It is an RPO and an RTO per workload, satisfied by the 3-2-1-1-0 rule, hardened with immutable copies, extended to your SaaS platforms, and proven by restores you actually run. If you cannot state your recovery objectives today, or you have never completed a full-system restore drill, that is exactly where the risk lives. intSignal designs, operates, and tests backup and recovery for organizations that cannot afford to guess — mapping each workload to the right protection and proving it holds under pressure. Talk to our team to set defensible RPO and RTO targets and test the restores before you need them.