> ## Content Index > Fetch the complete content index at: https://www.praxiscto.com/llms.txt > Use this file to discover other available public pages before exploring further. # What Your Backups Were Built to Survive Isn't What's Coming for Them - URL: https://www.praxiscto.com/cyber-recovery-which-backup-can-you-trust/ - Published: 2026-10-06T12:00:37.000Z - Updated: 2026-10-08T03:44:54.000Z - Description: Most backup plans assume the worst case is hardware failure, not a hidden adversary. Cyber recovery assumes the attacker's already inside — here's what that changes. - Author: Matt Shirel - Tags: Security ## The Assumption That Changed Traditional backup strategy is built on a specific, mostly reasonable assumption: something will eventually fail — a disk, a data center, a person who deletes the wrong folder — and when it does, the fix is to restore from the most recent good backup. The backup is a static object that's always trustworthy, and the only real question is how recent it is. Ransomware broke that assumption in a specific way. A sophisticated attacker doesn't just encrypt a company's production data — they look for the backups too, and if the backups are [reachable from the compromised network](https://www.praxiscto.com/the-trusted-office-fallacy-why-every-user-network-should-be-treated-as-untrusted/), they get encrypted, deleted, or corrupted right alongside everything else. A company that assumed "we have backups" as their ransomware recovery plan frequently discovers, during the actual incident, that the backups were part of the blast radius the whole time. Cyber recovery is the set of practices and assumptions that starts from this reality instead of discovering it during an incident. ## What "Recoverable" Actually Requires Now **Immutability.** A backup that can be modified or deleted by anyone with sufficient network access — including an attacker who's compromised an administrator account — isn't a real safety net against ransomware. Immutable backups are written in a way that makes them genuinely unmodifiable and undeletable for a defined retention window, even by someone with legitimate admin credentials. It's the requirement vendors lead with, and a necessary one, but it only guarantees a copy hasn't changed since it was written, not that it was clean when it was written. The question worth asking directly: can anyone, including a compromised administrator account, delete or modify our backups before the retention window expires? **Isolation.** A backup system sitting on the same network as production, reachable the same way production is reachable, inherits production's attack surface. Real isolation — an "air gap" in spirit if not always in literal physical terms — means the backup environment isn't reachable through the same compromised credentials or network path that got an attacker into production in the first place. Cloud-based immutable object storage with separate access controls is one common way to achieve this without physical tape; the point isn't the specific technology, it's whether a single compromised credential can reach both production and its backups. **Recovery testing against an assumed-compromised environment.** Traditional restore testing answers "does this backup restore correctly." Cyber recovery testing answers a harder question: can we restore into a clean environment fast enough to matter, without accidentally restoring the attacker's persistence mechanisms right along with the data. A backup that faithfully restores a server exactly as it was an hour before detection may also faithfully restore whatever backdoor the attacker planted a month before that. This is why cyber recovery increasingly involves clean-room recovery environments and deliberate, staged restoration — rebuild the environment first, then selectively restore data into it, rather than restoring everything and hoping the malware didn't come along for the ride. ## The Timeline Problem ![Timeline: backups taken after an attacker gets in may already be compromised.](https://storage.ghost.io/c/eb/09/eb09d71a-7468-4462-94d3-73cc9c2df39d/content/images/2026/10/blog-42-cyber-recovery-x-1200x675-v3.png) Every backup taken between intrusion and detection may carry the attacker with it. Traditional disaster recovery plans are usually built around a hardware-failure timeline: something breaks, you notice within minutes or hours, and you restore from a backup that's at most a day old. Ransomware and other sophisticated attacks break that timeline too. The time between an attacker gaining initial access and an organization detecting the breach is frequently measured in weeks to months, not hours — meaning by the time an incident is discovered, the "most recent good backup" the team instinctively reaches for may already be compromised, because the attacker was already inside the environment when that backup was taken. This is why cyber recovery planning has to account for a longer, fuzzier recovery point objective than traditional disaster recovery does. The real question isn't just "how recent is our backup" — it's "how far back would we need to go to be confident we're restoring from before the attacker got in," and most companies haven't actually worked out an answer to that question before they need one. ## The Trust Problem Immutability and isolation answer one question: will the backups still exist after an attack? They don't answer the harder one: which of them can be trusted. An immutable backup preserves whatever was on the system when it was written, so a copy taken after the attacker got in is preserved just as faithfully as a clean one. If nobody knows exactly when the breach started, nobody knows which copies are clean. Traditional recovery never had to ask that. A failed disk doesn't leave anything behind in the copies taken before it failed, so the newest backup was the best one. In cyber recovery the newest backup is the one most likely to have the attacker in it, and choosing a restore point becomes a decision based on evidence rather than on the calendar: - **Let the investigation set the restore point.** Forensics work out when the attacker actually got in. That date decides how far back to go, not whichever backup happens to be newest. - **Look for the attacker in the backups themselves.** Scan restore points for known malware and signs of compromise, and watch backup activity for anomalies, such as a sudden spike in changed or encrypted-looking data, which can show roughly when things went wrong. - **Rebuild the systems; restore only the data.** Bring servers back from known-good images rather than from backup, then restore only business data into them. That way the backups never have to be trusted to contain clean programs and settings. - **Treat identity as compromised until proven otherwise.** Restoring the systems that control logins and permissions (such as Active Directory) can restore the attacker's access along with them, so those are rebuilt and every password and key is reset, not restored. - **Decide in advance who chooses between data loss and confidence.** Going further back is safer but loses more recent data. That's a business decision, and it goes better when leadership has agreed in advance who makes it and on what basis than when it's improvised in the middle of an incident. Traditional backup built trust by keeping the newest copy within reach. Cyber recovery has to build it with evidence: proof that a restored system is clean, rather than an assumption that it is because it came from a backup. ## The Objection Worth Taking Seriously The strongest version of the objection is that this is already solved: most backup platforms sold in the past several years ship immutability and geographically separated replication as built-in options, not custom engineering, so a company running a modern platform already has what this piece describes. That's a fair point about the technology, and it's beside the point about the company. A feature existing in a product and a feature being turned on, correctly scoped, and tested against this specific threat model are three different claims, and the gap between them is exactly where most companies currently sit. That gap exists because the person who originally selected the platform was usually optimizing for migration speed or storage cost, not for defending a retention-window setting during an incident two years later. A vendor's product page listing "immutable backup" as a checkbox is not evidence that any particular company has it configured, and it is not evidence that whoever configured it chose a retention window long enough to outlast the time an attacker typically spends inside an environment before being noticed. ## This Isn't Really About Backup The specific mechanism here — immutability, isolation, clean-room testing — is backup-specific, but the pattern underneath it isn't. Any recovery plan built to answer a cooperative failure mode quietly stops working the moment the failure mode includes an adversary, and backup is simply the plan most companies wrote down first. A disaster-recovery runbook built for a data-center outage assumes the problem ends once the fire is out; it doesn't assume the fire was set by someone still standing in the parking lot with a lit match. An incident-response plan that assumes the attacker leaves once the breach is contained is making the same unexamined bet backup makes about its own copies — that the adversary's presence ends where the plan's assumptions end, rather than where the adversary decides it does. None of these plans were written carelessly; they were accurate against hardware failure and human error, the realistic worst case for most of the time they were written. The question worth asking about any of them is the one this piece asks about backup specifically: does its definition of "recovered" survive contact with an adversary who read the plan too? ## What This Doesn't Mean This isn't an argument that every company needs to rip out its existing backup infrastructure and start over, and it isn't an argument that [traditional backup practices](https://www.praxiscto.com/where-did-the-backup-admin-jobs-go/) were wrong for the threats they were designed around. Hardware failure, accidental deletion, and site-level disasters are still real risks that traditional backup handles well. It's an argument that "we have backups" and "we have a tested cyber recovery capability" are two different claims, and a lot of companies are currently operating as if the first one implies the second. The gap between them usually isn't visible until an actual incident, which is exactly the wrong time to discover it. ## The Practical Starting Point A company doesn't need to solve this all at once. The useful first step is a specific, answerable question: if a ransomware attacker had full administrative access to our network for a month before we noticed, would our backups from that period still be usable, and how would we know without an actual incident to find out? If the honest answer is "we're not sure," that's not an unusual place to be — it's the norm, not the exception, because most backup strategies were designed and never revisited against this specific threat model. It's also exactly the kind of gap a focused review can surface and prioritize, without requiring a full infrastructure rebuild to start closing it. --- [*Subscribe*](#/portal/signup) *for more like this.* --- *This article was drafted with AI assistance and reviewed and edited by Matt before publishing.* **About the Author:** Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. Backup and recovery architecture, including the shift toward cyber-recovery-specific practices, has been a recurring part of his infrastructure work across two decades.