In February 2024, the ransomware group ALPHV (BlackCat) hit Change Healthcare — the largest clearinghouse for medical claims in the United States. The company paid a $22 million ransom. Recovery took months. Patient data for over 100 million people was exposed. The total cost exceeded $2.4 billion.

Every week, another organization joins the list. Hospitals, municipalities, logistics companies, hosting providers. The pattern is always the same: ransomware encrypts files in place, overwrites the original data on disk, and the victim is left choosing between paying the ransom or restoring from backups — assuming backups exist, are recent, and were not also encrypted.

But there is a class of filesystems where this attack model fundamentally does not work. Filesystems built on Copy-on-Write (CoW) architecture never overwrite existing data. When ransomware "encrypts" a file on a CoW filesystem, it is actually writing new blocks while the original blocks remain untouched. Combined with proper snapshot policies, this turns a catastrophic ransomware event into something you can undo in under a minute.

This is not a theoretical advantage. This is a deployable strategy you can implement today on any Linux server running ZFS or Btrfs.

What Copy-on-Write Actually Means

Traditional filesystems like ext4, XFS, and NTFS use an update-in-place model. When you modify a file, the filesystem writes the new data directly over the old data at the same physical location on disk. Once written, the previous content is gone. There is no going back without a separate backup.

Copy-on-Write flips this model entirely. When you modify a file on a CoW filesystem, the filesystem does not touch the original blocks. Instead, it:

1. Allocates new blocks on disk
2. Writes the modified data to those new blocks
3. Updates the metadata pointers to reference the new blocks
4. Leaves the old blocks exactly where they were

The old data is not deleted, not overwritten, not zeroed. It sits on disk in its original form until the filesystem decides to reclaim the space — which, critically, it will not do if a snapshot holds a reference to those blocks.

This is the key insight: on a CoW filesystem with snapshots, every previous version of every file still exists on disk, occupying only the differential space between versions. A snapshot is not a copy — it is a frozen pointer tree to blocks that already exist. Creating one is instantaneous regardless of dataset size because no data is actually duplicated.

Why Ransomware Loves Traditional Filesystems

To understand why CoW defeats ransomware, you need to understand what ransomware actually does at the filesystem level.

Modern ransomware typically operates in one of three modes:

Full encryption: The malware reads each file, encrypts it with a symmetric key (usually AES-256 or ChaCha20), writes the ciphertext back to the same location, and deletes the original. On ext4, "writes back to the same location" means the original blocks are overwritten. Gone.

Partial encryption: To maximize speed, some variants encrypt only the first few megabytes of each file — enough to render it unusable but fast enough to hit millions of files before detection. On traditional filesystems, even partial overwrites destroy the original data at those block offsets.

Metadata destruction: Some variants skip file content entirely and instead corrupt filesystem metadata — the inode tables, directory entries, and extent trees that map filenames to disk blocks. This is faster than encrypting content and equally devastating on update-in-place filesystems because the mapping between "filename" and "data blocks" is destroyed.

In all three cases, the attack relies on one assumption: writing new data destroys old data. On ext4, XFS, and NTFS, this assumption is correct. On CoW filesystems, it is not.

How CoW Breaks the Ransomware Model

When ransomware runs on a ZFS or Btrfs filesystem, every "encrypted" write creates new blocks. The ransomware believes it is overwriting your files. In reality, it is filling your disk with encrypted garbage in new locations while your original data remains perfectly intact in the blocks referenced by your most recent snapshot.

Let us walk through what actually happens on ZFS:

1. Your server has a dataset tank/data with an automated snapshot taken 15 minutes ago: tank/data@auto-2026-08-13-1100
2. Ransomware gains access and begins encrypting files in /tank/data/
3. For each file, ZFS allocates new blocks for the encrypted content and updates the active metadata tree
4. The snapshot @auto-2026-08-13-1100 still references the original, unencrypted blocks
5. Those blocks cannot be freed or overwritten because the snapshot holds a reference to them
6. You detect the ransomware, kill the process, and roll back:

