Azure App Service backup failure

Resolving a backup failure of a DNN application in an Azure App Service

Scenario

It had been one of those days when nothing had gone right so it should have been no surprise that a routine module upgrade on a DNN installation running as an Azure App Service would not go quite as easily as it should have. Being a diligent person, I decided to check there was a backup before performing the upgrade when, lo and behold, I found the following:

The solution

The last backup had been some time ago and there had been nothing but failures since. As with all backup failures, whether in the cloud or not, the problem was likely an open file but which one? The Azure portal doesn’t exactly make it easy for you. There is a log file that goes with each backup but there was no obvious way to get that using the portal. So, time to connect to the storage account – the backups are stored in a blob within the storage account -using Azure Storage Explorer and take a look.

The log file for one of the failed backups was duly located and downloaded, In the log was the following text:

Timestamp: 2020-05-24T04:00:00.3263094Z Creating temp folder. Retrieve site meta-data. Backing up the databases. -- mydatabase Backing up site content and uploading to the blob... File skipped - \site\wwwroot\App_Data\Search\write.lock: Sharing violation to C:\Resources\directory\7d9308a8be7778c17986a9dc3eb953b.ControllerRole.BackupRestore\f98d1e76-e79e-4c53-b7c9-79e57a66bbe8\package\fs\site\wwwroot\App_Data\Search\write.lock Uploading metadata to the blob.

With the open file now identified, all that needed to be done was exclude it from the backup. Azure backup doesn’t allow for much in the way of configuration when it comes to App Services so, after a bit of research and consequent head scratching, it became clear that the solution was to place a text file called _backup.filter in the root directory of the DNN installation. So, one was duly created with the following content to exclude the open file:

\site\wwwroot\App_Data\Search\write.lock

Then the file was uploaded to the root of the web application.

Now, it was time to run a backup to confirm that a successful backup could be taken.

Looks like it worked so I could then get on with the work that I was actually supposed to be doing. Like I said, it was just one of those days.