Backup & Cyber Recovery

Every other layer in this landscape tries to stop an attack. Backup and cyber recovery assumes one eventually gets through. When ransomware encrypts the files, a bad deploy wipes the database, or a data center floods, the question stops being "how do we keep them out" and becomes "how do we get back the data we just lost" — and the only honest answer is a copy the disaster didn't touch.

That copy has become a target in its own right. Modern ransomware crews know that an organization with good backups won't pay, so before they trigger encryption they hunt for the backup server and delete or encrypt it first. A backup that a domain admin — or an attacker who stole that admin's password — can quietly delete is not really a safety net. The whole discipline has shifted from "do we have a backup" to "do we have a backup an attacker can't destroy, and have we proven we can actually restore from it."

The problem it solves

Prevention is never perfect, and some failure modes have nothing to do with attackers at all: a fat-fingered DROP TABLE, a corrupted upgrade, a SaaS vendor's outage, hardware that simply dies. In every one of those cases the difference between an inconvenient afternoon and an existential event is whether a clean, recent, restorable copy of the data exists somewhere safe.

The naive version — a nightly copy to a second drive, or a sync to a cloud folder — fails exactly when it's needed most. Ransomware encrypts mapped drives and synced folders right along with the originals. A backup that lives on the same network, reachable with the same credentials, shares the fate of what it's backing up. Solving this well means copies that are isolated, tamper-proof, and regularly proven to work.

How it works

A backup platform takes point-in-time copies of workloads — virtual machines, databases, file shares, SaaS tenants, whole Kubernetes clusters — on a schedule, deduplicating and compressing them so keeping many restore points stays affordable. The security-relevant part is where and how those copies are stored.

Immutability is the foundation: backups are written to storage that refuses to modify or delete them for a set retention period, enforced below the application so that not even an administrator account can override it. Even if an attacker fully owns the backup console, the copies underneath survive. Air-gapped vaulting goes further, keeping an isolated copy in a separate, network-segmented or vendor-managed vault that ransomware spreading through the production network has no path to reach.

On top of storage, these platforms increasingly watch the backups themselves. Ransomware anomaly detection scans incoming data for the tell-tale signs of mass encryption — sudden spikes in change rate, files turning into high-entropy noise — both to raise an early alarm and to pinpoint the last recovery point taken before the infection, so recovery starts from clean data rather than re-introducing the malware.

The 3-2-1 rule (and its modern update)

The durable rule of thumb is 3-2-1: keep at least three copies of your data, on two different types of media, with one copy stored offsite. It predates ransomware and still holds — three copies survive two simultaneous failures, and the offsite copy survives a disaster that takes out the whole site.

Ransomware forced an update, often written as 3-2-1-1-0: the extra 1 is one copy kept offline or immutable — beyond the reach of a network-borne attacker — and the 0 is zero recovery errors, meaning restores are actually tested and verified rather than assumed. That trailing zero is the part most organizations skip, and it's the part that decides whether the rest of the rule was worth anything.

Backup is not recovery

Having backups and being able to recover are different claims, and confusing them is how organizations discover — mid-incident — that their backups don't restore, are missing a critical system, or would take a week to bring back. Two numbers frame the goal: RTO (Recovery Time Objective), how long you can afford to be down, and RPO (Recovery Point Objective), how much data, measured in time, you can afford to lose. A backup taken once a night gives a 24-hour RPO whether you wanted one or not.

Meeting those targets under real conditions is what separates a backup product from a recovery one. DR orchestration automates failover to standby infrastructure and, critically, tests the recovery on a schedule so the plan is known to work before it's needed. Cleanroom recovery restores workloads into an isolated, known-clean environment — useful both for testing without touching production and for rebuilding after a breach without dragging the attacker's foothold along with the data. An untested backup is a hypothesis; recovery is the experiment that confirms it.

Choosing one

Start from the workloads you actually have to protect. A shop running VMs and databases in its own data center has very different needs from a Kubernetes-native team, or from an organization whose crown jewels live in Microsoft 365 and Salesforce — and the tools specialize accordingly, from broad enterprise platforms to Kubernetes-native and SaaS-native options.

Then weigh where the immutability actually lives. Vendor-managed, air-gapped vaults offer the strongest isolation with the least effort; self-managed tools can be just as immutable but only if you configure the underlying storage — object-lock, append-only, retention policy — correctly, and the default is usually not it. Finally, insist on recovery testing as a feature, not an afterthought: the platform that makes it easy to regularly prove a restore works is worth more than the one with the longest feature list you'll never exercise until the worst possible day.