Alternatively to full+incrementals, many may also do/offer full+differential - that way a full restore to most current only takes at most two sets - set of full, and set of differential between that and most current. So, advantage of that is fewer backups/media to load and read to restore, disadvantage is the size of each differential may grow relatively quickly - so for some that may not be feasible, or to compensate, may need to increase the frequency of the fulls.

There are various flavors of snapshot, but most work as something that continues to maintain a current differential. So, most of the time they're not really a proper full "snapshot", per se, but rather at the given snapshot time - and generally done at - or below - the filesystem layers, now all changes are tracked and recorded - generally at the block layer - at least between time of snapshot and current. So, on the filesystem (or block device or what have you), on the live, any time a block changes, the original is written/added to the snapshot ... except if original has already been written there, it won't be written again, and for some, if the current write happens to duplicate what was originally there, they may then remove that block from the snapshot (as it's no longer needed). And depending upon the technology, some will only do/hold one given snapshot at a time (e.g. LVM), whereas others can have multiple numbers/layers of snapshots (e.g. ZFS) ... in fact ZFS even has capabilities to flip what is a snapshot of what - e.g what's the base reference and what's the snapshot of that reference - that relationship can in fact be flipped around if/when desired to do so. So, when something says "snapshot", one is often well advised to read and pay attention, to be sure one knows exactly what type of "snapshot" one is getting, and what it does and doesn't do, and how it works.

deduplication with hardlink

Note that what you're doing there, and how, may not give you protection for some scenarios - e.g. farm of hardlinks with the originals isn't really a backup - e.g. change that data on original file - well the "backup" link to same also changes. However, yes, hardlinks can be used to greatly reduce redundant unneeded storage of backups - just those shouldn't be links to the original live active locations, otherwise writes there likewise change the data on the backup(s). See also: cmpln (Program I wrote that very efficiently deduplicates via hardlinks. It's also highly efficient as it only reads blocks of files so long as there's a potential match, never beyond the point (by block) of potential match, and never reads any block from any file more than exactly once. But note that it doesn't consider differences in, e.g. ownerships, permissions, etc.).