Azure File Share Backup via Recovery Vault

Azure Backup for Azure file shares provides a fully managed, cloud-native backup solution that uses snapshot-based backups stored in a Recovery Services Vault. Unlike traditional backup agents, this method requires no infrastructure on your end—Azure Backup orchestrates the entire process. The backup is application-consistent for file shares because it captures the state of the file share at a point in time using Azure file share snapshots, which are a feature of Azure Files.

Before Azure Backup integrated with file shares, administrators had to use Azure Backup Server (MABS) or custom scripts to back up file shares. The native solution simplifies this: you configure a backup policy directly from the Azure portal or CLI, and Azure Backup takes care of scheduling, retention, and restoration. The vault itself is a storage container that holds recovery points and backup policies. It is region-specific and can protect multiple file shares across storage accounts in the same region.

When you enable backup on an Azure file share, the following occurs: 1. Registration: The storage account containing the file share is registered with the Recovery Services Vault. This creates a connection using a managed identity assigned to the vault. The vault gains permissions to read and write snapshots on the storage account. 2. Policy Assignment: You assign a backup policy to the file share. The policy defines the backup schedule (frequency: daily or hourly) and retention rules (how long to keep daily, weekly, monthly, yearly snapshots). 3. Initial Backup: Azure Backup triggers a full snapshot of the file share immediately after policy assignment. This snapshot is stored as a recovery point in the vault. 4. Incremental Backups: Subsequent backups are incremental—only changes since the last snapshot are captured. Azure Backup uses the snapshot differential feature of Azure Files to compute changes efficiently. 5. Recovery Point Creation: Each backup creates a recovery point that includes the snapshot data and metadata (file names, timestamps, permissions). These recovery points are stored in the vault's storage, which is geo-redundant by default (GRS) unless you choose LRS or ZRS. 6. Retention Management: Azure Backup automatically deletes recovery points based on the retention policy. For example, if you set daily retention to 30 days, snapshots older than 30 days are purged.

Using Azure CLI:

# Create a Recovery Services Vault
az backup vault create --resource-group MyRG --name MyVault --location eastus

# Enable backup on a file share
az backup protection enable-for-azurefileshare \
    --resource-group MyRG \
    --vault-name MyVault \
    --storage-account MyStorageAccount \
    --azure-file-share MyFileShare \
    --policy-id $(az backup policy list --resource-group MyRG --vault-name MyVault --query "[?name=='DefaultPolicy'].id" -o tsv)

# List recovery points
az backup recoverypoint list --resource-group MyRG --vault-name MyVault --container-name MyStorageAccount --item-name MyFileShare

# Restore to alternate location
az backup restore restore-azurefileshare \
    --resource-group MyRG \
    --vault-name MyVault \
    --container-name MyStorageAccount \
    --item-name MyFileShare \
    --rp-name "<recovery-point-id>" \
    --resolve-conflict Overwrite \
    --restore-mode AlternateLocation \
    --target-storage-account TargetStorageAccount \
    --target-file-share RestoredShare

# View backup job status
az backup job list --resource-group MyRG --vault-name MyVault

Using Azure PowerShell:

# Enable backup
Enable-AzRmStorageShareBackup -ResourceGroupName MyRG -VaultName MyVault -StorageAccountName MyStorageAccount -Name MyFileShare -Policy $policy

# Get recovery points
Get-AzRecoveryServicesBackupRecoveryPoint -VaultId $vault.ID -Item $item

# Restore
Restore-AzRecoveryServicesBackupItem -VaultId $vault.ID -RecoveryPoint $rp -StorageAccountName TargetStorageAccount -FileShareName RestoredShare

A financial services company must retain file share backups for 7 years to meet regulatory requirements. They configure a Recovery Services Vault with a custom policy: daily backups retained for 30 days, weekly for 52 weeks, monthly for 36 months, and yearly for 7 years. This totals approximately 30 + 52 + 36 + 7 = 125 snapshots, well under the 200 limit. They choose GRS replication for disaster recovery. In production, they monitor backup jobs via Azure Monitor and set alerts for failures. A common issue is that the storage account firewall blocks the vault; they resolve it by adding the vault's managed identity to the firewall allow list. They also use Azure Policy to enforce that all new file shares are automatically backed up with this policy.

An engineering firm uses a file share for real-time collaboration on CAD files. They require hourly backups to minimize data loss. They create a custom policy with hourly frequency every 4 hours and retain hourly backups for 24 hours, daily for 30 days, and weekly for 12 weeks. Because the file share is large (5 TiB), they ensure the storage account is in the same region as the vault to reduce latency. They also enable soft delete to protect against accidental backup deletion. A challenge they face is that the file share has frequent changes, causing incremental backups to be large; they monitor backup storage consumption and adjust retention as needed.

A global company uses Azure File Sync to sync file shares across multiple regions. They back up the central file share in the primary region using Recovery Services Vault. In the event of a regional disaster, they can restore the file share to a new storage account in the secondary region using the alternate location restore. However, they must first ensure the secondary region has a vault (they replicate the vault using Azure Backup's cross-region restore feature, which is currently in preview for file shares). They also use Azure Traffic Manager to redirect users to the restored share. A common mistake is thinking that the vault itself can be failed over; in reality, you must restore the data to a new vault in the target region.