Backups That Actually Restore: A Backup and Recovery Testing Playbook for Mid-Market Owners and Operators

Backups That Actually Restore: A Backup and Recovery Testing Playbook for Mid-Market Owners and Operators

2026-10-19

The takeaway: A backup is only as good as your last successful test restore. Decide how much downtime and data loss each system can take, keep at least one copy that no everyday admin login can reach, protect the backup system’s own logins, and test restores on a calendar. Do that, and ransomware becomes a bad week instead of a ransom negotiation.

Why “we have backups” isn’t an answer

Attackers know backups are your way out, so they go after them first. In a Sophos-commissioned survey of 2,974 IT and security professionals whose organizations were hit by ransomware (conducted by Vanson Bourne in January and February 2024, organizations of 100 to 5,000 employees across 14 countries), 94% said the attackers tried to compromise their backups, and 57% of those attempts succeeded (Sophos, 2024).

The newer data shows backups pay off when they survive. In Sophos’s 2026 survey of 2,158 decision-makers at hit organizations (fielded Q1 2026), backups were used to recover data in 66% of attacks where data was encrypted, up from 54% in the 2025 report (Sophos 2026). Sophos is a security vendor, but the government guidance below points the same way.

Step 1: Decide how much downtime and data loss you can live with

Two numbers drive every backup decision. NIST’s contingency planning guide defines them (NIST SP 800-34 Rev. 1, May 2010, updated November 11, 2010):

  • Recovery Time Objective (RTO): the longest a system can stay down before the damage becomes unacceptable.
  • Recovery Point Objective (RPO): the point in time you can restore data back to. In plain words, how much recent work you can afford to lose.

These are business calls, not IT calls. An ERP might need an RTO of four hours and an RPO of 15 minutes; an archive share might be fine at three days and one day. Set them for your top five systems and have each system’s owner sign off.

Step 2: Follow 3-2-1, then make one copy unreachable

The classic rule from a US-CERT paper still holds: keep 3 copies of important data, on 2 different types of media, with 1 copy offsite (US-CERT, Data Backup Options, 2012).

Ransomware added a fourth requirement. CISA’s #StopRansomware Guide (September 2023) says to maintain offline, encrypted backups of critical data, because many ransomware variants try to find and delete or encrypt any backups they can reach (CISA). NIST’s ransomware profile, updated June 2026, says backups should have a copy stored offline or in a way that keeps attackers out (NIST IR 8374 Rev. 1).

“Immutable” storage is the cloud version of offline: a copy that can’t be changed or deleted for a set period. CISA’s guide notes that some cloud providers offer it, but adds a caution. It doesn’t meet compliance criteria for certain regulations, and misconfiguring it can get expensive.

Step 3: Don’t assume your SaaS vendor has your back

Microsoft says it builds redundancy into Microsoft 365, and its own resiliency documentation also states that “most data loss results from customer actions” (Microsoft Learn). Think of a deleted mailbox, a bad sync, or a compromised admin account. That’s the risk you’re backing up against. List every SaaS system that holds data you can’t recreate (email, files, CRM, accounting), check what its built-in recovery covers and for how long, and decide where you need a separate backup.

Step 4: Guard the backup system like the bank vault it is

If the same admin account that runs your servers can also delete your backups, an attacker who steals that one password gets both. In Sophos’s 2026 survey, 79% of attacks started with an identity-based approach, meaning stolen or abused credentials (Sophos 2026). So:

  • Use separate admin accounts for the backup system, not your everyday domain admin.
  • Put phishing-resistant MFA on every backup console login.
  • Turn on alerts for deleted backup jobs and shortened retention settings.
  • Keep the immutable or offline copy out of reach of those accounts.

Step 5: Test restores on a calendar

CISA says to regularly test the availability and integrity of backups in a disaster recovery scenario. NIST’s ransomware profile adds that you should verify backups are intact before you rely on them. A cadence we recommend for mid-market teams:

  • Monthly: restore a few random files and a mailbox. Five minutes, real proof.
  • Quarterly: do a full restore of one critical system and time it against its RTO.
  • Yearly: run a full recovery exercise with leadership in the room.

Write down how long each restore actually took. If the quarterly test takes 30 hours and the RTO is 8, you’ve found the problem on a Tuesday instead of during an attack.

Step 6: Write the runbook and print it

When systems are encrypted, your wiki may be too. CISA says to keep a hard copy and an offline version of your incident response plan. NIST’s profile adds an up-to-date contact list covering law enforcement, legal counsel, and incident response help. Your runbook should say who declares a disaster, the order systems come back in, and who calls the insurer.

Five questions for your IT lead or MSP this week

  1. What are the RTO and RPO for our top five systems, and who signed off?
  2. Which backup copy can’t be deleted with any everyday admin login?
  3. When did we last do a full restore, and how long did it take?
  4. Are Microsoft 365 or Google Workspace and our CRM backed up separately?
  5. Where’s the printed runbook?

Where outside help fits

Setting recovery targets, checking what your MSP actually does, and running the first real restore test are part of Yellow Coop’s Secure work, alongside incident response plans and tabletop exercises (what we do), in fractional engagements of 1 to 4 days a week (how we engage). If nobody can tell you when your last full restore was, book a 20-minute call.

Internal links: What We Do, How We Engage, CIO vs CTO vs CISO, Track Record, Contact, Insights.

Sources