# Roll back the entire dataset to the last clean snapshot
zfs rollback tank/data@auto-2026-08-13-1100

That single command restores every file in the dataset to its exact state at the time of the snapshot. It takes seconds regardless of whether the dataset is 10 GB or 10 TB, because no data is being copied — ZFS is simply switching which set of block pointers the active dataset references.

The encrypted blocks written by the ransomware? They are now unreferenced and will be reclaimed by ZFS as free space during the next transaction group commit.

Total downtime: the time it takes to type one command.

ZFS Snapshot Strategy for Ransomware Protection

The protection only works if you have recent, clean snapshots. An automated snapshot policy is non-negotiable. Here is a production-ready approach using zfs-auto-snapshot or a simple cron-based script:

Option 1: zfs-auto-snapshot (Ubuntu/Debian):

# Install
apt install zfs-auto-snapshot

# Default policy creates:
#   - 4 snapshots every 15 minutes (1 hour retention)
#   - 24 hourly snapshots (1 day retention)
#   - 7 daily snapshots (1 week retention)
#   - 4 weekly snapshots (1 month retention)
#   - 12 monthly snapshots (1 year retention)

# Verify it is running
systemctl list-timers | grep zfs

Option 2: Custom cron script for tighter control:

#!/bin/bash
# /usr/local/bin/zfs-snapshot.sh
# Run via cron every 15 minutes

DATASET="tank/data"
RETENTION_COUNT=96  # 96 snapshots × 15 min = 24 hours
SNAP_NAME="${DATASET}@auto-$(date +%Y-%m-%d-%H%M)"

# Create snapshot
zfs snapshot "$SNAP_NAME"

# Prune old snapshots beyond retention
zfs list -t snapshot -o name -s creation -H "$DATASET" | \
  grep "@auto-" | \
  head -n -${RETENTION_COUNT} | \
  xargs -I {} zfs destroy {}

echo "$(date): Created $SNAP_NAME, retained last $RETENTION_COUNT" >> /var/log/zfs-snapshot.log

# Cron entry — every 15 minutes
*/15 * * * * /usr/local/bin/zfs-snapshot.sh

With this policy, your maximum data loss in a ransomware event is 15 minutes of changes. For most workloads, that is acceptable. For databases or financial systems, reduce the interval to 5 minutes — ZFS snapshots are so lightweight that even per-minute snapshots have negligible performance impact.

Making Snapshots Ransomware-Proof

Here is the critical question: if ransomware gets root access, can it destroy your snapshots?

On a default ZFS configuration, yes. A root-level process can run zfs destroy tank/data@snapshot and eliminate your recovery point. Sophisticated ransomware groups are already doing this — variants like Royal and Black Basta specifically target backup systems, shadow copies, and snapshots before encrypting data.

This means snapshot creation alone is not enough. You need to make snapshots immutable — resistant even to a compromised root account. Here are four techniques, in order of increasing security:

1. ZFS Hold — Prevent snapshot deletion:

# Place a hold on a snapshot (prevents zfs destroy)
zfs hold keep tank/data@auto-2026-08-13-1100

# Verify holds
zfs holds tank/data@auto-2026-08-13-1100

# To release (required before deletion)
zfs release keep tank/data@auto-2026-08-13-1100

A hold prevents zfs destroy from working on that snapshot. However, root can release the hold and then destroy it. This stops careless deletion and unsophisticated malware but not a targeted attack.

2. Delegated administration — Remove root's ZFS privileges:

# Create a dedicated snapshot management user
useradd -r -s /usr/sbin/nologin zfs-snap-admin

# Delegate only snapshot creation to this user
zfs allow zfs-snap-admin snapshot,hold tank/data

# Run the snapshot script as this user (via cron or systemd)
# Root can still override via zfs allow, but the attack surface shrinks

3. ZFS replication to an air-gapped server (recommended):

