RAID is not a backup, and conventional ext4/xfs filesystems cannot protect your data against silent bit rot, controller corruption, or accidental deletions.

ZFS on Linux (OpenZFS) combines filesystem management with volume virtualization. Features include copy-on-write integrity, end-to-end Fletcher4/SHA-256 data checksumming, and instantaneous read-only snapshots. This makes it an ideal foundation for production storage arrays and Docker volume persistence.

Creating the Resilient Storage Pool

Never configure ZFS pools using transient device nodes like /dev/sdb. Kernel drive assignments change across reboots. Always reference unique disk IDs:

bash
# Create a 6-drive RAIDZ2 pool (tolerates 2 simultaneous drive failures)
sudo zpool create -f -o ashift=12 -O compression=zstd -O acltype=posixacl \
    -O xattr=sa -O normalization=formD -O atime=off -m /tank tank \
    raidz2 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_1 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_2 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_3 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_4 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_5 \
    /dev/disk/by-id/ata-WDC_WD80EFZZ_6

Essential Dataset Options:

  • ashift=12: Enforces 4096-byte (4K) sector alignment. Crucial for modern Advanced Format drives; failing to set this causes severe write amplification.
  • compression=zstd: Transparent real-time compression with negligible CPU overhead. Increases effective IOPS and extends drive endurance.
  • atime=off: Disables access timestamp updates on reads, eliminating unnecessary metadata writes.

    • Automated Snapshot Management with Sanoid

    ZFS snapshots are instantaneous and consume zero extra storage until underlying data blocks are modified or deleted. Sanoid automates policy-driven snapshot schedules.

    Install Sanoid and configure /etc/sanoid/sanoid.conf:

    ini
    [tank/docker-volumes]
    use_template = production
    recursive = yes

[template_production]
    frequently = 0
    hourly = 24
    daily = 30
    monthly = 6
    yearly = 1
    autosnap = yes
    autoprune = yes

    With this configuration, if a developer mistakenly executes rm -rf /app/data inside a container, you can instantly recover the dataset to its exact state from 2 hours ago without restoring hundreds of gigabytes from tape or cloud archives:

    bash
    # Access snapshot directly in hidden shadow directory
cd /tank/docker-volumes/.zfs/snapshot/autosnap_2026-10-26_14:00:00_hourly/
cp -r corrupted_service /tank/docker-volumes/

    Off-Site Replication with Syncoid

    Local snapshots protect against ransomware and human error, but cannot save data if the physical facility suffers catastrophic hardware loss.

    Using Syncoid (part of the Sanoid suite), replicate incremental snapshots over an encrypted SSH pipeline to a remote backup machine:

    bash
    syncoid --no-sync-snap tank/docker-volumes backupuser@remote-node.aebibtech.com:backuptank/docker-volumes

    Because Syncoid only streams modified blocks since the previous snapshot, daily offsite synchronization of terabytes of data completes in minutes over modest broadband connections.