By the end of this build sheet the share has layered protection you have personally tested: vaulted backup running daily with retention you chose on purpose, a snapshot schedule serving Previous Versions, soft delete confirmed, three alert rules watching throttling, capacity, and backup health, and, the step that separates this sheet from a settings checklist, a completed restore drill at both file and share level with the results written down.
Prerequisites: a production share ([AF 6.x] output or equivalent); Contributor plus Backup Contributor on the resource group; an email or Teams-connected action group target for alerts; and twenty spare minutes inside a change window for the drill, which touches nothing in production but deserves the courtesy of a declared window anyway.
Step 1: Enable vaulted backup with a deliberate policy
Create (or reuse) a Recovery Services vault in the share’s region, then configure backup for the file share with a policy that includes the vault tier, not snapshots alone. Azure Files backup lives in a Recovery Services vault; the newer Backup vault object covers disks, blobs, PostgreSQL and AKS, and pointing at it here is a wrong turn that costs an hour. In the portal the policy is built before the protected item: open the vault, Resiliency, Protection policies, Create policy, and choose the datasource type Azure Files (Azure Storage). Policy values are compliance decisions wearing a schedule; these are my defaults for a departmental estate:
| Setting | Value | Why |
|---|---|---|
| Backup tier | Vault-Standard (vaulted) plus snapshot | The vaulted copy is the isolated, ransomware-surviving one; the snapshot rides along for instant restores. |
| Schedule | Daily, outside business hours | File shares rarely justify sub-daily vault points; snapshots cover intraday. |
| Daily retention | 30 days | Covers the “noticed three weeks late” class of loss, the most common class there is. |
| Monthly retention | 12 months | The audit-season safety net; extend only if compliance names a number. |
| Yearly retention | Per compliance calendar, up to 10 years | Ten years is the platform ceiling; do not promise 99 to anyone. |
az backup vault create -g rg-files-pilot -n rsv-files-eastus -l eastus
# The policy has to exist before you reference it. The CLI creates policies from
# JSON, so start from a built-in one, edit it, and submit it under your own name.
az backup policy list -g rg-files-pilot -v rsv-files-eastus `
--backup-management-type AzureStorage -o table
az backup policy show -g rg-files-pilot -v rsv-files-eastus `
--name DefaultPolicy > dailyvaulted.json
# Edit dailyvaulted.json: set the schedule run time, the vault-standard retention
# durations from the table above, and "name": "DailyVaulted".
az backup policy create -g rg-files-pilot -v rsv-files-eastus `
--policy @dailyvaulted.json --name DailyVaulted `
--backup-management-type AzureStorage
az backup protection enable-for-azurefileshare `
--vault-name rsv-files-eastus -g rg-files-pilot `
--storage-account stvciofiles01 --azure-file-share company `
--policy-name DailyVaultedPowerShell builds the same policy from objects rather than JSON, which I prefer when the retention numbers are going into source control, because the intent is readable without diffing a schedule blob:
$vault = Get-AzRecoveryServicesVault -ResourceGroupName "rg-files-pilot" `
-Name "rsv-files-eastus"
Set-AzRecoveryServicesVaultContext -Vault $vault
$schedule = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType AzureFiles `
-BackupManagementType AzureStorage -ScheduleRunFrequency Daily
$schedule.ScheduleRunTimes.Clear()
$schedule.ScheduleRunTimes.Add((Get-Date -Hour 22 -Minute 0 -Second 0).ToUniversalTime())
$retention = Get-AzRecoveryServicesBackupRetentionPolicyObject -WorkloadType AzureFiles `
-BackupManagementType AzureStorage -BackupTier VaultStandard
$retention.DailySchedule.DurationCountInDays = 30
$retention.MonthlySchedule.DurationCountInMonths = 12
New-AzRecoveryServicesBackupProtectionPolicy -Name "DailyVaulted" `
-WorkloadType AzureFiles -BackupManagementType AzureStorage `
-SchedulePolicy $schedule -RetentionPolicy $retentionExpected result: a protected item in the vault, first backup job queued; run one on demand now rather than waiting for tonight, because Step 5 needs a recovery point. Failure mode with a lesson in it: enabling backup registers the vault against the storage account and takes a delete lock on protected snapshots; if an over-tidy administrator later “cleans up” that registration, backups fail with permission errors, so name the vault’s purpose where tidiness can read it. Note the meter: protected-instance fee per 250 GiB plus vault storage, the [AF 4] line item, now real.
Step 2: Schedule snapshots and verify Previous Versions
The backup policy’s snapshots serve the vault; users deserve a tighter rhythm. Reach for the policy before you reach for code: an Azure Files backup policy supports up to six scheduled backups per day, with the last snapshot of the day transferred to the vault and the others living as share snapshots, which covers the intraday need natively with nothing of your own to maintain. Set those runs at the hours the business actually loses work, typically mid-morning, midday, and late afternoon. Only when the policy genuinely cannot express what you need, an event-driven snapshot immediately before a batch job being the usual case, is an Automation runbook or Logic App calling the share snapshot API the right answer. Then prove the user experience exists: on a mounted client, right-click a folder, Previous Versions, and confirm the snapshots list and open. Two facts to keep in the runbook: two hundred snapshots per share is the ceiling, so a schedule must prune what it creates, and snapshots die with the share, which is why Step 1 exists. On provisioned v2, watch the overflow arithmetic from [AF 4]: snapshot deltas beyond provisioned headroom start a quiet meter, which Step 4’s capacity alert also guards.
Step 3: Verify soft delete, in writing
Soft delete for shares is on by default for new accounts and off in enough inherited estates to be worth thirty seconds: storage account, file service settings, soft delete enabled, retention 14 days or your incident-discovery honesty, whichever is longer. Record the retention in the runbook next to the vault policy, because the three protection layers have three different clocks and the person doing a 2 a.m. restore should not be deriving them from the portal.
Step 4: The three alert rules
Create an action group once (ag-files-ops, email plus Teams webhook), then three alerts. Two are metric alerts on the storage account’s file service, and both depend on getting the dimension right, because a metric alert with a dimension filter that matches nothing is indistinguishable from a healthy estate.
Throttling is not its own metric. It is the Transactions metric filtered on the Response type dimension, and the values that matter differ by billing model. On provisioned v2 the six to watch are SuccessWithShareEgressThrottling, SuccessWithShareIngressThrottling, SuccessWithShareIopsThrottling, ClientShareEgressThrottlingError, ClientShareIngressThrottlingError and ClientShareIopsThrottlingError. On pay-as-you-go the set collapses to SuccessWithShareIopsThrottling, SuccessWithThrottling and ClientShareIopsThrottlingError. Add the File Share dimension as well on provisioned accounts so the alert names the share rather than the account.
Capacity does not need arithmetic. Azure Files publishes Percentage File Share Utilization directly, so the threshold is the number 80 rather than a byte figure you recompute every time somebody changes the provisioned size. Its siblings, Percentage File Share IOPS Utilization and Percentage File Share Bandwidth Utilization, are worth adding once the estate is busy enough to reward the warning before the throttling.
$scope = "$(az storage account show -n stvciofiles01 -g rg-files-pilot --query id -o tsv)/fileServices/default"
# 1. Throttling: any throttled transaction in 15 minutes (provisioned v2 values)
az monitor metrics alert create -g rg-files-pilot -n "files-throttling" `
--scopes $scope `
--condition "total Transactions > 0 where ResponseType includes SuccessWithShareEgressThrottling or SuccessWithShareIngressThrottling or SuccessWithShareIopsThrottling or ClientShareEgressThrottlingError or ClientShareIngressThrottlingError or ClientShareIopsThrottlingError and FileShare includes company" `
--window-size 15m --evaluation-frequency 5m --action ag-files-ops
# 2. Capacity: share above 80% of its provisioned size
az monitor metrics alert create -g rg-files-pilot -n "files-capacity-80" `
--scopes $scope `
--condition "avg PercentageFileShareUtilization > 80 where FileShare includes company" `
--window-size 1h --evaluation-frequency 15m --action ag-files-ops| Setting | Value | Why |
|---|---|---|
| Throttling metric | Transactions, dimension Response type | There is no throttling metric; throttling is a response type on ordinary transactions. |
| Response type values | The six Share*Throttling values on provisioned v2 | Egress, ingress and IOPS throttle independently; watching only IOPS misses two of three. |
| Capacity metric | Percentage File Share Utilization > 80 | Platform-computed against provisioned size, so it survives resizes without an edit. |
| File Share dimension | The share name (provisioned accounts) | Account-level firing tells you something is wrong somewhere, which is not an alert, it is a mood. |
| Metadata ceiling | SuccessWithMetadataWarning, SuccessWithMetadataThrottling | Metadata IOPS have their own ceiling; many-small-file workloads hit it first. |
The third alert lives in the vault, not the metrics: Backup Alerts (or Azure Business Continuity Center) configured to notify ag-files-ops on failed jobs. Tune-out note so the throttling alert survives its first month: bursting absorbs brief storms silently and does not fire this alert; if it fires weekly, that is not noise, that is [AF 4] telling you a dial is set wrong, and the response is provisioning, not a higher threshold. Confirm the dimension values in the metric picker once on your own account before you trust the rule, since the available set depends on whether the account is provisioned v2 or pay-as-you-go, and a filter matching nothing alerts on nothing, forever, quietly.
Step 5: The restore drill
Now make the whole sheet true. File-level first: delete a known test file from the share, restore it from the vault’s recovery point (Restore, Item-level, select the file, restore to original location), and confirm content and ACL both came back; then restore the same file from a snapshot via Previous Versions and note which path was faster, because that answer, snapshots for speed, vault for survival, is the runbook’s triage logic. Share-level second, to an alternate location: full-share restore into a scratch share or directory, spot-check a deep folder’s DACL with icacls, then delete the scratch. Time both drills and write the numbers down; they are your honest RTO, and they will be quoted in the DR review from [AF 7] where the geo story got told without euphemism. The end-to-end pass for the whole build: three protection layers each demonstrated with a real restore, three alerts that have each fired once in a controlled test (throttle a deliberately undersized scratch share if you want the satisfaction), and a one-page runbook naming the clocks, the paths, and the drill dates. Schedule the drill’s repeat on the same cadence as your DR review, because a restore tested once in 2026 is a hypothesis again by 2028.
Azure Files
‹ Previous: [AF 7] Operating Azure Files: Backup, Monitoring, and the DR You Actually Have
Next: [AF 8] The Decision: Replace, Cache, or Keep ›
