For extra safety against hack+delete+ransom attacks, I make sure my backup servers and main kit have different credentials can't talk directly to each other at all - this way if someone hacks into my mains they can't automatically get at my backups and vice versa. I have an intermediate backup location: the active machines push data to that and the backup services pull from there, it can't login to either of the other sets. For automated backup testing, which I recommend you find time to setup, some data goes the other way (backups push to intermediate, other sites pull from there).
FWIW, we finally wrote our own "rsync HOWTO", which is ironic, given that we ran rsync.net for almost a decade without one.[1] It is NOT rsync.net specific, which is why I am mentioning it here. Just our attempt at a simple, concise rsync HOWTO. It includes crontab explanations and examples, as well as all of the SSH key generation steps.
"For extra safety against hack+delete+ransom attacks..."
rsync.net customers get protection from this in two ways. First, all accounts have ZFS snapshots enabled by default, and ZFS snapshots are absolutely immutable. Only local root can destroy them, and only with a snapshot-specific destruction command.
Second, we do server side "pulls" for all customers who request it, so you can have your backups at rsync.net without any credentials on your end for an attacker to use.
It's good software but still not really feature-complete. For example, doing mass-restore (e.g. an entire directory) is very tedious. Single files are fine, but this doesn't make it very useful.
(Point of note, I maintain the servers for the project, but don't really contribute to the project itself these days.)