The adoption of Azure AppService continues to grow, and I fully support this. However, one of the most common requests that I get when transitioning people surround backups and true redundancy and integrity strategies. Out of the box, Azure provides two backup options, which are important to understand. In addition to this, there are easy tools to automate off-site backups if desired.
Configuration Based Options
The following backup strategies are available with simple Azure configuration and do not require any programmatic intervention.
Azure Backups are accessed directly from your App Service by navigating to the "Backups" blade and is co-mingled functionality-wise with the "Snapshot" functionality I'll discuss later. Azure backups support a basic configuration and will back up the site on a scheduled basis, and optionally the database, to a zip archive and place it in Azure Blob Storage.
- Backups are placed in Blob Storage as regular zip files. They can be downloaded and with a GRS storage account can be geo-redundant
- You can easily extract and restore single files by downloading the zip.
- Automatic support exists for schedules and retention policies.
- If the total backup size is larger than 10 gb, you cannot use this process at all
- Although automatic failures are not automatically broadcast, so you must review.
- File lock issues can prevent specific files from backing up
Snapshots are a feature that is currently in Preview within Azure. It has been a preview functionality for more than 2 years at this point, but it is still a preview feature. Even though they are preview they operate entirely different than the Backups functionality and provide a number of additional benefits, with a different set of limitations.
- No website storage limits
- No configuration is needed, automatically implemented
- No file copy issues due to file locks
- Implementing using Shadow Copies so more granular restore options for time are available
- Internally 90 days of backups are retained, for Azure Platform recovery purposes
- Requires a Premium tier of AppService
- Only 30 days of history is available
- You must restore the ENTIRE application, you cannot restore a single file
- You cannot download a snapshot to your local machine
- It does not backup the database at the same time
After exhausting the out-of-the-box options, let's look at a few options that we can use to quickly download a copy of the site for offline storage.
KUDU API Download
KUDU is the "Advanced Tools" interface that you can access from within your Azure AppService and it contains an API that allows you to do administrative functions in addition to the web-based interactive behavior. Using KUDU it is easy to get a full download.
If Logged In
If you are already logged in to KUDU you can simply past the following into the browser to download the entire contents of your /wwwroot folder.
If Not Logged In
If you want to do this programmatically, or via a command line, you can use the publish profile credentials and format a URL such as the following to accomplish the same single-file download.
By simply placing your username, password, and site address in, it is easy to download a copy automatically. This process works very well and leverages the functionality of KUDU to do this without cluttering your system. Obviously, retention/storage is all on you, but this is a TRUE off-site backup.
The most common strategy used is of course the most simple, connect via FTP and download all of the files. The limitation of this method is nothing more than the time necessary to download the assets. Small sites, this is totally acceptable and works well. Larger sites, this can take hours given the number of files and/or the size of the files to download.
Powershell Zip & FTP Download
We can level up the traditional FTP model and utilize the KUDU Powershell window to Zip the site, and then download via FTP, to complete this process it is quite easy, but there are a few small nuances to consider. You start the process by accessing the Powershell Debug Console and navigating into the /site folder. You can then execute the following commands.
The first statement is critical, as the KUDU console does not support progress bars, so you must set the progress preference to silentlycontinue; otherwise, the entire process will fail. The second command creates a backup file called Mitch-Backup.zip in the current directory of the entire site. You can then take this single file and download/transfer it much faster than grabbing individual files. I have wrapped the command with a measure-command to help get analytic information on how long it took to complete since we have no progress indicators available.
Selecting a Direction
There are many methods available for offsite and remote backups. The right choice, or choices, will be different for everyone depending on the risk tolerance, frequency of updates and other system needs. However, I hope that this overview gives you some insight into the options available.