100% agree. Disaster recovery planning means asking "What if....?"
Most of our clients still keep their live data local, and then Backup to a dedicated cloud backup service. It's a scheduled task, and keeps multiple generations of backup, like old school tapes, so we can go back X months for versions of files. It's been tested, and used "in anger" to recover from accidental or malicious deletions, so we know it works. It's also a locally based company, and we can get phone support if needed. It's an automated process with their own client software, and emails the status to both the client and our office each morning, so you get a notice if a scheduled task hasn't happened, or has fallen over for some reason. It's actually better than manually doing backups, as we have had situations where a user has been changing tapes / disks each day, but the backup never actually worked. And no one knew....
But if the backup service shuts down tomorrow, for any reason, live data isn't affected, and we can implement a new backup plan, even if it's something like a USB hard disk as a temporary thing.
Another client has their main business system hosted on a AWS cloud. Each night the system makes a local backup of the database to a backup folder on the cloud server. Obviously that alone is not good enough, it's a single point of failure. So we copy that backup file down to a local server overnight, and add the file into the backup of local files and emails that are sent to the local cloud provider. So the backup exists in 3 different physical locations, with versioning and 3 months of history on the final cloud backup. So again, as you say, there are backups in 3 different physical locations. So far we haven't had to recover anything from the AWS system. but if the whole virtual server "went away", it would be rebuild-able. AND prior to the AWS, the clients building took a direct lightning hit, and the backup system saved them then, once they got power and internet back on, and a couple of new PCs / network switches / UPS units.