Backup and Disaster Recovery Plan: RPO, RTO and Testing

A backup and disaster recovery plan answers two questions every owner eventually faces: how much data can we lose, and how long can we be down? Most businesses have backups. Far fewer have written recovery targets, a copy ransomware cannot reach, and proof that a restore works.

This guide shows how to build that plan using federal guidance: RPO and RTO, the 3-2-1 and 3-2-1-1-0 rules, immutable copies, SaaS backup, restore testing and recovery site options. If you would rather have it designed, run and tested for you, our managed backup and disaster recovery service covers servers, endpoints, cloud workloads and SaaS data.

We also cover Arizona risks such as monsoon storms, extreme heat and planned power shutoffs.

Where this guidance comes from. This article draws on the CISA #StopRansomware Guide (September 2023), NIST SP 800-34 Rev. 1 on contingency planning, NIST SP 800-209 on storage security (October 2020), FEMA’s Ready.gov business continuity plan template, Microsoft and Google admin documentation, and National Weather Service Phoenix guidance. It also reflects our team’s field experience designing backups, running restore tests and helping organizations recover after ransomware and outages. Platform details are current as of October 2026.

What a backup and disaster recovery plan covers

Backup is copying data somewhere safe. Disaster recovery (DR) is the plan, infrastructure and practiced procedure for bringing systems back after a disruption. NIST SP 800-34 Rev. 1 lays out a seven-step contingency planning process that works for businesses of any size:

1. Write a contingency planning policy.
2. Conduct a business impact analysis (BIA) to prioritize critical systems.
3. Identify preventive controls, such as UPS power and redundancy.
4. Create recovery strategies, including backup methods and alternate sites.
5. Develop the contingency plan with step-by-step restore procedures.
6. Test, train and exercise the plan.
7. Maintain the plan as the business changes.

BCP vs DR: which one do you need?

Both. A business continuity plan (BCP) keeps the business operating during a disruption: who works where, how customers are served, which manual workarounds kick in. Disaster recovery is the IT piece: how systems and data come back. FEMA’s Ready.gov template reflects this, with sections for the BIA, continuity strategies, manual workarounds, testing and a data restoration plan for IT. Our crisis management and business continuity guide covers the business side in more depth.

RPO and RTO: setting recovery targets per system

NIST SP 800-34 Rev. 1 defines three numbers that drive every recovery decision:

• Maximum tolerable downtime (MTD): the total outage leadership will accept for a business process.
• Recovery time objective (RTO): the longest a system can stay unavailable before the impact becomes unacceptable. NIST notes it normally has to be shorter than the MTD.
• Recovery point objective (RPO): the point in time to which data can be recovered from the most recent backup. In practice, how much data you can afford to lose.

NIST SP 800-209 adds a practical rule: set an RPO for each data asset and design the backup technology to meet it. Rank systems honestly. Treating everything as top tier makes the plan unaffordable.

For example, a hypothetical accounting firm might give its practice-management database a 15-minute RPO and four-hour RTO, while its scanned archive tolerates a 24-hour RPO and three-day RTO. Those choices lead to very different backup designs and costs.

Backup types and RPO/RTO tiers

Use these as planning ranges, then confirm them with your own timed restore tests. Data volume, bandwidth and dependencies change real results.

Method	Typical RPO	Typical RTO	Best fit	Watch out for
Nightly backup to local storage	Up to 24 hours	Hours to a day	File shares, low-change systems	Same site and often same credentials as production
Frequent snapshots	Minutes to an hour	Minutes to hours	Virtual servers, databases	An attacker with admin rights can delete them
Offsite or cloud backup copy	Hours to a day	Hours to days	Site loss, theft, fire, flood	Large restores over the internet are slow
Immutable or air-gapped copy	Matches copy schedule	Hours to days	Ransomware, stolen credentials	Retention lock must outlast attacker dwell time
Image backup with cloud DR spin-up	Minutes to hours	Minutes to hours	Critical servers	Failover must be tested and failback planned
Replication to a hot or mirrored site	Near zero	Minutes	Very low tolerance for loss	Replicates encryption too, so it does not replace backups
Independent SaaS backup	Several times daily	Items fast, full tenant slower	Mail, OneDrive, SharePoint, Drive	Native recycle bins are not a backup

The 3-2-1 and 3-2-1-1-0 backup rules

The 3-2-1 rule is an industry rule of thumb, not a federal standard: three copies of your data, on two different media or storage types, with one copy offsite. It handles hardware failure and the loss of a building well.

Ransomware changed the threat, because attackers now look for the backups first. That is why many practitioners, including our team, design to 3-2-1-1-0, adding:

