Recent searches
Search options
Administered by:
A thread on why I use #ZFS. Each toot is one reason.
1/ Protection against Silent Data Corruption - data corruption that is not detected by any other component of the system. ZFS checksums or hashes every bit of data in the filesystem, data or metadata, and you can schedule a prediodic scan ("scrub") to see if all data is intact. On RAID setups, ZFS will automatically correct it for you. I've witnessed the value of this, particularly on petabyte-scale installations. https://en.wikipedia.org/wiki/Data_corruption#Silent
Why I use #ZFS
2/ Atomic snapshots are simple, easy, and lightweight. #Backup strategies do not generally need special handling for databases since the snapshot is atomic. Lightweight clones of snapshots are easy, and zero-storage snapshots called bookmarks are also available, to use as a basis for incremental zfs sends.
Why I use #ZFS
3/ zfs send and receive make #backups super easy. After the first full backup, there is never a need to scan the entire FS, and only changed blocks -- not changed files -- are sent. Safeguards abound. Backups every 10 minutes are fairly easy, every minute are possible, and I've been backing up my machines every hour for years now, without any load or battery life concerns. Rockets through in a few seconds on most of my boxes. More at https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp (at the end)
Why I use #ZFS
4/ zfs #encryption is more flexible than LUKS. You can apply it to certain parts of the filesystem, use different keys for different parts, etc. Even better, zfs send lets you choose whether to send raw encrypted or decrypted packets. You can make #backups for which no component ever sees the plaintext data. You can also snapshot, clone, back up, etc. without needing decryption keys.
Why I use #ZFS
5/ Built-in #compression with fast algorithms (lz4 and now zstd). In many cases the compression is fast enough that the reduced I/O results in a performance gain.
Why I use #ZFS
6/ zvols. You can do all of this with chunks that are presented as block devices, too. Want to back up that Windows virtual machine running under KVM or Virtualbox? Create /dev/zvol/foo with ZFS, attach it to the VM, and you can snapshot and backup and clone just as you would with a filesystem.
Why I use #ZFS
8/ More stable than #btrfs. Although btrfs provides many of these benefits - plus the theoretical benefit of more flexibility with rearranging data - every time I have tried btrfs, I have run into serious bugs. Some of them have been corrected, but not all. https://btrfs.wiki.kernel.org/index.php/Status gives the btrfs status. It still has pathologies with many snapshots, I believe still also with databases, though I think hardlinks have been fixed.
And to conclude, 9/ reasons I don't use #ZFS.
Although I use it on every machine I can, it is somewhat RAM hungry, so I don't run it on my #RaspberryPi machines or other very old hardware. Though I now have an 8GB Pi on hand that I intend to try it with.
It always makes me nervous, though. Running without protection against silent data corruption feels... unsafe 
#ZFS 10/ OK, an addendum. With crypto, you can even do incremental #backups (with zfs send) without ever mounting the filesystem or knowing its decryption keys - the output stream will have encrypted data, but zfs send just looks at changed blocks so you're good! Also since ZFS is copy-on-write it has better properties for SSDs that have issues with sudden power loss than most filesystems.