Kentico Quick Tips (8 Part Series)
Kentico was the first CMS to be certified to run in Azure back in 2011. The Kentico team worked closely with Microsoft to ensure compatibility and support for running Kentico outside the traditional data center environment. 👍
At WiredViews, we migrated our hosting from a private data center to Azure in 2017 and we've loved the experience of managing our client's sites in Azure ever since. 🙌
There are many benefits to using Azure's App Service product.
The primary one being that so much of the infrastructure that your application runs on in an App Service is being managed by Azure (OS updates, security hardening).
Developers get to focus on developing, and deploying their applications "just works".
The App Service has an integrated application backup solution that can be configured, on a schedule, to backup or snapshot the application's filesystem (and optionally the connected databases as well).
Here is a screenshot of that UI.
If you are used to writing scripts to
xcopy or zip files on a schedule, this built-in feature is a wonderful replacement. 👌
Here's something you might not be aware of...
If your App Service filesystem contains more than 10GB of data then the automated scheduled backups will fail! 😱
You will receive a notification like this in the Azure Portal:
Sites running on Kentico CMS can contain a lot of content. Some of that content is stored in the database (page content, site configuration, e-commerce history), but some of it might be on the filesystem (media library, attachments).
Media content stored on the filesystem can take up a lot of space.
Hopefully you are using Azure Blob Storage to store your media content in Kentico. This will keep your application's filesystem clean of anything except the deployed application code and assets.
Another good reason to keep media content in Blog Storage instead of the filesystem is that the filesystem isn't shared between deployment slots. See the section on Application Slots.
Even if you are storing media content in Blob Storage, there are ways that your App Service file system can fill up with data (log files, temp data, import process files deployed via ftp, ect...).
The way we fix this problem and ensure our backups complete successfully is to filter out the files we don't need stored in the backup. 🤔
A special file,
_backup.filter, which you can create at the root of your deployed application's folder, gives the App Service backup process instructions on what to filter out of the backup. 🧐
For a Kentico CMS site this would be placed in the
\CMS folder, added to the .NET project and deployed to the App Service with the rest of the application code and binaries.
Here is an example of what we might include in a
\site\wwwroot\App_Data\AzureCache \site\wwwroot\App_Data\AzureTemp \site\wwwroot\App_Data\CMSTemp \site\wwwroot\App_Data\Persistent
This example file would tell the App Service to ignore the specified directories when creating the backup.
These Kentico directories can fill up with a lot of extra stuff that doesn't need to be backed up, but now we don't have to worry about that stopping our backup! 🎉
One of the benefits of App Service in Azure, automated backups, is a great feature and should always want configured and enabled, especially in a production environment.
If we want to rely on these automated backups we need to obey the rules and restrictions of the platform, including the 10GB backup limit rule.
Kentico CMS can generate a lot of content, and while there are ways to keep this content off the filesystem, some sites might push past 10GB of files.
_backup.filter file lets developers select which files and folders to exclude from the backup process to ensure an App Service doesn't reach or exceed the 10GB limit for backups.
By staying below the backup limit we can help guarantee our backups always succeed. 💪
I hope you enjoyed this Quick Tip. I plan on posting more tips in this series.
If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:
or my Kentico 12: Design Patterns series.