Ransomware-Safe Backups: Beyond 3-2-1 to 3-2-1-1-0

The Ransomware Backup Problem

You're running Synology NAS with automatic cloud backup enabled. One afternoon, ransomware slips into your network. By the time you notice—encrypted file extensions, ransom note, 30-day countdown—your primary NAS is destroyed. You feel safe. You have cloud backup.

You check the cloud. It's encrypted too.

This happens because most automated cloud sync is bidirectional or push-on-change. Your NAS continuously uploads to the cloud service. When ransomware encrypts files locally, those encrypted files are immediately synced to the cloud. Your backup becomes a perfect copy of your encrypted data.

Even worse: the ransomware often deletes file versions in the cloud service, or uses its credentials to disable backup entirely. By the time you recover, the only unencrypted copies are older snapshots that you hope the service retained.

The Cloud Sync Fallacy

Cloud backup services market themselves as "continuous protection." It's the opposite of what you need during a ransomware attack. Continuous sync means continuous exposure.

A data hoarder managing 100+ TB can't rely on cloud services to maintain immutable snapshots. Even services that do offer immutable snapshots often allow the primary account to delete them, or they cost 3–4× more than the baseline service.

The only backup that survives ransomware is one that is air-gapped, immutable, and unidirectional. No continuous sync. No delete capability from the primary system. Just a copy that lives alone.

Air-Gapped Backup: Isolation by Design

Air-gapped means disconnected. Your backup lives on a drive or NAS that is not connected to your primary network. It doesn't have network access to your production systems. It doesn't have network-accessible credentials. Ransomware can't reach it.

For most data hoarders, true air-gap is impractical (you need occasional restore access), so the real-world approach is air-gapped-by-default: The backup drive stays disconnected 99% of the time. You only connect it:

• Once a week for a scheduled backup job
• Immediately after connecting, the backup runs and then disconnects
• The drive spends the rest of the week offline, untouchable

Even if ransomware is active on your primary systems, it can't touch the backup because the backup isn't there. Ransomware operates in real-time (encrypting files as they exist), not retroactively (going back weeks to destroy old snapshots).

Immutable Snapshots: Write-Once Data

Immutability means once data is written, it can't be modified or deleted. On a filesystem level, this requires:

• Write-once media: Optical discs (M-Disc), magnetic tape, or WORM (write-once-read-many) drives. Data is literally etched once and can't be changed.
• Immutable snapshots: Filesystem snapshots (ZFS, Btrfs) with enforcement that the snapshot can't be deleted or rolled back without a separate admin key.
• Object-lock storage: Cloud services that support object-level locking (immutable for a fixed duration) separate from account-level delete permissions.

For large collections, ZFS snapshots on local backup storage is often the most practical. You can create weekly snapshots of your backup NAS. These snapshots are protected: they can't be deleted by normal account credentials, only by physical access or a separate vault password.

One-Way, Unidirectional Transfer Only

This is critical: your backup pipeline must be only push. The primary system pushes to backup. The backup does not pull, does not sync back, and does not have delete permissions on the source.

If ransomware compromises your primary system and tries to delete files on the backup (via network credentials, misconfigured mount points, or exploited backup software), the permissions structure must prevent it.

Example: Your NAS syncs to a backup NAS once per week via Handrive P2P transfer. The backup NAS does not have SSH access back to the primary NAS. It doesn't have syncing credentials. It receives data, writes it, and that's it. Ransomware can't use the backup NAS to propagate back to primary (lateral movement is blocked). And the backup NAS can't be told to delete or modify its own data from the primary system because that connection doesn't exist.

The 3-2-1-1-0 Rule

The classic 3-2-1 rule (three copies, two media types, one off-site) doesn't explicitly address ransomware. The extended 3-2-1-1-0 rule does:

• 3 copies of critical data
• 2 different storage media types
• 1 copy off-site
• 1 copy air-gapped (disconnected)
• 0 copies synced continuously

This means your architecture looks like: primary production storage (networked, fast, day-to-day), secondary backup on-site (RAID, fast restore), tertiary backup off-site via P2P (slower but protected by geography), and quaternary air-gapped snapshot on encrypted external drive (mounted weekly, then locked away).

