With the continued adoption of Azure, and the great pricing, I am seeing more sites migrating to Azure. As we see more sites moving to Azure, I am starting to notice a few trends with regards to the way that sites are configured, backed-up, and restored using the Azure AppServices features. This post will look specifically at how to control your Backup processes with relation to DNN files to ensure a higher success rate for backups if there is interest in these topics I'll follow up with other Azure specific information.
The Problem
This view is not something that we want to see as site administrators and developers. The concept of a "Partially Succeeded" backup is something that should cause alarm and quick research. This basic status display does not give enough detail to take immediate action. You can review the .log files included in your backups storage container, however, with a DNN/Evoq based site we have a few items that we know we can do to help ourselves out, due to activity on the site that can block backups.
Skipping Non-Essential Files
By default, an Azure AppService backup will attempt to backup all files in your application, including logs, write lock files, and if using file based caching your caches. These files can often create issues due to the website actively using them at the time of a backup. For example, if the Search Indexer is re-indexing the site during a scheduled backup it is possible that the write.lock file will not copy. A failure of any single file to copy will result in the "Partially Succeeded" message. To get around this, we can add a "_backup.filter" file to the /wwwroot folder of the website. The below is a sample of a file I use for this website.
\site\wwwroot\App_Data\Search\write.lock \site\wwwroot\Portals\_default\cache \site\wwwroot\Portals\_default\logs \site\wwwroot\Portals\1\Cache \site\wwwroot\Portals\1-System\Cache
The format of this file is simply the path to the folder, or file, that we want to exclude starting with \site. In this case, you can see that I exclude the write.lock file from the search folder, as well as cache and log items, from the default portal as well as child portals. You can add additional folders here if you don't need to back them up.
In my case, the cache is not persisted through a restart, so we don't need to back it up. The Log4Net logs I have a different solution for as well which is why I can easily exclude that path.
Conclusion
File filters are an amazing thing, you have to be careful to not accidentally skip something important, and always be sure to test your backups to make sure that they work. Have another helpful exclusion? Be sure to share it below!