Ransomware Defense: The Backup Strategy That Actually Works (3-2-1 and Beyond)

The complete home cybersecurity lab guide covers snapshot discipline for the lab itself — snapshot before every destructive experiment, keep configuration backed up outside the lab. That’s the right habit for a lab where you’re deliberately breaking things. It’s a smaller, easier version of a problem that matters a lot more once you’re talking about the rest of your data: photos, documents, everything that isn’t disposable. Ransomware is what makes that problem genuinely hard, and most backup advice was written before ransomware was the thing it’s actually defending against.

Why Ransomware Changes the Backup Calculus

Traditional backup thinking is built around hardware failure and human error — a drive dies, someone deletes the wrong folder, a laptop gets stolen. All of those are solved by having a copy somewhere else. Ransomware is a different threat model entirely: it’s an active adversary that, once it has a foothold on your network, specifically goes looking for anything that looks like a backup and encrypts or deletes it too. A backup drive that’s permanently plugged in and mapped as a network share isn’t a backup in any meaningful sense once ransomware is loose on the network — it’s just another encryption target with a slightly different drive letter.

This is the part most consumer backup advice quietly skips. “Back up your files” is true but incomplete. The actual question is whether your backup is reachable by the same compromise that would take out your primary data, and for a lot of common setups, the honest answer is yes.

The 3-2-1 Rule, and Where It Falls Short Against Ransomware

3-2-1 is still the right starting framework: 3 copies of your data, on 2 different types of media, with 1 copy offsite. It’s necessary. It’s not sufficient against a threat that’s specifically trying to reach and destroy every copy it can find. The rule doesn’t say anything about whether those copies are reachable from a compromised machine, and for most home setups, at least one of them is — the NAS on the same network, the external drive that’s always connected, the cloud sync folder that mirrors changes (including malicious encryption) in near-real time.

The fix isn’t a different rule, it’s an addition to this one: at least one of your copies needs to be genuinely unreachable from your compromised state — either physically disconnected (true air-gap) or logically immutable (the backup system itself won’t let anything, including a compromised admin account, delete or overwrite old versions within a retention window).

What Actually Stops Ransomware From Destroying Your Backups Too

Immutable, versioned cloud backup. Services built specifically for this (not generic cloud sync, which happily syncs encrypted garbage right over your good files) keep every version of a file for a defined retention window, and the retention itself isn’t something a compromised client can delete early. This is the single highest-value piece of the setup and the one most people skip because generic sync (Dropbox, Google Drive, OneDrive) already feels like “a backup.”

A genuinely offline copy, rotated periodically. An external drive that’s connected only during the backup itself and disconnected immediately after is unreachable by definition the rest of the time. This is the least convenient piece and the one most likely to lapse from good intentions into “I’ll get to it,” which is exactly why it needs to be a scheduled habit, not a someday task.

A backup account with no delete permission on the backup target, separate from your daily-use admin account. If ransomware compromises your normal login, it inherits whatever permissions that login has. A backup job that authenticates with a separate, restricted account — write and append only, no delete, no permission changes — means even a fully compromised primary account can’t reach back and destroy the backup history.

The Restore Test Nobody Actually Does

A backup you’ve never restored from is a theory, not a backup. I mean this literally — the actual test isn’t “does the backup job complete without an error,” it’s “can I take this backup and get a working file back from it, right now, today.” Backup jobs fail silently in ways that don’t show up as an error: a misconfigured exclusion pattern that’s been skipping your documents folder for eight months, a corrupted archive that only reveals itself on extraction, permissions that quietly broke after an OS update. None of these show up in a green checkmark. All of them show up the first time you actually need the restore and it doesn’t work.

Pick one file at random, quarterly, and actually restore it from your backup to a different location. It’s a five-minute habit that catches problems while they’re still an inconvenience instead of a disaster.

What I Actually Run

A NAS on the home network with versioned snapshots (not a delete-friendly share, immutable snapshots that even an admin login can’t casually wipe out), an immutable cloud backup service as the true offsite copy with a 90-day+ version retention window, and a rotated external drive that gets connected, updated, and disconnected on a monthly schedule rather than living plugged in. The cloud service is the one doing the actual ransomware-resistance work — it’s reachable from anywhere but not deletable from a compromised endpoint within the retention window, which is exactly the property I actually need.

What I Got Wrong

For longer than I want to admit, my “backup” was a NAS share mapped as a network drive on my primary machine, which is precisely the setup this whole article argues against — reachable, writable, and would have been just as encrypted as everything else in a real ransomware event. I found this out not through an actual ransomware incident, thankfully, but through a genuinely dumb self-inflicted one: a scripting mistake during a completely unrelated project wrote garbage over a folder faster than I noticed, and the NAS share happily mirrored the damage in real time because that’s exactly what a mapped share does. The data was recoverable from an older cloud version, which is the only reason this is a “lesson learned” story and not a “here’s what I lost” one.

The other thing I underestimated: how much friction the offline rotated drive would actually have in practice. The cloud and NAS pieces run themselves once configured. The offline drive requires me to actually do something monthly, and the honest failure mode of any backup step that requires a human action on a schedule is that the human eventually stops doing it. I ended up setting a recurring calendar reminder specifically because “I’ll just remember” turned out to be false almost immediately.

Common Mistakes

Treating cloud sync as a backup. Sync mirrors changes, including bad ones, in near-real time. That’s a collaboration tool, not ransomware protection, unless the specific service also does immutable versioning underneath the sync.

No offline or immutable copy at all. If every copy of your data is reachable and writable from your normal login, you have redundancy against hardware failure and nothing against an active adversary.

Never testing a restore. Covered above, worth repeating because it’s the single most common gap: a backup system that’s never been tested is a hope, not a plan.

Sources:

1. CISA, ransomware protection and response guidance
2. NIST Special Publication 800-34, contingency planning guide
3. 3-2-1 backup rule, general industry best practice origin (US-CERT)