There's a number of reasons I feel this assumption is valid in most cases: 1) Unless it's a targeted attack it's highly unlikely that a ransomware strain will

There's a number of reasons I feel this assumption is valid in most cases: 1) Unless it's a targeted attack it's highly unlikely that a ransomware strain will be designed to target a specific filesystem. Snapshot deletion requires filesystem specific APIs, whereas reading/writing files is just standard libc fare. You would need to maintain different strains of a virus to target an organization running Btrfs vs ZFS vs ReFS, for example. - If the attacker has deep knowledge of your storage stack, and has gained privileged access to it, you've already lost: go to step 4. 2) Separation of privileges. Deleting a snapshot is a privileged command. A ransomware infection that doesn't successfully elevate privileges might be able to encrypt my home directory, which would suck, but it wouldn't have permissions to delete snapshots of my home directory. 3) Virtualization / network storage: snapshots are transparent to virtual guests, a virus inside a guest can't delete snapshots if it's not aware they exist. With network shares and ZFS: you can choose whether or not you want to expose snapshots. If you do expose them: don't grant network clients privileges to delete them. 4) Replication: with any ransomware infection the only real defense is off-site backups. Snapshots makes backups trivial. You can incrementally replicate and restore from them easily (e.g: zfs send/recv.) This alone makes using a CoW filesystem worthwhile in the defense against ransomware. Ransomware will have a hard time deleting snapshots on an air-gapped disk.