MicrosoftI would like to add that if you are using IaaS VM servers (I am using SQL Server IaaS servers in this case) with Azure managed disks then you can reach the throughput limit on disk if you are not careful and affect the performance on the VM possibly using SMB multichannel. We use the default Azure Fileshare settings and it limits the throughput to 300MB/s which does not cause the disk throughput issues, backups do take longer but VM performance is not effected by throughput overwhelming the managed disks. We also mirror the SQL backups to BLOB storage and BLOB storage definitely has the ability to exceed the disk throughput on the VMs but paired with the FileShare it limits the throughput to 300MB/s for both, the FileShare acts as to limit to disk throughput. The only gotcha is that with BLOB backups you will probably hit the 50K block limit on large DBs that go over 12TB in size with backup files and if you decide to mirror the SQL backups then you are limited to 64 files for both the FileShare and BLOB backup files, you will need to use multiple files to avoid the 50K block limit. On our largest DB I backup to Fileshare only (64 files) and then copy up to BLOB storage from the FileShare with AZCopy, limited to 300MB/s on any one server but I use more than 1 server to copy to BLOB storage so it does not take as long as you think to move 13TB+ of data to BLOB storage. Once there it can be managed by storage policy to keep only so many weeks of backup; restores from BLOB are very fast compared to FileShare (300MB/s without the SMB multichannel). It also means you can restore to another region without having to copy the data to that region, the BLOB storage is accessible and the throughput is very high from the BLOB storage.
