Azure Storage is a cloud-based, scalable, and durable data storage system provided by Microsoft. It offers four different data storage options:
- Blobs: Store unstructured data like documents, images, audio, and video.
- Files: Store files made available as SMB or NFS file shares
- Queues: Store messages in a reliable and scalable manner
- Tables: Store key–value NoSQL data
Replication options enable you to make your Azure storage account available in one or many regions, and you can access your data using the Azure Resource Manager (ARM) REST API using many different methods:
- Azure portal
- Azure Storage Explorer desktop app
- Azure PowerShell
- Azure Command-Line Interface (Azure CLI)
- Azure Storage software development kit (SDK) libraries
- Raw ARM REST API requests
In today's post, I'll teach you how to back up your blob and file data in Azure Storage. Note that today, we're concerned with data backup (disaster recovery). By contrast, storage account replication and failover provide multi-availability zones or multi-region high availability.
As I explained in the 4sysops article Azure Recovery Services Vault: Ironing Out the Confusion, Microsoft has two primary backup vaults that support different workloads:
- Recovery Services vault: Hybrid/multi-cloud disaster recovery
- Azure Backup vault: Azure-only workload backup
We'll start by backing up our Azure storage accounts' file service by using the Recovery Services vault. Here's the recipe:
- Create an Azure Recovery Services vault in the same region as the file shares you need to back up.
- In the Recovery Services vault, define a backup policy for the file share.
- Select the file shares to back up.
- Run an initial backup to begin protection.
- Subsequent backups will run according to your defined backup policy schedule.
You can also configure retention policies for backup snapshots and perform restores when necessary.
NOTE: The Recovery Services vault must be in the same Azure region as your file share.
The bad news is that if you have several storage accounts spread across multiple regions, you'll have to pay for multiple Recovery Services vaults. Bummer!
Next, let's back up our Azure storage accounts' blob service by using Azure Backup vault and an Azure feature called operational backup. First, operational backup for blobs is a continuous backup strategy in which blobs are backed up locally in the context of the storage account itself. The solution allows fast and easy point-in-time recovery (PITR).
First, enable operational backup on the data protection blade of the storage account in question. Next, deploy an Azure Backup vault in the same region as your storage account. Although operational backup is a local storage solution, it's orchestrated through the Azure Backup vault.
Assign the Backup vault the Storage Account Backup Contributor role to ensure the vault can reach the account's blob service. Specify your backup policy (maximum retention period is 360 days), choose your storage accounts, and away you go!
I want to repeat that blob service operational backup uses locally redundant storage only. Thus, you'll need to use another technique to back up your blobs in another Azure region.
AzCopy with an automation script or Azure function
AzCopy is a Microsoft command-line utility that enables fast and efficient data transfer between on-premises or cloud-based storage services, including Azure blob, file, and table storage. AzCopy supports data migration, backup, and disaster recovery scenarios.
It can be used to upload and download data, copy data within or between storage accounts, and manage data transfers with features such as resume and retry on failure. AzCopy uses server-side asynchronous data transfer for optimized performance and supports large-scale data transfers with features such as parallel data transfer and network optimization.
In some ways, AzCopy reminds me of the venerable Robocopy command, which I was surprised to find ships natively with Windows 11 nowadays.
Anyway, let's imagine we want to back up all blobs from one storage account in region A to another storage account in region B. We can inject the AzCopy command below into a shell script to automate the cross-region backup.
NOTE: Source and destination Azure storage accounts must belong to the same Azure AD tenant. The client running the automation script must also have network connectivity to both storage accounts.
You also want to think of how you're authenticating AzCopy to Azure. Here are three options:
- Shared Key: Use a shared key to authenticate to Azure storage. This method requires the storage account name and key.
- SAS (Shared Access Signature): Use a SAS token to authenticate to Azure storage. This method requires a SAS token that provides access to a specific resource for a specified period.
- Azure AD authentication: Use Azure AD credentials to authenticate to Azure storage. This method requires an Azure AD account that has been granted role-based access control (RBAC) authorization to the storage account.
azcopy copy 'https://source.blob.core.windows.net/' 'https://destination.blob.core.windows.net' --recursive
You can host your AzCopy automation script anywhere, whether on-premises, in another cloud, or within Azure. Here are a couple of Azure-specific options:
- Automation runbook: Python or PowerShell script that is invoked either manually or on a schedule
- Function: Cloud-hosted code file invoked by a timer or event trigger
- Logic App: Business workflow invoked by a timer or event trigger
Hosting an AzCopy script as an Azure Automation runbook
It wasn't too long ago that we Azure administrators had to use automation scripts to back up the Azure Storage blob and file services. It's cool that Microsoft supports those workloads nowadays via the Recovery Services and Azure Backup vaults.
Subscribe to 4sysops newsletter!
Remember again that Azure Storage backup offers data protection and disaster recovery capabilities but does not address storage account availability. For that, you'll want to configure account replication and learn how to conduct administrator-initiated cross-region failovers.