One of the more common newbie mistakes is to run sanoid on the replication target with the production template, rather than the backup or hotspare templates. You don’t want to take snapshots locally on a replication target–which is why you use the backup or hotspare templates for the target, so Sanoid knows it should be pruning stale snapshots but should not be taking new ones itself.
Remember, this isn’t as scary as it might sound–Sanoid is cautious, so if inbound replication stops working, Sanoid won’t delete older snapshots. Looking at dailies as an example, let’s say you’ve got 30 dailies on your backup target, then something breaks and you stop getting new dailies replicated in.
When Sanoid runs the next day, it’ll see that the oldest daily is 31 days old–but it won’t delete it, because there are only thirty total daily snaphots available, and in order for a stale snapshot to be pruned it must be both be older than thirty days, and there must be thirty newer snapshots present. So even if you are a very very bad sysadmin and don’t notice for several months that your backups weren’t running, Sanoid won’t ever prune your orphaned backups until replication is fixed, and newer snapshots finally begin rolling in.
Continuing this example, let’s say your internet connection dropped at the remote location, and you didn’t notice for 90 days. When you fix it, you’ll still have 30 dailies on the remote–but they’ll be 60-90 days old, instead of 0-30 days. Once you have it fixed, let’s say a single daily snapshot replicates in before the connection goes down again. Sanoid will now see 31 dailies available, so it will prune the oldest of the stale dailies, but leave the other 29 as well as the new one.