This is the gold standard. Replicate snapshots to a separate machine that the production server cannot write to or destroy snapshots on. The replication target uses a pull model — it initiates the transfer, not the production server.

# ON THE BACKUP SERVER (pull model)
# This server has SSH key access to the production server
# but the production server has NO access to the backup server

#!/bin/bash
# /usr/local/bin/zfs-pull-replicate.sh
# Run on backup server every 30 minutes

PROD_HOST="prod-server"
SRC_DATASET="tank/data"
DST_DATASET="backup/prod-data"

# Get the latest snapshot on the backup server
LAST_RECV=$(zfs list -t snapshot -o name -s creation -H "$DST_DATASET" | tail -1 | cut -d@ -f2)

# Get the latest snapshot on the production server
LAST_SNAP=$(ssh "$PROD_HOST" "zfs list -t snapshot -o name -s creation -H $SRC_DATASET" | tail -1 | cut -d@ -f2)

if [ "$LAST_RECV" = "$LAST_SNAP" ]; then
    echo "Already up to date"
    exit 0
fi

# Incremental replication
ssh "$PROD_HOST" "zfs send -i @${LAST_RECV} ${SRC_DATASET}@${LAST_SNAP}" | \
    zfs receive -F "$DST_DATASET"

echo "$(date): Replicated @${LAST_SNAP} (incremental from @${LAST_RECV})"

The critical design here: the production server has no SSH access, no ZFS permissions, and no network path to the backup server. Even if ransomware fully compromises the production machine, it cannot reach the backup. The backup server pulls data outbound through a one-way SSH connection.

4. ZFS encryption with separate key management:

# Create an encrypted dataset
zfs create -o encryption=aes-256-gcm \
           -o keyformat=passphrase \
           -o keylocation=file:///etc/zfs/keys/tank-data.key \
           tank/encrypted-data

# The encryption key file should be stored on a separate
# volume or retrieved from a key management system (KMS)
# Ransomware that compromises the host but not the KMS
# cannot decrypt the snapshots on the backup server

Btrfs: The Alternative Approach

Btrfs offers similar CoW protection with different tooling. While ZFS is generally preferred for production server workloads due to its maturity and feature set, Btrfs is a solid option — especially on systems where ZFS kernel module installation is not feasible.

Creating and managing Btrfs snapshots:

# Create a read-only snapshot (critical: use -r for immutability)
btrfs subvolume snapshot -r /data /data/.snapshots/2026-08-13-1100

# List snapshots
btrfs subvolume list -s /data

# Rollback: replace the active subvolume with a snapshot
# (Btrfs doesn't have a native rollback command like ZFS)
mv /data /data.encrypted
btrfs subvolume snapshot /data/.snapshots/2026-08-13-1100 /data

# Delete the encrypted subvolume
btrfs subvolume delete /data.encrypted

Automated snapshots with Snapper:

# Install snapper
apt install snapper

# Create a configuration for /data
snapper -c data create-config /data

# Configure timeline snapshots
snapper -c data set-config \
    TIMELINE_CREATE=yes \
    TIMELINE_MIN_AGE=1800 \
    TIMELINE_LIMIT_HOURLY=24 \
    TIMELINE_LIMIT_DAILY=7 \
    TIMELINE_LIMIT_WEEKLY=4 \
    TIMELINE_LIMIT_MONTHLY=6

# List snapshots
snapper -c data list

# Recover files from a snapshot
snapper -c data undochange 50..0

Key differences from ZFS:

• Btrfs uses the -r flag to create read-only snapshots. Always use this — writable snapshots can be encrypted by ransomware just like regular files
• Btrfs does not have native send/receive with incremental replication as polished as ZFS, though btrfs send and btrfs receive do work for basic replication
• Btrfs RAID5/6 is still not production-ready (the write hole). Use ZFS for multi-disk redundancy
• Snapper integrates with systemd and provides a more user-friendly interface than manual snapshot management

Real-World Recovery: A Walkthrough

Let us simulate a ransomware event and recovery on a ZFS system, step by step.

