Designing Backup and Disaster Recovery Around RPO and RTO

Most backup programs are judged on the day they are needed, and many fail that day for reasons visible long before: a job silently skipping a volume, a database copied mid-write, a restore that takes days over a link nobody measured, or backups encrypted by the same attacker who encrypted production.

This guide starts from those numbers, recovery point objective (RPO) and recovery time objective (RTO), and builds outward: how many copies to keep, how to make one survive ransomware, how to capture databases consistently, how often to prove restores work, how to write runbooks, and where the money goes.

Start with RPO and RTO for each system

RPO is how much data you can afford to lose, measured in time. An RPO of 24 hours means a nightly backup is acceptable. An RPO of 15 minutes means continuous log shipping, replication or very frequent snapshots. RTO is how long a system can be unavailable, measured from failure to users working again.

These numbers should come from the business owner of each system, not from IT alone, and they should be written down. Systems usually fall into a few tiers:

• Tier 1. Revenue and customer-facing systems such as order processing, payments and core databases. Typical targets: RPO of minutes, RTO of 1 to 4 hours.
• Tier 2. Internal systems people depend on daily, such as ERP, file shares, email and ticketing. Typical targets: RPO of 1 to 4 hours, RTO of 8 to 24 hours.
• Tier 3. Archives, reporting replicas, development and test environments. Typical targets: RPO of 24 hours, RTO of several days.
• Rebuildable. Stateless servers built from code or images. Back up the configuration and the build pipeline, not the servers themselves.

RTO includes everything: detecting the failure, deciding to recover, reaching the backup system, provisioning hardware, transferring data and validating the application.

The 3-2-1 rule and its modern extension

The classic 3-2-1 rule says to keep three copies of your data (production plus two backups), on two different storage systems or media, with one copy offsite.

Many teams now use 3-2-1-1-0: one copy is offline or immutable, and restores are verified with zero errors. The extra terms exist because ransomware operators look for and delete reachable backups before encrypting production. A backup an administrator account can delete is just another target.

In practice, "two media" today usually means two independent storage systems rather than disk and tape. A local backup appliance plus object storage in another facility qualifies. Two volumes on the same array do not, and a snapshot alone is not a backup, because it shares hardware and credentials with the data it protects.

Immutable and isolated copies against ransomware

An immutable copy cannot be modified or deleted until its retention period expires, even by an administrator. Common options are object storage with write-once retention locks in compliance mode, backup appliances with hardened retention, and media taken physically offline.

Immutability only helps if the surrounding controls match. Assume an attacker holds domain administrator rights in production and ask what they still cannot touch:

• Separate identity. The backup platform uses its own accounts, not the production directory, with multi-factor authentication on every administrative login.
• Locked retention. Retention locks that cannot be shortened after the fact, with any change to retention policy requiring two people.
• Network separation. Backup storage reachable only from backup servers, on a separate management network, with no inbound access from user networks.
• Retention depth. Enough history to reach back before the infection. Attackers often sit inside a network for weeks, so 30 to 90 days is a realistic floor for the immutable tier.
• Alerting on anomalies. Alerts for spikes in changed data, deleted backup sets and retention edits, often the first visible signs of an attack.

Plan the ransomware restore separately from the hardware restore. After ransomware you may need to restore into an isolated environment, scan the data, find the last known good point and rebuild credentials before reconnecting anything.

Database consistency: the part file backups get wrong

Copying the files of a running database usually produces a backup that looks complete and fails on restore, because pages were captured at different moments. Use methods the database understands.

