For years, backing up Azure Files meant snapshots kept in the very same storage account. I've run into that gap in plenty of customer environments. If someone deleted the storage account, or ransomware got to that layer, the backups disappeared along with the data. Azure Files vaulted backup changes this, and we finally have a proper backup. Copies of your file shares are stored independently in a Recovery Services vault, which protects you against accidental deletion as well as attacks carried out with broad permissions.
Vaulted backup keeps a copy of the share outside the storage account
Snapshots live inside the storage account. Azure Files vaulted backup instead writes a copy of your share to a separate Recovery Services vault. That's a big step forward. Even if the whole storage account is deleted or compromised, your backups stay intact, as long as the vault itself is protected with soft delete and immutability. I've seen tenants where someone deleted a resource group by mistake, or where storage accounts became unreachable after a misconfiguration. Without a vaulted backup, losing the data took one click. With this option you can restore shares reliably even in the worst case, provided the Recovery Services vault is locked down properly.
The diagram below compares the snapshot model with vaulted backup:
flowchart LR
A["Azure file share"] --> B["Snapshot backup (storage account)"]
A --> C["Vaulted backup (Recovery Services vault)"]
B -.-> D["Only safe if account exists"]
C --> E["Independent protection (even if account deleted)"]
Figure: With vaulted backup, the data sits outside the storage account in the Recovery Services vault.
Setup covers the vault, the policy and locked-down access
You start in whichever Recovery Services vault you want to use, so think about resource group and region before you commit. In the vault, go to Backup → Azure Files (Azure Storage). The step that matters most is choosing the Vault-Standard tier in the backup policy. Only then is the backup data physically stored in the vault and not just kept as snapshots in the source account. In the policy dialog you set daily, weekly, monthly and yearly retention to match your business and compliance requirements.
A few things I secure on the Recovery Services vault as soon as it exists:
- Enable soft delete (it's on by default, but check it anyway)
- Enable immutability (set in the portal, and it can't be turned off later)
- Use RBAC to restrict what backup operators are allowed to do
With immutability in place, not even privileged admins or operator accounts can delete or modify backup data.
Practical tip: Once the vault is set up, I check soft delete and immutability, then do a quick restore to a non-production share to confirm the policy and the process work.
Restore tests show whether the backup actually works
A backup is worth exactly as much as your ability to restore it when things are going wrong. You restore Azure Files vaulted backups from the Recovery Services vault under Backup Items → Azure Storage (Azure Files). From any recovery point you can bring back a single share or several, either overwriting the original or restoring to a new share. How long it takes depends on data size and vault load, and large shares can need several hours. I recommend a restore test to a non-production share every quarter. A real incident is the worst moment to find out your process has holes.
The full list of limitations and details is in Microsoft's Azure Files backup overview and the guide to backing up Azure Files.
Retention and churn drive the cost of vaulted backup
Vaulted backup will always cost more than snapshots. You pay for storage in the Recovery Services vault, and with longer retention or high churn, bandwidth and transaction costs grow as well. If you back up many file shares with long retention, watch vault usage and adjust the policies when needed. Deleting old recovery points doesn't necessarily lower costs right away, because data stays protected for as long as the retention policies apply. I rely on the vault's storage consumption pane in the Azure portal for this, and Azure Cost Management gives you solid reporting for ongoing analysis.
Vaulted backup has improved audit results in my projects so far
Since I started enabling vaulted backup for Azure Files, audit results have clearly improved, and both IT and security teams trust the setup more. Protecting the Recovery Services vault with soft delete, immutability and RBAC is now the minimum I expect. If a production workload depends on Azure Files, every share should have vaulted backup turned on. It's not complicated as long as you plan your policies and schedule restore tests regularly. If you're also dealing with hybrid authentication and permissions on Azure Files, take a look at my earlier post on Azure Files with Entra Kerberos for hybrid identities.
My view is simple. A backup that lives in the same storage account isn't really a backup, and vaulted backup finally brings Azure Files up to enterprise standard.


