Backup for Azure Blob Storage - 2021 Update
One of the most popular articles on this site is one I wrote back in 2018 about options for backing up Azure Blob storage. I think one of the reasons it has been so popular is that the ability to backup Azure Blobs seems like something that should be trivial, but when you start looking into it, you realise you’ve opened a can of worms, and there isn’t really a good option. Despite being written in 2018, I haven’t written an update because nothing changed for a very long time. Despite requests for a native backup solution for Azure Blobs being around for a very long time, nothing happened. However, this is no longer the case; we have a native backup solution for Azure Blobs!
Operational Backup for Azure Blobs, as the feature is called, has been out for a little while, but I’d refrained from writing about it till it is out of preview and ready for use, which it now is, so let’s take a look at how it works.
Use Case
Before we see how to set up Blob backup, it’s important to understand the use case these backups are for. When you enable Blob backup, your blobs are backed up to the local storage account, not into a separate backup vault or another storage account. This backup is intended to protect you against accidental deletion or overwriting of blobs and provide the ability to restore to previous versions. Blob backup is not intended as a geo-redundant backup solution or a DR solution; for this, you would look to the other functions of Azure Blob storage.
Enabling Backup
Despite being a local backup, you still set up and manage Blob backup through the Azure backup centre, which allows you to have a single pane of glass for all your backups. Simply open the backup centre and click add backup. Then, in the wizard that opens, select Azure blobs.
On the next screen, you need to select a backup vault. As mentioned, the blob data is not actually stored in the vault, but the metadata about the backups is.
Next, you need to select a retention policy, determining how long backups are retained. Retention for blob backup is pretty simple; it’s just a single window of time after which backups of blobs older than that will be removed. There are no incremental or differential options here. You can create a new policy to meet your requirements or select an existing one. The default retention when you create a new policy is 30 days.
Next, we select the storage accounts we want to backup. You can add as many storage accounts to the same backup as you want, so long as you are happy that they will all have the same retention period. Once selected, you will need to wait a little while for the storage accounts to be validated.
You will probably find, as I did, that your validation fails because of RBAC permissions. If you do find this, the issue is that your backup vault’s managed identity does not have the “Storage Account Backup Operator” role on your storage account. The wizard will attempt to fix this for you, but you can also avoid the error by doing this in advance.
Once you fix this, you can click “Revalidate”, and it should show as ready.
Finally, we get to a summary page to confirm everything is correct and enable the backup. Once it deploys the backup solution, you can check it configured by going to the “Backup Instances” tab. By default, this shows VM backups, so change the “Data Source Type” dropdown to Azure Blobs. This will then show each storage account that is being backed up and the state it is in.
Backup for blobs is a continuous backup, so there are no backup jobs that run at specific times. So if you look at the storage account in the backup centre, you will see that no jobs have actually run, this is fine. You will also see some text indicating what time your backups are valid from.
Restore
As soon as you have the backup enabled, you can restore it. To do so, go back to the Backup centre Backup Instances section, select the Azur Blobs Data source type, and then select the specific storage account you want to restore from. Next, scroll down to the bottom of the page, and you will find a “Restore Points” section. Use this to select the time you want to restore data from, then click “Restore.”
This will start the restore wizard, which will ask you what data you want to restore. You have three options:
- Restore all blobs in the storage account to this specific point in time
- Restore up to 10 specific containers in the storage account
- Restore up to 10 path prefixes, or specific file paths (this would let you restore a specific file)
You will notice there are a couple of warnings here, which reveal a couple of downsides to this server:
- You can only restore to the same storage account, effectively overwriting the existing version of the files. You cannot restore to a separate location. Obviously, you could always restore back to the current version after the restore, but not ideal if you just want to quickly look at a historical version
- There is a warning that “While restore is in progress, blobs in the storage cannot be read or written”, this is a bit vague. I struggled to understand if that mean just the blobs that are being restored or all blobs in the storage account. Some testing seems to show that I could still upload and edit blobs that are not being restored while the restore is going on, so it seems to just be the blobs being restored. However, this does mean that if you have services that rely on reading those blobs, there may be downtime while they are restored.
Once you set up your restore, you can complete the wizard, and the backup will start. This restore job does show up as a job in backup centre, so you can monitor progress there.
Once the job completes, you should find your files have been restored to the requested time.
Summary
It’s great to finally have a native backup solution for blob storage that works with Azure Backup centre and is really easy to set up and use. There are a couple of areas for improvement, such as restoring to a different storage account, but hopefully, we will see that in the future.
