Key Architectural Outcomes
- Write Once, Read Many (WORM) storage architecture prevents ransomware from altering existing historical backup archives.
- Automated hourly ZFS snapshots with immutable retention periods enforced at the filesystem kernel level.
- One-way push replication to secondary target behind an isolated network bridge.
- Strict 3-2-1-1-0 backup rule fulfillment (including 1 immutable and 0 verified restoration errors).
1. The Ransomware Threat to Traditional Backups
Modern cybercriminal syndicates deliberately target online backup repositories first. If backup volumes are exposed via standard SMB/NFS file shares with read/write access, malware will silently encrypt or delete backup volumes before detonating on production workstations. ZFS-based storage architectures solve this vulnerability through kernel-enforced read-only snapshots and cryptographic dataset immutability. Even if domain administrator credentials are compromised, an attacker cannot delete or encrypt past snapshots prior to the expiration of their retention lock.2. The 3-2-1-1-0 Modern Enterprise Backup Framework
3. ZFS Dataset Configuration & Immutability Commands
On TrueNAS SCALE / FreeBSD ZFS environments, datasets dedicated to backup repositories are configured with atomic snapshots and cryptographic holds:bash
# 1. Take a manual or scheduled snapshot
zfs snapshot tank/backups/vm-datastore@snap-2026-10-31-0000
# 2. Apply an immutable user hold that prevents deletion even by root
zfs hold ransomware-lock tank/backups/vm-datastore@snap-2026-10-31-0000
# 3. Attempting to destroy the snapshot will fail with EPERM
zfs destroy tank/backups/vm-datastore@snap-2026-10-31-0000
# Output: cannot destroy 'tank/backups/vm-datastore@snap-2026-10-31-0000': snapshot has holds
# 4. Stream encrypted snapshots to secondary off-site TrueNAS instance
zfs send -R -i @snap-previous tank/backups/vm-datastore@snap-2026-10-31-0000 \
| ssh backup-dr.internal.jajsolutions.com "zfs receive -d backup-pool"