It has taken a week of escalting thos issue to get Azure support to respond, however, the person is good. Any community insights most useful?
Essentially, a Web Service App (not a VM) install of DNN9.3.2 cannot backup using the standard feature, we only get 'partial backups' shown which are useless for any purpose, and meant no backup existed of the installation. When MS checked over why this was happening, their logs showed.
"""What I discovered was that all backups were only partially completing because of the below exception:
File skipped - \LogFiles\ApplicationInsights\status\status_RD0003FFB61563_11892_6.json: Sharing violation to C:\Resources\directory\15b7df3b762049cbacf23452d5d0adc9.ControllerRole.BackupRestore\f0d248b8-5066-48b1-b293-193b5366dd01\package\fs\LogFiles\ApplicationInsights\status\status_RD0003FFB61563_11892_6.json
System.IO.IOException: Sharing violation to C:\Resources\directory\15b7df3b762049cbacf23452d5d0adc9.ControllerRole.BackupRestore\f0d248b8-5066-48b1-b293-193b5366dd01\package\fs\LogFiles\ApplicationInsights\status\status_RD0003FFB61563_11892_6.json
at System.IO.Compression.NativeMethods.RaiseIOExceptionFromErrorCode(Win32ErrorCode errorCode, String maybeFullPath)
at System.IO.Compression.FileStreamEx.CreateInstance(String path, FileMode fileMode, FileAccess fileAccess, FileShare fileShare)
at System.IO.Compression.ZipArchive.DoCreateEntryFromFile(String sourceFileName, String entryName, Nullable`1 compressionLevel)
at System.IO.Compression.ZipArchive.DoCreateFromDirectory(ZipArchive archive, String baseDirectory, String directory, Nullable`1 compressionLevel, Func`2 shouldArchiveFileFunc)
What these exceptions essentially tell us is that some files were skipped during backup due to a lock/sharing violation. As these files seem to have had a lock on them during the backup - they were skipped and that's what caused the backup to end with a status of "partially succeeded". All other files should have been backed up correctly.
In that case I would recommend using Backup Filters to exclude files from your Backup, which you know are being used constantly and will thus have locks on them. In your case above - this seems to be an Application Insights file - ApplicationInsights\status\status_RD0003FFB61563_11892_6.json. From the document below please review the section “Exclude files from your backup” :
By following the steps from that section of the document above you would be able to exclude that file from future backups and they should complete normally after that!""
So while my world looked like it had come to an end, the MS engineer gave me a cheat, higher levels of Azure subscription can us the SnapShot function which are continuous ghosts of the portal. AND MS dont tell you these SnapShots operate all the time for all levels of subscription, you just cant use them unless you are a hgher level subscriber.
Next step was to use a snapshot for a restore and the result failed because of other services still running in the background.
Several hours on now the SnapShot restore to the target web service still wont run. So now we have created a new 'deployment slot' alongside the main web service and asked to snaphsot restire to that instead.
What is now very clear is that there are individual featues that should protect a web app every which way, however, they are not robust yet and you can still fall througfh the gaps.