For a data hoarder, this might be: primary 12-bay RAID on-site, secondary 8-bay RAID in a different room, off-site backup via P2P to a friend's NAS, and a quarterly backup to an external drive that lives in a fireproof safe and only gets connected for backups.

Implementation: The Ransomware-Safe Pipeline

Here's a concrete setup that survives ransomware:

Layer 1: Primary Storage

Your working data. 12-bay RAID-6 NAS with 18 TB drives. This is your hot storage. Network-connected, frequently accessed, typical backup targets. If this gets encrypted, layers 2–4 are still clean.

Layer 2: Secondary On-Site Backup (Immutable Snapshots)

Second NAS (8-bay RAID, or even simpler: single drive pool with ZFS snapshots). Connected to your network but not mounted continuously. Backup runs nightly: primary NAS initiates a P2P transfer to the secondary NAS. Secondary NAS writes the data, then creates a daily snapshot. Snapshots are immutable—can't be deleted without physical access or a vault password.

Even if ransomware compromises your primary NAS, the secondary NAS only receives data during the scheduled backup window. The moment backup finishes, the connection closes. Ransomware can't delete yesterday's snapshot because it doesn't have access to the secondary NAS's snapshot controls.

Layer 3: Off-Site Backup via P2P Transfer

Weekly backup to off-site location (friend's NAS, remote server, secondary residence). P2P transfer moves incremental changes. Off-site NAS maintains its own ZFS snapshots. Off-site location is geographically distant, so a physical disaster at your location doesn't take it out.

Even if ransomware deletes all your on-site backups (layers 1 and 2), the off-site copy exists. Restore takes days (you have to move data back over P2P), but the data is safe.

Layer 4: Air-Gapped Cold Storage

Quarterly full backup to an external drive. Connect the drive once every three months, run a full backup, then disconnect and store it in a fireproof safe or off-site vault. This drive never sees your network except during those quarterly events.

This is your "nuclear option" recovery copy. If every networked system is compromised and encrypted, you still have a 90-day-old copy that's been sitting in a safe.

Why This Stops Ransomware

Ransomware typically operates within your network boundary. It encrypts local files, looks for network shares, and destroys backups it can reach. It's designed for speed (encrypt everything before IT notices), not stealth (hide and persist for months).

Your 3-2-1-1-0 pipeline breaks this:

• Layer 2 (secondary backup) is snapshot-protected. Ransomware can't delete immutable snapshots without vault credentials.
• Layer 3 (off-site) is geographically isolated. Even if ransomware spreads over your network, it can't reach another building, city, or country.
• Layer 4 (cold storage) is air-gapped. Disconnected 100% of the time except quarterly backups. Ransomware can't touch it at all.

If primary (layer 1) gets encrypted, you still have three clean copies. You restore from layer 3 (off-site) in days, or from layer 4 (cold) in weeks if necessary.

The Operational Reality

This sounds complex, but it's not. You set it up once:

• Primary NAS: Always on, active daily.
• Secondary NAS: Cron job nightly pulls changes from primary via P2P, then creates immutable snapshot.
• Off-site NAS: Cron job weekly pulls changes from primary via P2P over the internet.
• Cold storage external drive: Quarterly manual backup. Plug it in, run backup script, unplug it, store it.

After setup, it runs itself. You don't think about it until you need it. And when you need it (post-ransomware), you have untouched copies in multiple locations.

What About Cloud Services?

Can you use cloud for layer 3 (off-site)? In theory, yes. In practice, be extremely careful:

• Use cloud services that support immutable object locking (separate from account-level delete).
• Use API keys with read-only access for your restore, separate from write access.
• Never enable versioning and auto-delete (keep versions indefinitely).
• Consider encrypting your backups before sending to cloud (so even if the cloud service is compromised, your data is encrypted).

But honestly? For 100+ TB, local P2P transfer to a friend's NAS is cheaper, faster, and more reliable than paying cloud storage costs year after year.

The Bottom Line

Ransomware is a real threat. Cloud backup alone won't save you if sync is continuous. The only architecture that truly protects your data is one that isolates copies: immutable snapshots you can't delete, off-site backups you can't reach from your primary network, and air-gapped cold storage that's never connected.

3-2-1-1-0. Three copies. Two media types. One off-site. One air-gapped. Zero continuous sync. That's the architecture that survives ransomware.