I have TB and TB of videos, distributed among several datasets, depending on video type. For example, in
- tank/video1
- tank/video2
- tank/video3
Currently they’re in separate datasets to help manage the snapshots. I use zfs-auto-snapshot with a pre-hook script that looks at the written value, skipping the snapshot if it’s less than a set threshold. This helps reduce empty snapshots when a dataset doesn’t change too often.
They each replicate individually to the backup boxes via zfs-backup and that’s part of the reason for separate datasets like that, rather than having them all under a common root, like
- tank/videos/video1
- tank/videos/video2
- tank/videos/video3
It would be nice to just replicate tank/videos, but that would require each sub-dataset to have the same set of snapshots as the others, and as the top-level tank/videos.
zfs-auto-snapshot/zfs-backup works fine, but meh. I’d like to re-architect to that common root and switch to sanoid/syncoid.
Can sanoid/syncoid support that ? That is, do a recursive snapshot of tank/videos with a pre_snapshot_script that only allows the snapshot for each video1/2/3 based on a written/threshold check. So each of video1/2/3 will wind up having different sets of snapshots. Then syncoid replicate the root tank/videos to the remote backup box ?
Syncoid will handle that without blinking, since it manages its own recursion rather than relying on ZFS recursion.
Sanoid might be a little more challenging, if you want it to skip taking snapshots. That’s pretty much exactly the opposite of what sanoid ever wants to do. You can probably figure out some way to make it happen, potentially using the script hook arguments, but you’re kinda on your own for that one. 
If you decide getting sanoid to do what you want is too difficult, though, you don’t have to use sanoid just because you switched to syncoid. Syncoid neither knows nor cares about what created your snapshots or how, it just replicates whatever it finds.
Worth noting: if you stick with your current plan to take snapshots at irregular intervals only, it does make it a bit harder to monitor success of replication, because you can’t just expect new snapshots to show up on the target on a regular basis.
In general, I do not recommend “don’t bother taking a snapshot unless x amount of data has changed” type strategies. They make life significantly more… “interesting” without delivering much in the way of tangible advantage. Snapshots with little or no data in them are awfully close to “free,” and having them show up on a predictable, regular basis makes monitoring SO much simpler and more reliable.
Oh, one other note: if you do use Sanoid , setting"recursive=yes" (which I always recommend) instead of “recursive=zfs” on tank/videos WILL allow you to change settings on the individual datasets beneath tank/videos. With recursive=yes, sanoid manages its own recursion (as syncoid does), which means you can set a recursive policy but override individual details on child datasets, take snapshots at the same time that aren’t linked to each other the way zfs native recursion does, and so forth.
Good to know about Sanoid recursive=yes - will keep that in mind. Thanks.
At a previous gig we uses zfs extensively, many datasets with thousands of snapshots. A typical exercise was pruning away zero-length snaps just to reduce the number to be examined.
I have personal datasets with rarely-changing data. Having a list of snaps going back a year that fits on a screen is easier to work with than one that needs scrolling and scrolling. At least for me that is 
So, do you really need daily snapshots going that far back?
The default “production” template for Sanoid keeps thirty hourlies, thirty dailies, and three monthlies.
If I wanted to keep a year’s worth of archives, I’d just bump the monthlies up to twelve, personally. I don’t need hourlies or dailies going back that far.
I’m not saying nobody does, but I am saying it’s worth at least considering whether thinning them differently as they age is worth consideration, since it solves the “I’m drowning in bullshit” problem (including getting rid of most of the ephemeral crap caught by more frequent snapshots) while still leaving your snapshot schedule predictable.
Also perhaps worth keeping in mind–it’s easy and free to use grep to filter down the list of snapshots you have to see at any given time. I do have one client who keeps several years’ worth of dailies, and if I wanted to see all the snapshots on that client’s backup from, say, May of this year I’d just
zfs list -rt snap pool/dataset | grep 2026-05 and Bob would, in fact, be my uncle. 
Heh no, I don’t need dailies back that far At least not in general. The consolidation into monthlies is generally good enough.
I did get burned once some years ago (dang, at least 6 years holy crap) - a failing of zfs-auto-snapshot I think … A large chunk of data went into a dataset, got the daily and monthly snaps fine. zfs-auto-snapshot was keeping 12 monthlies, which was fine. But for an unchanging dataset (old backup data) eventually the snaps with changes aged out, and all that was left was empty snaps of the current state.
And sure enough, I wanted to check something from ages ago …
So, I want to keep 12 monthlies, not 12 months worth of snaps. If the data is rarely changing, then those 12 monthlies should go back for years not just 12 calendar months.
Well, you CAN also have sanoid maintain yearlies…