My approach to backups is the same, irrespective of where the SQL Server instance sits.
SQL Server native backups to a network share, or "local" drive if you're on an Azure VM (I tend to avoid writing directly to Blob Storage for backups, because it's slow).
A process that copies these backups to "offsite" storage. In most cases these days, this is Azure Cool Blob Storage, with some form of Geo-Redundancy. My process might be AzCopy, or PowerShell, a batch file, or my own Database Backup Sync tool. It doesn't matter how you do it, as long as you're doing it. The point is to get a copy of the backup files as far away from the source as soon after the backup as possible.
Don't think of it as a backup, think of it as the fastest (RTO) way to recover the database to a consistent state, at a point in time (RPO) that satisfies the business requirements. Stated more plainly:
- how quickly do you need to restore in a disaster recovery scenario?
- how much data is the business prepared to lose?
In other words, focus less on where the files are going, and more on the reliability of the backup files, and your restoration process, if everything catches on fire.
That means having checksums enabled on backups, a regular test of restoring the databases (on another machine somewhere), followed by a DBCC CHECKDB
to ensure consistency in the database.
The elegance of Blob Storage as a secondary store for backups is that you can pull the files down from any Internet-connected machine and test the restore process.
I do not discuss typical maintenance tasks you should also be running on your instance, which includes DBCC CHECKDB
, index and statistic maintenance, etc. Those are outside of the scope of this answer.