• Native or hot backup tools. Use the database engine's supported online backup method, or a backup agent that integrates with it, so the copy is transactionally consistent.
• Log shipping for short RPO. Combine periodic full backups with continuous archiving of transaction logs. This allows point-in-time recovery, including stepping back to just before a bad deployment or malicious change.
• Application-consistent snapshots. If you rely on storage or VM snapshots, quiesce or freeze the database first (or use the engine's snapshot integration) so the snapshot captures a consistent state.
• Replication is not backup. A replica faithfully copies deletions, corruption and bad updates within seconds. Keep it for availability and short RTO, and keep separate backups for recoverability.

Measure database restore time, not just backup time. A restore often includes replaying hours of logs and rebuilding indexes, which can take several times longer than the backup. If a 4 TB database has a 2-hour RTO, confirm whether a restore can meet it or whether you also need a standby replica.

A 1 Gbps link at full load moves about 125 MB per second, or roughly 10 TB per day. In practice, protocol overhead, deduplication rehydration and storage read speed often hold sustained throughput to 50 to 80 percent of the line rate.

• Example. Restoring 20 TB over 1 Gbps at 70 percent efficiency takes about 2.9 days. Over 10 Gbps it takes about 7 hours, if the storage on both ends can keep up.
• Local copy first. A local backup tier near production serves most restores quickly; the offsite and immutable tiers serve disasters and attacks.
• Restore the critical subset. Design so the Tier 1 data can be restored first and on its own, rather than waiting for the full dataset.

A restore testing schedule that proves recoverability

A backup that has never been restored is an assumption. Scale testing effort with the tier:

• Daily. Automated checks of job status, and automated integrity verification of backup files where the platform supports it. Any failed or skipped job opens a ticket.
• Weekly. Restore a random sample of files and folders from different systems and compare them against checksums or the source.
• Monthly. Restore at least one Tier 1 database to an isolated environment, run a consistency check, and confirm the application can read it. Record the elapsed time.
• Quarterly. Restore a complete Tier 1 application stack, including dependencies, from the offsite or immutable tier. Compare actual recovery time with the RTO.
• Annually. Run a full disaster recovery exercise, including a ransomware scenario, with the people who would really be on call. Include the decision process, not only the technical steps.

Record each test: date, system, source copy, volume, elapsed time and problems found. When a test exceeds its RTO, treat it as an incident with an owner and a deadline.

Runbooks people can follow under pressure

Recoveries are usually run by whoever is available, at an inconvenient hour, under stress. Write runbooks for that person: specific, numbered and tested, naming commands, hostnames and expected outputs.

• Trigger and authority. What conditions start the recovery, who can declare a disaster, and who must be informed.
• Contacts. Owners, vendors and providers, with phone numbers that do not depend on email being up.
• Access. How to reach the backup platform and recovery environment if the primary directory, VPN or password manager is unavailable. Store emergency credentials in a sealed, audited break-glass process.
• Recovery order. The sequence of systems based on dependencies: network and DNS, identity, databases, then applications.
• Step-by-step procedures. Exact steps per system, with the expected time for each and how to verify success.
• Validation and handback. How the business owner confirms the system is usable and data is current enough, and how normal operations and backups resume.

Store runbooks somewhere that survives the disaster they describe: a printed copy, an offline encrypted copy, and a copy outside the production environment.

Cost trade-offs and how to make them

Every reduction in RPO or RTO costs money, and the curve is steep at the low end. Moving from a 24-hour RPO to 1 hour mainly costs more frequent jobs and log storage. Moving toward zero usually means continuous replication and a standby environment, roughly doubling infrastructure for those systems.

• Storage volume. Retention depth multiplies storage. Deduplication and compression help considerably for file and VM backups, less for already compressed or encrypted data.
• Immutable tier. Locked retention means you pay for the full period, even for data you would like to delete early. Size it deliberately.
• Egress and transfer. Some storage services charge for data read out or transferred, which makes large restores and frequent tests more expensive. Include restore costs in your estimate, not just storage.
• Standby compute. A warm standby meets short RTOs but costs close to a second production environment. A pilot-light design replicates data and provisions compute during recovery: cheaper, but slower.
• People and testing time. Restore tests and runbook upkeep take staff hours every month. Budget them, because without them the rest of the spend is unproven.

A simple decision rule: for each tier, compare the expected annual loss at the current targets with the annual cost of the design that meets tighter ones. If the improvement costs less than the loss it prevents, do it. If not, document the accepted risk and have the business owner sign off.

Backup and recovery checklist

• Each system: written RPO, RTO, tier and owner.
• Dependencies mapped; recovery order follows them.
• Three copies per in-scope system, on 2+ independent storage systems, one offsite.
• At least one immutable or offline copy, 30+ days for critical data.
• Backup admin uses separate MFA accounts. Retention changes need two people.
• Backups on an isolated network, unreachable from user LANs.
• Consistent, engine-aware database backups, plus log archiving where RPO is under a few hours.
• Restore throughput measured; the largest Tier 1 restore fits its RTO.
• Scheduled and logged: daily job checks, weekly file, monthly database, quarterly app restores, annual full test.
• Runbooks numbered, tested, offline, reviewed per test or big change.
• Alerts: failed jobs, deleted backups, retention edits, data change spikes.
• Costs: storage, transfer, standby compute, staff time. Owners sign off accepted risks.

Next steps

Start by filling in RPO, RTO and owner for your ten most important systems, then run one timed restore of the largest.

If you are building or moving backup targets, Vonahost provides dedicated servers with local NVMe or network block storage up to 1 PB in the region you choose, and its managed cloud includes backups. Every proposal states configuration, location, responsibilities and monthly price in US dollars, so it is clear which parts of the recovery plan you operate and which the provider does.