• 1 copy immutable or offline (air-gapped), so it cannot be altered or deleted during its retention window.
• 0 errors after restore verification, meaning someone has proven the data comes back.

Those two additions map directly to federal guidance. CISA says to keep offline, encrypted backups and regularly test their availability and integrity. NIST SP 800-209 recommends considering an air gap around recovery copies, using immutable storage such as retention locking, and testing restores against the RTO.

Immutable and offline backups against ransomware

The CISA #StopRansomware Guide states the problem plainly: many ransomware variants try to find and delete or encrypt accessible backups. If your backup console uses the same admin account as everything else, an attacker who steals that account owns your recovery too.

NIST SP 800-209 describes immutability as locking data after it is created so it cannot be altered or deleted. A ransomware-resistant design usually includes:

• An immutable copy (object or retention lock) or an offline copy that is disconnected.
• Separate backup credentials with multi-factor authentication, kept out of the production directory where practical.
• Encrypted backups, with keys stored where you can reach them during a disaster.
• Golden images of critical systems, which CISA recommends for fast rebuilds.
• Restores to an isolated staging environment first, as NIST SP 800-209 suggests.
• Retention long enough to reach a restore point from before the attacker arrived.

CISA’s guidance is to restore from offline, encrypted backups based on a prioritization of critical services, so that priority list must exist beforehand. Our ransomware recovery page explains why restoring a domain controller backed up during an intrusion can restore the intrusion, and our article on how Windows ransomware breaches happen shows how attackers reach backups.

Not sure your backups would survive an attack? We can review your setup, check for an immutable copy and run a test restore with documented results. Request a backup review online, or book a consultation online to talk it through first.

SaaS backup: Microsoft 365 and Google Workspace

Many owners assume the cloud backs itself up. Microsoft’s shared responsibility documentation says otherwise: for all cloud deployment types, you own your data and identities and are responsible for protecting them. The provider keeps the platform running.

Native tools help, but they have limits. As of October 2026:

• Microsoft Learn states deleted SharePoint sites are retained for 93 days, then permanently deleted.
• Google Workspace admin help says admins can restore deleted Drive files within 25 days after a user empties their trash.
• Google’s Vault FAQ answers “Is Vault a data backup or archive tool?” with “No.”

An independent SaaS backup closes predictable gaps: a departing employee deleting data, ransomware encrypting files that sync to OneDrive or Drive, an expired retention window, or a legal hold that outlasts native retention. Retention rules vary by industry, so confirm obligations with counsel. This is general information, not legal advice.

Disaster recovery site options: cloud DR, DRaaS and alternate sites

Backups protect data. A recovery site gives you somewhere to run systems when the primary location is gone. NIST SP 800-34 Rev. 1 describes the traditional options:

• Cold site: space, power and connectivity but no equipment. Lowest cost, longest setup.
• Warm site: partially equipped. Middle on cost and time.
• Hot site: fully equipped to take over quickly, at higher cost.
• Mirrored site: fully redundant with real-time mirroring. NIST calls it the most expensive choice.

For most small and midsize businesses, cloud DR and disaster recovery as a service (DRaaS) now fill the warm or hot role. Backups replicate to a provider’s cloud, and in a disaster your servers run there while users connect remotely. You pay for standby storage and failover compute instead of a second building.

Apply NIST’s location advice either way: the recovery site should be somewhere unlikely to be hit by the same hazard as your primary site. Also plan the failback, which is a second project that often gets forgotten.

Arizona risks your recovery plan should cover

Arizona businesses face physical risks that can take systems offline with no attacker involved:

• Monsoon storms. NWS Phoenix defines monsoon season as June 15 through September 30 and lists downburst winds, blowing dust, lightning and flash flooding as hazards.
• Extreme heat. NWS Phoenix calls heat the most deadly weather-related hazard in the United States. A failed air conditioner in a small server room can shut equipment down.
• Planned power shutoffs. In April 2026, APS announced a Public Safety Power Shutoff near Flagstaff to reduce wildfire risk and projected roughly 12 to 24 hours without power.

Practical steps include UPS units sized for a clean shutdown, a generator where justified, temperature alerts, equipment kept off the floor, and a copy stored outside your region. Our managed network and infrastructure service monitors UPS and environmental sensors alongside routers, switches and firewalls.

Restore testing: a backup and disaster recovery test checklist

NIST SP 800-209 recommends testing backups at least monthly for critical data, with end-to-end test restores into a sandbox when recovery speed matters. It warns that configuration drift or an attack can leave backups that cannot actually be used. NIST SP 800-34 Rev. 1 scales exercises by impact, from a tabletop for low-impact systems to a full-scale exercise with failover for high-impact systems.

