Tangential to this when are operating systems going to ship w/ CoW filesystems by default? Accidental deletion of critical directories has been a solved problem for years now. I take instant snapshots of my home directory on ZFS every hour, my boot environment is snapshotted before every update.
You could literally remove my entire root directory and at worst you've minorly inconvenienced me: I now have to boot from a USB drive and run `zfs rollback` to the most recent snapshot. I'd be impervious to most ransomware as well: my home directory is filled w/ garbage now? Good thing it can't encrypt my read only snapshots, even with root access. Oh and I can serialize those snapshots across the network at the block level before I nuke the infected machine.
Of course humanity will always invent a bigger idiot, so it's possible a virus could gain root & exec some dangerous ZFS commands, or it's possible some MSFT employee could pass the `-r` flag and recursively delete a dataset & its snapshots in their post-update script. Plus let's not forget that no filesystem in the world will stop you from just zero-filling the drive. Still it's easy for me to imagine a world where I'm completely impervious from ransomware: by way of only being able to delete critical snapshots when a hardware key is present or when my TPM is unlocked.
On the whole it seems to me CoW filesystems are a major step forward in safe-guarding users from accidental deletions. At a minimum they have other benefits (serialized incremental send streams, block level compression & dedup, etc.) that make backups easier to manage. -- Yet I still can't boot from ReFS on Windows.
That'd be great, if I didn't have to turn it off. System Restore is so slow as to be borderline unusable. (In my experience creating the restore point accounts for the majority of time Windows spends doing updates, on a true CoW filesystem this should be nearly instantaneous.) Furthermore if you have VSS enabled on a volume hosting an MSSQL database it creates entries in the backup log for every snapshot, which destroys the chain of differential backups. This makes it impossible to use SQL Server Agent's maintenance plans alongside VSS in small-scale deployments (e.g: a workstation.)
I cannot stress enough: NTFS is not a CoW filesystem, any attempt to add CoW features on top of it will be poorly performant and doomed to fail, because they actually have to copy the old data blocks when you overwrite something. ZFS, btrfs, et al. are not actually copying user-data, because they don't have a concept of "ovewriting a block," every block that is written is written to unallocated regions of the disk; blocks that are not referenced by a dataset or snapshot are then returned to the allocator for later use; at no point is the old data "copied", it's just "not returned to the allocator for reuse."
What btrfs or ZFS mean by "copying" is not the user's data blocks, it's copying filesystem metadata, portions of btrfs' extent tree, or ZFS' block pointer tree. There is a world of difference between volume shadow copy, and an actual CoW filesystem. -- Microsoft knows this, that's why they are working on ReFS. (Of course in typical MSFT fashion they've made a number of critical mistakes: user data checksums are optional, and volume management is not integrated so it can't even use those integrity streams to self-heal corruption. Also last I checked ReFS can't even be used as a bootable Windows volume. -- It's worth pointing out APFS also made the mistake of checksumming metadata but not user data; which in my opinion makes both of them unsuitable as next generation filesystems.)
> ZFS, btrfs, et al. are not actually copying user-data, because they don't have a concept of "ovewriting a block," every block that is written is written to unallocated regions of the disk
Unless you just so happen to be writing over an entire block, then there still must be a copy happening. The old data, less the bytes you modified, must be written into the new block along with your changed bytes.
AFAIK no disk hardware (or filesystem) supports _actual_ byte writes, and never has. They all work by reading in a block (say 512 bytes minimum), changing the bits you asked it to and writing the new block out. So it's no extra effort to simply write the new block to a different location.
Last time Microsoft decided to replace NTFS with something modern, they took about 15 years to give up. If they start now, we can expect them to give up roughly in 2033.
They tried radical, that's why it was slow and sadly painful. Now implementing CoW ideas is at MS reach easily and would bring commercial value easily, so it could go very differently.
ZFS has now been ported to Windows. With some testing and polishing, maybe it will be something they could adopt in the future (I know, wishful thinking, but the technology is there).
You could always do what I did, and drag Windows along kicking & screaming into the future. I setup Linux on a ZFS root, carved out a zvol formatted w/ NTFS, and installed Windows on top of that in a VM. I get the benefit of being able to `zfs send | receive` the ZVOL to my backup pool, I can do instant snapshots before these godawful upgrades, etc. -- Throw a second GPU in an IOMMU group and you even get near native gaming performance. (Gaming & Visual Studio's debugger are pretty much the only things I use Windows for now.)
It's not perfect, but it works, the major downsides are:
- Granularity is at the volume level, so you get a lot more block churn in your snapshots. I mitigate this by trying to separate the "OS" volume and "Data" volume to the extent Windows will let me.
- If you're doing any heavy lifting on top of the ZVOL that expects sync writes (e.g: MS SQL) its performance will degrade slightly. Anecdotally I find this to be negligible on my all-flash pool. Besides they sell SQL Server for Linux now ;-).
- NTFS is unaware of the snapshots, so your snapshots will be of a dirty state if the guest is running. AFAIK there's nothing like `xfs_freeze/unfreeze` that can be done in the guest to make these snapshots atomic. That being said NTFS' chkdsk is quite mature, and I've never observed this to be an issue in practice.
”The Volume Shadow Copy Service (VSS) keeps historical versions of files and folders on NTFS volumes by copying old, newly overwritten data to shadow copy via copy-on-write technique. The user may later request an earlier version to be recovered.”
Out of curiosity, have you got a link to a workflow doc/tutorial/guide that could instruct someone who's a big green around the ears with using a zfs backup like this?
For a great primer on ZFS (on Linux) in general there's this website[1] by Aaron Toponce that is very well laid out. Specifically see the section on snapshots & clones, as well as sending/receiving. Also don't forget that you can make a ZFS pool out of any block device, this includes normal files mounted as a loop device! So a great way to experiment w/ learning how to manage a ZFS pool is to just create a few sparse files, add them to a pool, and just start messing around with it. (For actual production pools though always put ZFS as close to the actual disks as possible.)
What's really cool about serialized snapshots is that once native encryption support lands in ZFSonLinux you'll be able to send encrypted volumes over the wire. The data blocks don't have to be decrypted to be serialized or checked for integrity, so you don't even need the decryption key to do incremental sends! You can send your backups to an untrusted remote pool that never has to have knowledge of the decryption key!
(You can also serialize snapshots to files, which is useful for say writing them to detachable media to sneakernet them. If you want to do incremental sends though the receiver does have to be an actual zpool.)
Some other helpful hints would be using something like `mbuffer`[2] on the sender & receiver. This is handy for spinning rust pools, so that your disks don't have to wait on the network before seeking to the next blocks to be sent.
Also ZFS lets you delegate permissions so you can manage filesystems as normal users, I'd recommend doing this so you don't have to login as root on the remote pool to receive the snapshots.[3] In my case I ran into this early on because I have `PermitRootLogin no` on all my boxes.
They had that 10 years ago and called it "system restore", but they couldn't figure out how to actually...make it work.
Besides, msft makes money by selling SaaS. There's no financial incentive to protecting consumer data since the EULA indemnifies the company for any damages caused by their products.
You could literally remove my entire root directory and at worst you've minorly inconvenienced me: I now have to boot from a USB drive and run `zfs rollback` to the most recent snapshot. I'd be impervious to most ransomware as well: my home directory is filled w/ garbage now? Good thing it can't encrypt my read only snapshots, even with root access. Oh and I can serialize those snapshots across the network at the block level before I nuke the infected machine.
Of course humanity will always invent a bigger idiot, so it's possible a virus could gain root & exec some dangerous ZFS commands, or it's possible some MSFT employee could pass the `-r` flag and recursively delete a dataset & its snapshots in their post-update script. Plus let's not forget that no filesystem in the world will stop you from just zero-filling the drive. Still it's easy for me to imagine a world where I'm completely impervious from ransomware: by way of only being able to delete critical snapshots when a hardware key is present or when my TPM is unlocked.
On the whole it seems to me CoW filesystems are a major step forward in safe-guarding users from accidental deletions. At a minimum they have other benefits (serialized incremental send streams, block level compression & dedup, etc.) that make backups easier to manage. -- Yet I still can't boot from ReFS on Windows.