Hope this doesn’t come across as negative, but I’m not sure why one would use rsync when dedicated solutions like restic exists that are superior in almost all aspects, except maybe raw copy performance: built-in flexible retention handling, deduplication even for partial changes, compression, encryption so you don’t have to trust the backup target and more.
> I’m not sure why one would use rsync when dedicated solutions like restic exists that are superior in almost all aspects
I've used both. Perhaps restic is superior when backing up to the cloud but it's a complex program, it's local cache can be enormous, it requires at least restic itself and perhaps fuse file systems, it can be very slow to find a file.
rsync is drop dead simple, requires no special tools to restore as it's just a copy of the file system, and thus needs no caches and is always fast. A task like "compare or restore a single file from the backup" is trivial. With a wrapper script [0] it offers most of the same features as restic, bar encrypted storage. Restic's killer feature is the number of backends it supports I guess, but for local backup that doesn't matter. For local backups an rsync backup over restic every time.
I use restic for my own backups (using resticprofile). One argument for raync would be less tools to learn and less tools to install. Whether that is worth it — my own decision was: No — but if I e.g. had to backup a temporary project's raspberry pi I would not bother setting restic up and just rsync it somewhere.
TIL about —link-dest option. I use pretty much the same,rsync -aH but I use it with —delete option to rsync from primary to backup storage both running ZFS with daily snapshots. This way, my backup is always a true copy of primary, and whatever was deleted is retained ed in snapshots.
