Verified backups: why testing your restores became non-negotiable in 2026
A backup that completes is not a backup that restores. Why cyber insurers now require tested restores, and how to prove it, without the jargon.
A backup you have never restored is not a backup. It is a hypothesis. And the day of an incident is not the moment to find out it was wrong.
In 2026, this is no longer just a best practice. It has become a contractual requirement: your insurers, your auditors and your clients all want proof that your backups actually restore.
”Backup completed” does not mean “data recoverable”
Every morning, your backup tool shows a green checkmark. Reassuring. Except that a backup that completes and a backup that restores are two different things. Between the two, plenty can have gone wrong, silently:
- a corrupted file that no one verified;
- an incomplete snapshot taken while the database was still writing;
- a lost encryption key that makes the copy unreadable;
- ransomware already present in the backed-up data;
- media (disk, tape, bucket) that became unreadable over time.
The job still “succeeds.” The problem only shows up at restore time, which is to say at the worst possible moment.
The numbers that sting
Industry studies in 2025 paint a harsh picture:
- Nearly 4 in 10 restores fail at the moment they are actually needed.
- Barely one third of organizations manage to get back up within hours, while two thirds are convinced they can.
- After a ransomware attack, only one organization in ten recovers more than 90% of its data.
The common thread behind these failures is almost never a missing backup. It is a missing test.
What changed in 2026: cyber insurance no longer takes your word for it
A few years ago, ticking “yes, we run backups” was enough to get a policy. Those days are over.
Insurers have moved tested backups from a recommendation to a condition of coverage, written in black and white into the contract. In practice, they now ask for:
- immutable backups, isolated from the production network;
- restore tests on a documented schedule;
- dated test results that prove data comes back, not just that the job finished.
And they check. At renewal and during a claim, the insurer compares your declarations to the reality of your systems. If the gap is too wide, they can reduce the payout, deny the claim, or even rescind the policy. An analysis of more than 10,000 policies found that the backup question had been answered incorrectly or incompletely in nearly 9 cases out of 10. That is a lot of potential denials on the day it matters.
In other words: in 2026, an untested backup is not only a technical risk. It can void your insurance.
The rule that sums it up: 3-2-1-1-0
The old 3-2-1 rule (3 copies, on 2 types of media, with 1 offsite) evolved to answer ransomware. Two numbers were added:
| Number | What it requires |
|---|---|
| 3 | Three copies of your data |
| 2 | On two different media types |
| 1 | With one kept offsite |
| +1 | One immutable or air-gapped copy that ransomware cannot encrypt or delete |
| +0 | Zero errors, proven by regular restore tests |
The last number, the 0, is the newest and the most demanding. It is not declared: it is proven. That is exactly what insurers now ask for.
Testing for real: three levels
Not all “tests” are equal. Here are the three levels, from weakest to strongest.
1. Per-machine monitoring. Knowing, for every VM, that an expected backup actually arrived, and being alerted immediately if one goes missing. This is the baseline: no more blind spots.
2. Integrity verification. Recomputing the checksums of each backup to catch corruption early, before you need it, not during the restore.
3. The real restore test. The only one that truly proves anything: restore a machine to an isolated environment and boot it. If the VM reaches its login screen, the proof is made. And the timestamped report it produces is precisely the document your insurer wants to see.
The first two levels are necessary. The third is the one that turns a hypothesis into certainty.
What it looks like in practice
This is exactly the logic behind our managed Proxmox backup. Your Proxmox Backup Server datastore is managed, encrypted and immutable (Object Lock), hosted in Canada. We monitor every backup per machine, we verify its integrity, and we can restore and boot your VMs on an isolated node to prove, console capture in hand, that they truly come back. Every test produces a dated report, the very one your cyber insurer asks for.
All of it in Canada, beyond the reach of the Cloud Act, and combinable with a disaster recovery plan if downtime costs you dearly.
Frequently asked questions
My backup job succeeds every night. Isn’t that enough? No. A job that completes proves that data was copied, not that it is recoverable. Only a tested restore proves that.
How often should I test? Most insurers expect monthly tests for critical data and quarterly for the rest, with dated results. Automatically scheduled tests remove the risk of forgetting.
What does an immutable backup change against ransomware? During the chosen window, the copy cannot be modified or deleted, even with stolen administrator credentials. You always keep a clean point to restart from.
Can a cyber insurer really refuse to pay? Yes. If your backups do not match what was declared, the insurer can reduce, deny or rescind. Test documentation is not paperwork: it is what protects your payout.
Do your backups actually restore? Explore managed Proxmox backup, monitored, verified and tested, or create your account to discuss it and get a price.