All your suggestions currently have one thing in common: the backup source does the backup and has access to the backup destination. Whether you mount the location or use tools like SSH or rsync, the source system somehow has access to the backup. Therefore, a compromise on the server might compromise your backups, too.
What if the backup solution has ...
One good option is to make your backup storage immutable, or at least provide reliable versioning which gives you effectively immutability. To be clear: immutable means unable to be changed, or permanent.
There are multiple services that can do this for you. AWS S3, BackBlaze B2, and I suspect Azure and Google both offer a similar service....
Solutions that aren't really interesting in my situation:
An extra backup job on the offsite host which transfers them to a location that isn't accessible by the first host.
The fundamental problem is that if you can remotely access your backups then so can the hacker.
(Due to technical limitation)
Technical limitations are made to be overcome.
You can use storage services like AWS S3 (or probably Google's or Azure's equivalent) where you can give your root account PUT permissions to your bucket but not DELETE permissions. That way, you can use a push model and the attacker won't be able to delete the backup.
There are further security measures that you can take with AWS, like requiring MFA to ...
Borg backup through SSH with key authentication. Problem: connection to that offsite server can be done with the key that's store on the host if the malicious user has root access to the host.
You can use option command in your authorized_keys. You fix the command allowed in remote.
how to add commands in ssh authorized_keys
Even if an attacker recovers ...
Combining the test command with the -d flag and checking to see if the mount exists per this question:
if mountpoint -q "$mount" && test -d /path/to/share; then
cp -ru /path/to/files /. -t /path/to/share
Edited per Michael Hampton's comment.
Backup all of /etc/, and any config you know is elsewhere. Optionally, if you don't have a good installed package list, your rpm database in /var/lib/rpm/. Consider incremental backups of these directories, although fulls don't take up that much space.
To find what rpm thinks are config files, run rpm -qac. There is some non /etc/ strangeness in here that ...
Azure Backup Recovery Services Vault is a different entity than a storage account. It is not Blob and does not have hot/cool/archive tiers. Restores to your choice of storage account are documented.
As of June 2019, Azure Backup can backup VM disks and Azure File shares. To backup Azure Blob, use a different solution.
Instead of vault, it is possible to ...
A technique you could set up is using syncthing between your server and a remote backup server, and letting the remote backup server do snapshots or whatever on its end so that erasure server side doesn't result in erasure offsite.
One method that comes to mind is to iterate over the list of mountpoints and see how many files are present under each one. A value of 1 probably means the filesystem isn't mounted (and only the directory itself is present). This strategy won't work if the mountpoints are nested, however. By "nested" I mean mountpoints like: