No this makes sense.
Thanks.
I’ll ask more if I need more.
How does it verify the snapshot is common?
Checksum?
Snapshot name?
There’s a GUID
The name doesn’t matter. They just have to be the same snapshot originally.
There’s a property specifically for this use-case.
zfs get guid pool/fs@snapwill give you a GUID (Globally Unique ID) for a snapshot. If the GUID doesn’t match between two snapshots, one isn’t replicated from the other, and they won’t work as a basis for further incremental replication.
Ok, so now I have discovered what happens.
The destination (in my case the backup server, which pulls the data) will replicate the dataset and any snapshots for that dataset that exist on the source
If a snapshot is deleted from the source, then the next replication will also delete it from the destination, which allows me to configure my auto snapshots from the source, and the backup will just reflect this config, because it replicates the snapshots as well.
@Stux Above you said that after the monthly snapshots are replicated, the source can delete them, while they still remain on the destination.
How is this possible? Won’t the next replication from the source to the destination complain that there are snapshots (the hourly ones) present on the destination?
I do this, and it just works. The main creates automatic snapshots at midnight. The backup pulls snapshots with the defined naming scheme.
The replication will continue from the most recent common snapshot.
The replication task only deletes snaps on the destination once it’s finished replicating the current snaps to the destination.
So there will be a base next time.
PS: I’ve been testing this stuff for a video 
Looking forward to it.
Found a nice little bash script over on Github. It’s also in the ports tree as well a BSD pkg repo. It only supported PUSH replication, so I did some work on the script and added PULL replication as well. Tested using both, seems to work decently. A simple cron job takes care of the rest.