Once support hits in Linux, a little app of mine[0] will support block cloning for its "roll forward" operation, where all previous snapshots are preserved, but a particular snapshot is rolled forward to the live dataset. Right now, data is simply diff copied in chunks. When this support hits, there will be no need to copy any data. Blocks written to the live dataset can just be references to the underlying snapshot blocks, and no extra space will need to be used.
What does it mean to roll forward? I read the linked Github and I don't get what is happening
> Roll forward to a previous ZFS snapshot, instead of rolling back (this avoids destroying interstitial snapshots):
sudo httm --roll-forward=rpool/scratch@snap_2023-04-01-15:26:06_httmSnapFileMount
[sudo] password for kimono:
httm took a pre-execution snapshot named: rpool/scratch@snap_pre_2023-04-01-15:27:38_httmSnapRollForward
...
httm roll forward completed successfully.
httm took a post-execution snapshot named: rpool/scratch@snap_post_2023-04-01-15:28:40_:snap_2023-04-01-15:26:06_httmSnapFileMount:_httmSnapRollForward
--roll-forward="snap_name"
traditionally 'zfs rollback' is a destructive operation, whereas httm roll-forward is non-destructive. httm will copy only files and their attributes that have changed since a specified snapshot, from that snapshot, to its live dataset. httm will also take two precautionary snapshots, one before and one after the copy. Should the roll forward fail for any reason, httm will roll back to the pre-execution state. Note: This is a ZFS only option which requires super user privileges.
I might also add 'zfs rollback' is a destructive operation because it destroys snapshots between the current live version of the filesystem and the rollback snapshot target (the 'interstitial' snapshots). Imagine you have a ransom-ware installed and you need to rollback, but you want to view the ransomware's operations through snapshots for forensic purposes. You can do that.
It's also faster than a checksummed rsync, because it makes a determination based on the underlying ZFS checksums, or more accurate than a non-checksummed rsync.
This is a relatively minor feature re: httm. I recommend installing and playing around with it a bit.
What I don't understand is: aren't zfs snapshots writable, like in btrfs?
If I wanted to rollback the live filesystem into a previous snapshot, why couldn't I just start writing into the snapshot instead? (Or create another snapshot that is a clone of the old one, and write into it)
> What I don't understand is: aren't zfs snapshots writable, like in btrfs?
ZFS snapshots, following the historic meaning of "snapshot", are read-only. ZFS supports cloning of a read-only snapshot to a writable volume/file system.
Btrfs is actually the one 'corrupting' the already-accepted nomenclature of snapshots meaning a read-only copy of the data.
I would assume the etymology of the file system concept of a "snapshot" derives from photography, where something is frozen at a particular moment of time:
> In computer systems, a snapshot is the state of a system at a particular point in time. The term was coined as an analogy to that in photography. […] To avoid downtime, high-availability systems may instead perform the backup on a snapshot—a read-only copy of the data set frozen at a point in time—and allow applications to continue writing to their data. Most snapshot implementations are efficient and can create snapshots in O(1).
Once support hits in Linux, a little app of mine[0] will support block cloning for its "roll forward" operation, where all previous snapshots are preserved, but a particular snapshot is rolled forward to the live dataset. Right now, data is simply diff copied in chunks. When this support hits, there will be no need to copy any data. Blocks written to the live dataset can just be references to the underlying snapshot blocks, and no extra space will need to be used.
[0]: https://github.com/kimono-koans/httm