Initial state: A production file server with 2 TB of data on tank/data, automated snapshots every 15 minutes, and pull-based replication to an off-site backup server every 30 minutes.

11:00 AM — Last clean snapshot: tank/data@auto-2026-08-13-1100

11:07 AM — Ransomware executes. An employee opens a weaponized PDF. The malware escalates to root via a kernel exploit and begins encrypting files using ChaCha20. It processes approximately 50,000 files per minute.

11:12 AM — Detection. Your monitoring catches anomalous disk I/O (massive sequential writes with no corresponding reads from legitimate applications). The ZFS written property on the dataset spikes from normal 200 MB/interval to 40 GB in 5 minutes:

# This command shows how much data has changed since the last snapshot
zfs get written tank/data
# Normal: ~200M
# During attack: 40G+ (massive CoW writes from encryption)

11:13 AM — Containment. Kill the ransomware process, isolate the server from the network:

# Identify and kill the ransomware process
ps aux | grep -i '[e]ncrypt\|[r]ansom\|[l]ockbit'
kill -9 

# Network isolation (keep SSH on management VLAN)
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -i mgmt0 -p tcp --dport 22 -j ACCEPT

11:14 AM — Assessment. Check snapshot integrity:

# List available snapshots
zfs list -t snapshot -o name,creation,used tank/data

# Verify the last clean snapshot is intact
ls /tank/data/.zfs/snapshot/auto-2026-08-13-1100/
# You should see your original, unencrypted files here

# Compare: current state vs snapshot
diff <(ls /tank/data/) <(ls /tank/data/.zfs/snapshot/auto-2026-08-13-1100/)

11:15 AM — Rollback:

# Destroy any snapshots created DURING the attack (they contain encrypted data)
zfs destroy tank/data@auto-2026-08-13-1115

# Roll back to last clean snapshot
zfs rollback tank/data@auto-2026-08-13-1100

# Verify
ls /tank/data/
md5sum /tank/data/critical-file.db

11:16 AM — Operational. All files restored to their 11:00 AM state. Data loss: 7 minutes of changes (from 11:00 snapshot to 11:07 encryption start). Total downtime: approximately 3 minutes.

Compare this to the ext4 alternative: restore from last night's backup (10+ hours of data loss), spend hours verifying backup integrity, rebuild the server from scratch, and pray the backup was not also compromised. Recovery time: hours to days.

Monitoring for Ransomware on CoW Filesystems

CoW filesystems give you a unique detection advantage: you can monitor the written and usedbysnapshots properties for anomalous changes. A sudden spike in data written since the last snapshot is a strong indicator of bulk encryption.

#!/bin/bash
# /usr/local/bin/zfs-anomaly-detect.sh
# Run every minute via cron

DATASET="tank/data"
THRESHOLD_GB=5  # Alert if more than 5 GB written since last snapshot
LOG="/var/log/zfs-anomaly.log"

WRITTEN=$(zfs get -Hp -o value written "$DATASET")
WRITTEN_GB=$((WRITTEN / 1073741824))

if [ "$WRITTEN_GB" -gt "$THRESHOLD_GB" ]; then
    echo "$(date) ALERT: ${WRITTEN_GB}GB written since last snapshot on $DATASET" >> "$LOG"
    # Send alert — email, Telegram, PagerDuty, etc.
    curl -s -X POST "https://api.telegram.org/bot/sendMessage" \
        -d "chat_id=" \
        -d "text=🚨 RANSOMWARE ALERT: ${WRITTEN_GB}GB written on $DATASET since last snapshot"
fi

This is a detection mechanism that traditional filesystems simply cannot provide. On ext4, there is no efficient way to ask "how much data has changed in the last 15 minutes?" On ZFS, it is a single property lookup.

The Limits of CoW: What It Does Not Protect Against

CoW is powerful, but it is not a silver bullet. Understanding the limitations is important:

