I know it’s pedantic, but ZFS snapshots and replications apply to datasets, not drives or pools. When datasets, folders, drives, pools, and vdevs are conflated, it causes confusion for users down the road.
I know what you meant though. You are correct. Whether full or incremental replication, the target will have an exact “mirror” of the file-system at the exact point in time that its snapshot was created. Not just files. Everything. Data, metadata, timestamps, permissions, ownerships, everything.
Correct.
The disclaimer is that rolling back a snapshot is a destructive one-way operation. If you need to recover files that you had deleted, and they exist in an earlier snapshot, then there are safer ways to do that.
Rolling back the source to an earlier snapshot will break your ability to do incremental replications, unless you force a rollback on the destination as well.
Correct.
A better way to look at it: Snapshots never add data. They can retain deleted data that won’t free up any space until the snapshot is destroyed.
I made a non-technical guide here. You might find it helpful.[1] It’s intentionally silly and extreme for the sake of illustrating how powerful snapshots are and how they can get out of hand for many new users.
The “white” stickers are automatically tagged to boxes that exist in the “live file-system”. Unlike the “color” stickers, the white stickers are not snapshots. ↩︎