This is by way of feedback on our experience on stetching Azure Web Application Services (NOT Virtual Machines), where after six weeks of interaction with MS we have a view as to why backing up and snapshotting failed.  Our portals were in central USA, UK and France.

Clearly this is rare maybe unique even, and we contributed in the early stages from expecting too much too quickly.   Maybe its a sign of with increasing use of features comes problems not previously found.  Azure Web Applications are different in they are like IIS in a box, which makes it very attractive to deploy new functional portals quickly and consistently. 

Broadly the symptoms were: incomplete or failed backups (we manged about 1 in 3 that completed and were usable); very (very) long backup times; erratic ftp site transfers; inability to delete all the files in a site folder (ftp or console); inablity to restore from any backup or snapshot; occasional wildly different backup file sizes; error messages about log in IDs failing to working SQL databases.

From the Community contributions in understanding why (thank you again), many others are successfully using Azure web apps, though most do not using the more sophisticated features of Web Apps.

The start point was that we had architected for multiple DNN installs running our compliance portals in different countries and different languages (all out of the same Azure panel). Good old GDPR/Privacy designed in from day one.  However...

Ultimately, the problems seem to stem from Web Sevices not clearing the backcup cache that is used in the background. 

The upside of all of this is we have clear evidence of how robust DNN 9xx is, we have pulled and pushed it every which way and it still works.

So a few mostly obvious observations in no order of importance for using Azure based on our experience to October 2019:

• Beware of Azure nomenclature, 'partially successfull' isnt usable in Azure in any way.
• Keep it simple, one web app and database in each Azure region in its own resource group, dont cross regions.
• DONT under any circumstance use the Azure marketplace installer for DNN, do it manually
• DONT use web App slots (we had two portals running on the same SQL quite happily but content didnt cross over from one to the other (why should it).
• Notifications saying things have completed dont always mean they have, there is a lot of latency in the control panels from start to finish. Slow is the best way to work.
• Ideally, stop the portal before backing up until you have the locked files filter installed OK.
• 1.8Gb site can take three hours to back up!
• Make sure you have the minium locked files filter text file in the wwwroot. [named   _backup.filter.txt     containing "\site\wwwroot\App_Data\Search\write.lock"]
• Keep a work log of what you did and when time wise, so you can go to a backup and know where you were at the time.
• For every web app have its own storage and recovery containers, dont mix containers within the same storage space. (these are your protection if it all goes pear-shaped).
• You cant backup and restore across web apps, its best to download and restore manually.
• If backups misbehave, use the reset tab to clear out all the settings and start again. If that doesn't work recreate all the storage and containers again and reset bacups. If that doesnt work, upgarde the account temprarily to the next level subscription, close the Azure panel and log out. Log back in, return to the correct subscription, and recreate containers/reset again.
• Azure Snapshots dont work properly if the backup isnt working (there is a bit of question on this however as MS says it should always work and they use it as the first route to recovering a lost site).
• The DNN upgrade pack works well to restore a site to working state without a re install (manual ftp), even to the same version, if once restored the site doesn't start (it shouldn't work but it does).
• Dont mix anything across resource groups.
• When manually uploading a fresh install or restoring a backup, hard delete out any remaining files/folders in the web app location. 
• Always download  backup file copies to your desktop (includes portal and SQL backpac plus some meta data). A good back up zip file is to be highly prized.  Use this to check file numbers and sizes.
• ftp transfers can fly or keep dropping out, its erratic.
• There is a limit of 10GB on portal site size before the backup and recovery gets more complex (portal and SQL cant be done together.

We had decided to abandon Azure Web Apps. The support engineer got the bit between her teeth and kept at it so we have stayed with her, and maybe we can still meet our timetables in Azure. She has been brilliant.

If this helps with a few warning signs before such installations drive you crazy, then all to the good.