Data exfiltration: CoW protects availability (you can restore your data) but not confidentiality. Modern ransomware groups practice double extortion — they steal data before encrypting it. CoW does nothing to prevent data theft.

Disk space exhaustion: Since CoW writes new blocks for every modification, a ransomware attack consumes free space rapidly. If the pool fills to 100%, ZFS enters a degraded state and may not be able to complete a rollback cleanly. Mitigation: set zfs set reservation=50G tank/data to guarantee rollback space, and monitor pool usage.

Boot/OS partition attacks: Your ZFS data pool may be safe, but if the OS partition (typically ext4 on /boot or the root filesystem) is encrypted, the server will not boot. Mitigation: keep a separate, minimal rescue environment that can boot and access ZFS pools.

Snapshot deletion by root: As discussed above, default configurations allow root to destroy snapshots. Air-gapped replication is the definitive solution.

Encryption at rest vs encryption of data: ZFS native encryption protects data at rest (stolen drives cannot be read) but does not prevent ransomware from encrypting files at the application layer above the filesystem.

Defense-in-Depth: A Complete CoW Anti-Ransomware Architecture

Here is the full stack for a ransomware-resilient server:

Layer 1 — CoW Filesystem (ZFS): All data on ZFS pools. Automated snapshots every 15 minutes with 24-hour retention.

Layer 2 — Immutable Snapshots: ZFS holds on critical snapshots. Delegated administration so the application user cannot modify snapshot policies.

Layer 3 — Air-Gapped Replication: Pull-based ZFS send/receive to a backup server that the production machine cannot access. Replication every 30 minutes.

Layer 4 — Anomaly Detection: Monitor written property on all datasets. Alert on deviations beyond 3 standard deviations from the rolling average. Automatic snapshot creation on anomaly detection.

Layer 5 — Network Segmentation: Backup server on isolated VLAN. No inbound connections from production network. Management access via jump host only.

Layer 6 — Regular Testing: Quarterly ransomware simulation drills. Verify rollback works, measure recovery time, validate backup integrity.

# Quick health check: verify your protection is active
echo "=== ZFS Ransomware Readiness Check ==="
echo "Pools:"
zpool status -x
echo ""
echo "Recent snapshots:"
zfs list -t snapshot -o name,creation -s creation | tail -10
echo ""
echo "Snapshot space usage:"
zfs get usedbysnapshots tank/data
echo ""
echo "Current written since last snapshot:"
zfs get written tank/data
echo ""
echo "Holds on snapshots:"
zfs holds -r tank/data 2>/dev/null || echo "No holds configured"

Why Bare Metal Matters for CoW Protection

You cannot implement this architecture on a shared cloud instance. Cloud providers manage the storage layer — you get a virtual disk, not raw block devices. You cannot run ZFS on an EBS volume with any guarantee of CoW semantics, and you certainly cannot set up pull-based replication to your own hardware.

Dedicated bare metal servers give you full control over the storage stack: you choose the filesystem, configure the snapshot policy, manage the replication target, and own the network segmentation. No hypervisor between you and your disks. No cloud provider deciding your storage backend. No shared storage array where another tenant's ransomware event triggers an I/O storm on your volumes.

At SwissLayer, our dedicated servers ship with NVMe storage and full root access — you can deploy ZFS from day one with the exact snapshot and replication policies your organization requires. Combined with our 10Gbps unmetered connectivity, replication to off-site backup targets runs at wire speed without bandwidth caps eating into your transfer budget.

Swiss jurisdiction adds another layer: your data — and your snapshots — are protected by Swiss Federal Data Protection law (FADP), not subject to foreign court orders, and stored in facilities with physical security standards that match the cryptographic security of your filesystem. Ransomware resilience is not just about software architecture. It is about controlling the full stack, from the jurisdiction your data resides in to the blocks on the disk.

Ready to build ransomware-resilient infrastructure? Explore our dedicated servers with full ZFS support, NVMe storage, and the Swiss data protection framework behind them — or talk to our team about designing a replication architecture that fits your recovery objectives.