Here and here “My Backups are failing, Let’s open a support ticket” are some good information about how to configure an Azure App Service backup. I like the fact that you can also include a database backup in parallel with a backup of the web site. Keep in mind the limit of 10GB in regards to the maximum size that can be backed up and the size of the database cannot be larger than 1GB. This database limit is only applicable when being backed up via the Azure App Service feature. For sure you can backup your database using the SQL Azure, MySQL, etc… tools.
The backup of your database could have any of these status during/after the scheduled or manual execution of a backup:
If you get an exception and you want to investigate further, make note of the Storage Account and Container where you stored the backup. You can find this out by clicking on the Storage link on the Backup blade, as shown in Figure 1.
Figure 1, which container is my azure app service stored into, troubleshooting Azure Backups
You can also find that information by clicking on one of the backups and looking at the File Location value on the Backup properties blade, as seen in Figure 2.
Figure 2, which container is my azure app service stored into, troubleshooting Azure Backups
If there is some exception, you would likely see it dumped out in the Backup Logs detail also on the Backup properties, seen also in Figure 2.
There is also a log file written as part of the backup and would likely contain some useful information. To get that backup log file, <pause> from within the Azure portal, navigate to the Storage Account Container and you will see 3 files written per backup. The ZIP file which contains the actual backup, and XML file and the LOG file. You would see something similar to that shown in Figure 3.
Figure 3, get the azure backup log file from the storage container for debugging and troubleshooting, troubleshooting Azure Backups
Then open it up and see if there is any information within it that help progress.
I’ll update this one as I experience new scenarios.
- Partially Succeeded means that there were likely some files which could not be backed up, because they were locked for some reason. When this happens the backup process skips them and backs up the rest of the site and database if configured. You should be able to see which files were skipped in the log file. If for some reason you do not need these files backed up you can skip them by following the instructions in section “Backup just part of your app” here.
- Stopping Locked On-Demand/Triggered Azure Webjob sometimes is the reason for a Partially Succeeded backup status
- If your web site is greater then 10GB and you have some static files which do not need to be backed up because they do not change, again, you can skip them by following the instructions in section “Backup just part of your app” here. There is currently no option to increase the 10GB limit. There is also no option to increase the 1GB size limit on the database.
- UMBRACO – File skipped – \\site\\wwwroot\\App_Data\\TEMP\\ExamineIndexes\\External\\Index\\write.lock: Sharing violation to C:\\Resources\\directory\\4331c001051d47afae56f28ebb1a7320.ControllerRole.BackupRestore\\faf2fcdd-89a2-46cc-be5f-00465d7820f6\\package\\fs\\site\\wwwroot\\App_Data\\TEMP\\ExamineIndexes\\External\\Index\\write.lock -> in this case add a file named _backup.filter that includes a line \site\wwwroot\App_Data\TEMP\ and place it into the D:\home\site\wwwroot\ of your web app, as discussed here. This will skip the files in that directory, assuming you want them to be skipped.