If the server has been attacked somehow by ransomware then the sftp backups will be fine. sftp to a chroot sftp-only configuration and rsnapshot running on the remote end means one would have to not notice this for a very long time before all backups are corrupted. I am happy to demonstrate this if need be.
Adding to this time between backups can be shortened by using a different cronjob to utilize inotifywait in a loop and back up to a different or same sftp account achieving both scheduled and ad-hoc snapshots.
Yeah then you need a monitoring solution for your backup, another colo for your DR, etc. You end up with all this overhead that you need to always be on top of, unless you can hire someone that you trust and maintain things for you. It's just better value hosting elsewhere where all these unhappy path scenarios have been careful considered and taken care of. I'm definitely not say use free services either as they do not even come with support, but there's middle ground.
In terms of monitoring I could envision this just being a section of the backup script on the primary servers that perform a dry-run backup and if the delta is massive then something has likely tampered with the files, refuses to do a real backup and sends an alert, text message or otherwise. It would have to be something that people would not ignore.
The sftp backup servers in their script that kicks off their rsnapshot could also count total vs new files and alert if nothing has changed or too much has changed. Each person/org would have to determine what is an unusual time to go without changes assuming the primary mail servers have died due to malware or the new file delta is too big due to files all being tampered with.
Adding to this time between backups can be shortened by using a different cronjob to utilize inotifywait in a loop and back up to a different or same sftp account achieving both scheduled and ad-hoc snapshots.