Use this checklist for each test cycle:

• Confirm scope: which systems, which RPO and RTO targets, and who participates.
• Verify recent jobs completed and the immutable or offline copy is current and locked.
• Restore a file, a mailbox or SaaS item, and one full system to an isolated environment.
• Time the restore from declaration to working system and compare it with the RTO.
• Check the restored data date against the RPO and confirm the application works.
• Confirm dependencies: directory services, DNS, certificates and encryption keys.
• Test access to the plan, contacts and recovery credentials with the network assumed down.
• Run a tabletop on who declares a disaster, authorizes failover and contacts insurer and counsel.
• Rehearse failback for at least one system.
• Document failures and fixes, assign owners and update the plan.

Tests that always pass are usually scoped to pass. The failures are the useful output, and the written result is what an insurer or auditor will ask for. Our free ransomware readiness scorecard shows where your recovery position stands before a full test.

How to choose a managed backup and DR provider

Pricing varies widely, so focus on cost drivers: protected data volume, servers and endpoints, SaaS seats, retention length, RPO and RTO targets, cloud DR standby and failover compute, and test frequency. Then ask:

• Is there an immutable or offline copy, and who can delete it?
• Are backup credentials separate from production and protected with MFA?
• Will we receive documented restore test results?
• What are the agreed RTO and RPO per system, and has a failover been timed?
• Is Microsoft 365 or Google Workspace data backed up independently?
• Who coordinates recovery and evidence preservation if ransomware is involved?

Restoring fast can destroy evidence needed for insurance or notification decisions. Our CEO’s guide to ransomware and recovery covers how leadership should weigh speed against investigation.

How Honeybadger Solutions helps with backup and disaster recovery

Honeybadger Solutions is a veteran-owned, veteran-led firm based in Casa Grande, Arizona, delivering cyber and IT services nationwide. Our backup and disaster recovery service designs to the 3-2-1-1-0 standard, with immutable and air-gapped copies, managed backup for servers, endpoints, cloud workloads and SaaS data, daily monitoring with automated restore verification, and recovery planning with RTO and RPO set per system. Contingency planning follows NIST SP 800-34.

We run scheduled failover tests with documented results, perform file, mailbox, database and bare-metal restores, handle failover to cloud and plan the failback. After ransomware, we recover to a clean restore point validated before reconnection. Backup sits inside our managed IT services, so monitoring, patching and recovery are handled by one team.

Request backup and disaster recovery service online and we will scope a backup review or recovery plan, or book a consultation online to talk through your RPO and RTO targets.

Why the online intake is faster than a phone call: it takes about two minutes, and your answers are routed straight to the specialist team that handles your kind of matter, whether that is cyber and forensics, investigations or field security. That team sees the full picture before it replies, so you skip phone tag and get a real answer and next steps sooner. If it cannot wait for business hours, use the urgent intake form, which is read seven days a week.

Frequently asked questions

What is the difference between backup and disaster recovery?

A backup is a copy of data. Disaster recovery is the tested process for bringing systems and data back into service within a set time after a disruption. You can have backups without a recovery plan, but not a working recovery plan without reliable backups.

What are RPO and RTO in plain terms?

Recovery point objective (RPO) is how much data you can afford to lose, measured in time. Recovery time objective (RTO) is how long a system can stay down before the impact becomes unacceptable. Each system should get its own targets.

Is the 3-2-1 backup rule still enough against ransomware?

Usually not by itself. Ransomware operators often go after reachable backups first. The 3-2-1-1-0 variation adds one immutable or offline copy and zero errors on restore testing, which lines up with CISA’s advice to keep offline, encrypted backups and test them.

Do I need to back up Microsoft 365 or Google Workspace?

In most cases, yes. The provider runs the platform, but you remain responsible for your data and identities. Native recovery windows are limited, and Google states that Vault is not designed to be a backup tool.

How often should we test our disaster recovery plan?

NIST SP 800-209 recommends testing backups at least monthly for critical data. Run small restore tests often and a documented recovery or failover exercise at least once a year, plus after major changes.

Should a small business use DRaaS or a cloud DR site?

It depends on your recovery targets and budget. DRaaS can give a small business a warm or hot recovery option without a second facility, but you still need defined RTO and RPO, tested failover and a failback plan.

Related reading

• ▸ PCI DSS 4.0 Compliance for Small Business: SAQs and Checklist
• ▸ Cyber Insurance Requirements: Controls Underwriters Check
• ▸ Phishing-Resistant MFA: A Business Guide to Stopping MFA Bypass
• ▸ Penetration Testing Cost: What Drives Price and Scope