A Backup Nobody Has Restored Is a Hope

The Decision in Front of You

Every company with a server or a cloud account pays for backup. The decision for leadership is whether to keep paying for copies or to start paying for proof.

Proof means restoring real systems on a schedule, timing the work, and having someone outside IT confirm the data is right. Without it, the first real restore happens on the worst day of the year, in front of customers, regulators, and sometimes an attacker who has already been inside the backup system.

The money at stake is large. In a 2024 Sophos study of 2,974 organizations hit by ransomware, victims whose backups were compromised had a median total recovery cost of $3 million. Victims whose backups survived had a median of $375,000 ¹.

What's Happening

Confidence runs ahead of results

Veeam's Ransomware Trends Report 2025 surveyed 1,300 organizations, 900 of which had suffered an attack in the prior year. Only 10% of the attacked organizations recovered more than 90% of their data, and 57% recovered less than half ². Before they were hit, 69% believed they were prepared ². Almost every respondent (98%) had a ransomware playbook, but only 44% of those playbooks covered how and how often backups would be verified ².

The 2026 edition of Veeam's research, the Data Trust and Resilience Report, drew on more than 900 senior IT, security, and risk leaders. Ninety percent were confident they could recover from a cyber incident. Among ransomware victims whose operations or data were affected, 28% recovered all of it, and the average organization recovered 72% of affected data ³. Veeam links better outcomes to recovery proven through realistic testing ³. Veeam sells backup software, so treat these figures as directional.

Restore time is just as overstated. Unitrends' State of Backup and Recovery Report 2025, a survey of more than 3,000 IT professionals, found over 60% believed they could recover from downtime within hours, while only 35% had been able to do so ⁴. A quarter of organizations tested disaster recovery once a year or less ⁴.

Attackers go for the backups first

The same 2024 Sophos study found attackers tried to compromise backups in 94% of ransomware incidents, and succeeded in 57% of those attempts ¹. Exhibit 1 shows what changed when they did.

Sophos's 2025 survey of 3,400 victims found the share of organizations that recovered data from backups had fallen to its lowest level in six years ⁵. The federal guidance is blunt about why. CISA's #StopRansomware Guide notes that many ransomware variants search for reachable backups to delete or encrypt them, and tells organizations to keep offline, encrypted backups and to test their availability and integrity in a disaster recovery scenario ⁶.

Two recent cases

UniSuper and Google Cloud, May 2024. UniSuper, an Australian pension fund managing more than A$135 billion for over 647,000 members, lost its entire Google Cloud VMware Engine private cloud ⁷. Google's review found that operators had left one parameter blank when provisioning the environment in 2023. The system filled in a default one-year term and deleted the private cloud automatically when that term ran out, without notifying the customer ⁸. UniSuper had duplicated the environment across two geographies, and the deletion took out both ⁷. Members lost services for an extended period while teams rebuilt hundreds of virtual machines, databases, and applications ⁷⁸. Recovery depended on backups held with an additional service provider, which the joint statement credits with limiting data loss ⁷. The lesson for leadership: replication across regions protects against a regional failure, and only a separately held copy protects against the provider itself.

South Korea's national data center fire, September 2025. A battery fire at the National Information Resources Service data center in Daejeon burned 384 battery packs and took down 96 government systems, disrupting 647 networks ⁹¹⁰. Ninety-five of the 96 systems had backups. The exception was G-Drive, a shared storage system used across government, where about 858TB of files, reported as roughly eight years of work, were lost because the system was considered too large to back up ⁹¹⁰. About 17% of central government officials were affected ⁹. In early October, 115 of the 647 networks had been restored, and officials expected full recovery to take about a month ⁹¹⁰. The lesson: a backup program is only as good as its least protected system, and a decision to leave something out is a business decision that leadership should see in writing.

Why the Usual Approach Fails

Most backup programs are measured by the wrong number. The nightly report says jobs completed, which confirms that data reached storage. Whether a running application can be rebuilt from that data, whether the copy is clean, and how many hours the rebuild would take all go unmeasured.

Restores are hard to schedule. A realistic test needs spare compute, an isolated network, an engineer for a day, and a business user to check the records. None of those has a budget line, so the test slips.

Copies share fate with production. Backups that sit on the same network, under the same administrator accounts, in the same cloud tenancy, fail together with the system they protect. UniSuper's two geographies failed together for this reason ⁷.

Nobody owns the result. When backup belongs to infrastructure and the data belongs to a business unit, each side assumes the other has checked.

The 3-2-1 rule, described in a 2012 US-CERT paper, calls for three copies of important data on two different media types, with one copy stored offsite ¹¹. That guidance is more than five years old; CISA's current guidance adds offline copies kept out of attackers' reach ⁶. NIST SP 800-53 includes control enhancements for testing backups for reliability and integrity, CP-9(1), and for restoring a sample of backup information as part of contingency plan testing, CP-9(2) ¹². NIST SP 800-34 Rev. 1 (2010, still the current federal guide) expects contingency plan tests to include system recovery on an alternate platform from backup media, and for high-impact systems a full recovery and reconstitution to a known state ¹³. ISO/IEC 27001:2022 control A.8.13 expects backup copies to be tested regularly against a documented backup policy ¹⁴.

The Framework: The Restore Proof Loop

The Restore Proof Loop treats a restore test the way finance treats an audit sample. Each critical system is restored on a schedule, the result is checked by someone who knows the data, and the numbers go to leadership.

flowchart LR
    A[Inventory<br/>critical systems<br/>and owners] --> B[Isolate<br/>one immutable copy<br/>off production access]
    B --> C[Restore<br/>full system<br/>on a schedule]
    C --> D[Verify<br/>business owner<br/>checks the data]
    D --> E[Report<br/>pass rate and<br/>restore time]
    E --> A

Inventory. List the systems the business cannot run without, and name a business owner for each. Record anything deliberately left out of backup, with the reason and the owner's signature. G-Drive would have appeared on this list ⁹.

Isolate. Keep at least one copy that production administrators, service accounts, and AI agents cannot alter or delete (an immutable copy), held with a second provider, in locked storage, or offline. Restore tests should draw from this copy at least once a year, because it is the one the company will need after an attack.

Restore. Rebuild the whole system, including the application, its configuration, and its connections, on separate infrastructure. An application depends on a database, an identity service, and a network, and a single restored file tests none of them. Rotate through critical systems so each is restored at least twice a year.

Verify. A business user signs off that the restored records are complete and correct, for example by matching invoice totals or open orders against a known point in time. The engineer's check ends when the server boots; the owner's check covers whether the numbers reconcile.

Report. Each quarter, leadership sees four figures: the share of critical systems with a passed restore in the last six months, the median and longest restore times against the time the business has said it can tolerate, the oldest untested critical system, and the date of the last restore from the isolated copy.

Costs, Risks, and Tradeoffs

Restore testing has real costs, and it is the wrong level of effort for some organizations.

How to Act

Questions to Ask Your Team

1. When did we last restore our most important system from backup, end to end, and how long did it take?
2. Who outside IT confirmed the restored data was correct?
3. Which systems do we deliberately not back up, and who approved that?
4. If an attacker had our administrator credentials, which backup copies could they delete?
5. Do we hold a copy with a separate provider or in storage that nobody can alter?
6. How long would a full restore of our order or billing system take today, as measured in a test?
7. What failed in our last restore test, and is it fixed?

Closing

A backup that has never been restored is a hope, and the company is already paying for the copies. Spend a modest amount more to restore them on a schedule, have the business confirm the data, keep one copy out of reach of production, and put restore success and restore time in front of the CEO and CFO every quarter.