Azure will not back up your NFS file share, and will not make it immutable either
The symptom is an absence
There is no stack trace in this post. The failure mode is quieter and more expensive: you design a protection scheme on paper, every component of it is a documented Azure feature, and one by one the components turn out not to apply to your exact combination of service, protocol, resource provider and account setting. Nothing crashes. A blade just does not offer the option you expected, or an option is there and covers less than its name suggests.
The starting point was an Azure Files share exported over NFS, used by Linux workloads, holding data that had to survive both an operator mistake and a deliberate deletion: point-in-time recovery for individual files, plus a copy that nobody with access to the storage account can destroy. The plan was ordinary — Azure Backup for the share, share soft delete as a safety net, an immutable blob container for the long-term copy.
None of those three worked.
The wrong diagnosis: “I have misconfigured something”
The first instinct when a feature does not appear is that permissions are wrong, the region is wrong, or the vault is in the wrong resource group. That instinct burns hours here, because every one of these limits is a support boundary, not a misconfiguration, and the product surface does not distinguish the two. The way to rule one out is to read the support statement for your exact combination. Not “does Azure Backup support Azure Files” — it does — but “does Azure Backup support Azure Files over NFS”. That second question has a different answer, and it governs.
Azure Backup does not support file shares that use the NFS protocol. Both the snapshot tier and the vaulted tier cover SMB shares. There is no policy, no vault type, no preview flag that makes the NFS share appear as a protectable item. The managed backup product is out of scope for this workload — and once you accept that, you stop hunting for a checkbox that does not exist.
Constraint two: soft delete depends on which provider created the share
The fallback was share soft delete: if someone deletes the share, it sits in a recoverable state for the retention period. Soft delete does exist for Azure file shares — just not for all of them.
Share soft delete does not apply to shares created through the Microsoft.FileShares resource provider
(the provisioned v2 model). It is a feature of shares that live under the classic Microsoft.Storage
provider. The practical consequence is blunt: under the newer provider, a deleted share is gone at the
moment of deletion. There is no recovery window and no undelete path.
What makes this dangerous is that the two kinds of share look identical in day-to-day use. You mount them
the same way, you read and write the same files, the data path is indistinguishable. The difference is in
the ARM resource type, and nobody checks that before writing a runbook. So check it explicitly: look at
the resource provider of the share resource itself. If it is Microsoft.FileShares, cross soft delete off
your list of controls. Do not treat “Azure file shares support soft delete” as an answer about your
share.
Constraint three: snapshots are real, but they are not backups
Share snapshots work under both providers and are genuinely useful. Scheduled snapshots give you file-level rollback: someone truncates a file, overwrites a directory, or runs a bad sync, and you restore from yesterday’s snapshot.
But snapshots live inside the storage account, attached to the share. Delete the share and the snapshots go with it; delete the account and everything goes with it. A snapshot is a point-in-time view of the object it is protecting, so it defends against mistakes within the data and never against destruction of the container. Snapshots stay in the design — just not as the answer to “what if the share is deleted”.
Constraint four: the immutable copy cannot live in the same account
The natural next move is to copy the data out of the file share into a blob container in the same storage account and make that container immutable — a WORM policy with a legal hold or a time-based retention policy. Requirement satisfied, in theory.
Blob immutability is not available on storage accounts that have NFS 3.0 or SFTP enabled. The same account feature that lets your Linux hosts mount the share is the one that disqualifies the account from WORM. You cannot have both on one account, so the “keep it all in one place” design is dead on arrival.
A second assumption dies next to it: blob versioning is not supported together with hierarchical namespace (Data Lake Gen2). If your account was created with HNS enabled — common for anything that started life as an analytics store — versioning is not a fallback you can turn on instead. Its absence is announced nowhere in your daily workflow.
One more control in this family fails in the direction of false confidence rather than missing options: Microsoft Defender for Storage does not scan blobs uploaded over NFS 3.0. In the portal the plan shows as enabled on the account. The gap is in the ingestion path, not in the configuration, so nothing in the resource’s state tells you that data arriving by that route is unscanned. A control that looks on and is off for your traffic is worse than one you know you do not have.
The design that survives all four constraints
Three layers, each covering a failure the others do not:
- Scheduled share snapshots on the file share. Fast, cheap, and the right tool for file-level recovery — accidental overwrite, bad deploy, a script that deleted the wrong directory.
- A copy of the data out of the storage account, into a separate account that does not have NFS or SFTP enabled, landing in a blob container with an immutability (WORM) policy. This layer survives deletion of the share, deletion of the original account, and ransomware — because it is outside the same blast radius and cannot be overwritten within its retention period.
- A
CannotDeleteresource lock on the resources that must not disappear. Locks are a control-plane guard: they stop the accidentalaz group delete, the wrong subscription in a terminal, the cleanup script that iterated one level too high.
Remove any one of the three and there is a real scenario it was covering. Snapshots without the external copy lose everything when the account goes. The external copy without locks still lets someone erase the live service. Locks without snapshots leave you with no way to undo a bad file write.
The contrast that makes the rule concrete
It would be easy to conclude “in Azure, backups die with the resource”. Not true either. Azure SQL long-term retention backups survive deletion of the database and of the logical server. They remain restorable within the same subscription — you can list and restore them through the CLI or PowerShell — and they disappear only when the subscription does. Point-in-time restore behaves the opposite way: it is tied to the server, and the moment the logical server is deleted the PITR capability for its databases goes with it.
So within one vendor, and even one service, two backup features have opposite lifetimes. “The backup lives with the resource” is a property of each individual feature, not of Azure, and has to be checked per service.
What to take away
In a managed cloud, protection features are not switches — they are matrices indexed by (service,
protocol, resource provider, account feature). Azure Backup minus NFS. Soft delete minus
Microsoft.FileShares. Immutability minus NFS/SFTP accounts. Versioning minus hierarchical namespace.
Defender scanning minus NFS 3.0 ingestion. Each cell is documented in prose somewhere, and almost none are
enforced where you would notice — the portal shows a feature that is on, or omits an option, and both look
the same as “everything is fine”.
The habit that fixes this is not technical. Before you design a recovery story, write down what each feature does not cover for your exact combination, and keep that list beside the design. Then test a restore — because the day you find a gap by attempting a real recovery is the wrong day to learn the matrix had a hole in it.