Azure Files & Backup

Shared file shares and data protection.

Every office used to have one. The beige tower humming in a cupboard under the stairs, serving the \\fileserver\shared drive that everyone mapped on their first morning and nobody dared reboot. Azure Files is that machine with the hardware taken away: a fully managed file share you mount over the network exactly like the old drive letter, while Microsoft owns the disks, the patching and the 3 a.m. RAID rebuilds (RAID means redundant array of independent disks, the trick of pooling several drives so one dying does not take the data with it). A share full of payroll spreadsheets is only worth as much as your ability to get it back, so Azure Backup rides along beside it: a managed insurance policy that takes recovery points on a schedule and keeps them as long as you say. The previous lesson covered blobs, which applications reach over HTTPS. Files exists for everything that still expects a real *file system*.

What Azure Files is, and when to reach for it

Azure Files hands out shares over SMB (Server Message Block, the file-sharing protocol Windows has spoken since the 1990s, now at encrypted version 3.1.1) and NFS 4.1 (Network File System, the Unix equivalent, premium tier only and reachable only from inside a virtual network). Here is how it differs from the storage you already met. A *managed disk* is a private drive bolted to exactly one virtual machine. A *blob container* is a bucket of objects behind an HTTPS interface, with no real folders and no file locking. A *file share* is a genuine file system, and dozens of clients can mount it at the same time: virtual machines, containers, servers still sitting in your own building. Directories work. Locking works. So do ACLs (access control lists, the per-file rules about who may read or write). That makes it the obvious home for lift-and-shift apps that expect a UNC path (Universal Naming Convention, the \\server\share style address), for user profiles and home directories, and for configuration that several machines read at once. Standard shares live in a StorageV2 account on spinning HDD (hard disk drive) storage and bill you per use. Premium shares need a dedicated FileStorage account on SSDs (solid-state drives) and bill *provisioned* capacity: you pay for what you reserve rather than what you store, and you get predictable low latency in return. Either way, one share stretches to 100 TiB (tebibytes, the binary-counted cousin of terabytes). Microsoft's newer *provisioned v2* accounts bring provisioned billing to standard HDD shares and lift that ceiling to 256 TiB. Know they exist. The classic pair above is what AZ-104 actually tests.

# resource group + standard storage account (StorageV2 = general purpose v2)
az group create --name rg-files --location northeurope --output none
az storage account create \
  --name stcontosofiles --resource-group rg-files \
  --location northeurope --kind StorageV2 --sku Standard_LRS \
  --min-tls-version TLS1_2
 
# create the share via the management plane (share-rm = ARM, no account key needed)
az storage share-rm create \
  --resource-group rg-files --storage-account stcontosofiles \
  --name projects --quota 1024 --access-tier TransactionOptimized
# {
#   "accessTier": "TransactionOptimized",
#   "name": "projects",
#   "shareQuota": 1024,
#   ...
# }
 
# premium instead? --kind FileStorage --sku Premium_LRS (provisioned billing)

Mount it like it's 1999 (but encrypted)

A mount needs credentials, and you get two routes. The quick one is the storage account key, a long string that behaves like the root password for the whole account: hand it to someone and they own every share and every blob in it. That is exactly why production shares should use *identity-based access* instead. You join the storage account to Microsoft Entra Kerberos (Kerberos is the ticket-based sign-in protocol Windows domains have used for decades, and Microsoft Entra ID is the service that used to be called Azure AD) or to on-premises AD DS (Active Directory Domain Services, the domain controller sitting in your own server room). Then people sign in as themselves and NTFS-style permissions apply file by file, NTFS being the Windows file system whose rights are set per file and per folder. AZ-104 expects you to know both routes, and to know the key is the fallback rather than the goal. Traffic runs over TCP port 445, and the encryption built into SMB 3.x (version 3.1.1 on current clients) is the only reason mounting across the public internet is permitted at all. Older, unencrypted SMB versions get refused unless you deliberately weaken the account by switching off secure transport.

# fetch the account key (root credential — prefer identity auth in prod)
KEY=$(az storage account keys list \
  --resource-group rg-files --account-name stcontosofiles \
  --query "[0].value" --output tsv)
 
# Linux: mount over SMB 3.1.1 (needs the cifs-utils package)
sudo mkdir -p /mnt/projects
sudo mount -t cifs //stcontosofiles.file.core.windows.net/projects /mnt/projects \
  -o vers=3.1.1,username=stcontosofiles,password=$KEY,dir_mode=0777,file_mode=0777,serverino,nosharesock,actimeo=30
 
df -h /mnt/projects
# Filesystem                                       Size  Used Avail Use% Mounted on
# //stcontosofiles.file.core.windows.net/projects  1.0T     0  1.0T   0% /mnt/projects
 
# Windows: test reachability first, then map a drive
# PS> Test-NetConnection stcontosofiles.file.core.windows.net -Port 445
#     TcpTestSucceeded : True
# PS> net use Z: \\stcontosofiles.file.core.windows.net\projects /user:localhost\stcontosofiles <key>
#     The command completed successfully.

Azure File Sync: keep the cloud copy, cache it locally

If a branch office already runs a Windows file server, Azure File Sync turns it into a cache rather than a rival. The local server becomes your fridge and the Azure share the supermarket: this week's food stays close to hand, everything else gets fetched on demand. You install the sync agent on Windows Server, register that server with a Storage Sync Service, then build a *sync group*: one cloud endpoint (the Azure file share, which is the source of truth) plus one or more server endpoints (local folders that replicate to it). Cloud tiering then pushes cold files off the local disk and leaves reparse-point stubs behind, little placeholders that pull the real file back from Azure the moment somebody opens it. A server with 500 GB of disk can therefore present a 5 TB share where only the hot files are truly local. Staff keep LAN speed (local area network, the fast wiring inside the building) on the files they touch daily, and Azure holds the durable, backed-up copy. The costs: Windows Server only, and a pause the first time anyone opens a tiered file. For the exam, learn the chain by heart: *agent → registered server → sync group → cloud endpoint + server endpoints*.

Protecting the share: snapshots plus a vault

Protection starts with share snapshots, read-only photographs of the share at one moment, stored *inside the same storage account* right next to the live data. You get up to 200 per share and you pay only for what changed between them. Taking one by hand before a risky change is a good habit, but habits are not strategies, so Azure stacks Azure Backup on top. Backup needs a Recovery Services vault: a management resource that must sit in the *same region* as the storage account, holding your backup policies (a schedule plus a retention period) and the bookkeeping for every recovery point. On the *snapshot tier*, a file-share "backup" is really the vault telling the storage account to take snapshots on schedule and to delete the expired ones. No file data ever crosses into the vault, only references and metadata, which is why those jobs finish in seconds. The *vaulted tier*, now generally available, goes further and copies changed data into the vault itself, so your recovery points outlive the storage account even if somebody deletes it. Turning on backup also turns on soft delete for file shares on that account, with 14 days of retention, so a deleted share sits in a recoverable state instead of evaporating. One cost lever bites harder than the rest: vaults default to geo-redundant backup storage (copies kept in a second region), and that redundancy setting locks the moment you protect your first item. Decide before, not after.

# 1. one-off snapshot — instant, differential, lives with the share
az storage share snapshot --account-name stcontosofiles --name projects \
  --account-key $KEY
# { "snapshot": "2026-07-13T09:15:22.0000000Z", ... }
 
# 2. Recovery Services vault — must be in the SAME region as the storage account
az backup vault create --resource-group rg-files \
  --name rsv-files-neu --location northeurope
 
# cost lever: vault defaults to GRS — downgrade BEFORE protecting anything
az backup vault backup-properties set --resource-group rg-files \
  --name rsv-files-neu --backup-storage-redundancy LocallyRedundant
 
# 3. protect the share; DailyPolicy = a file-share policy in this vault
#    (e.g. daily 01:30 UTC, 30-day retention — create once via portal or
#     `az backup policy create --backup-management-type AzureStorage ...`)
az backup protection enable-for-azurefileshare \
  --resource-group rg-files --vault-name rsv-files-neu \
  --storage-account stcontosofiles --azure-file-share projects \
  --policy-name DailyPolicy
 
# 4. don't wait for the schedule — take a recovery point now (dd-mm-yyyy)
az backup protection backup-now \
  --resource-group rg-files --vault-name rsv-files-neu \
  --container-name stcontosofiles --item-name projects \
  --backup-management-type AzureStorage --retain-until 13-08-2026
 
az backup job list --resource-group rg-files --vault-name rsv-files-neu -o table
# Name      Operation        Status     Item Name  Backup Management Type    Start Time UTC                    Duration
# 8f31c...  ConfigureBackup  Completed  projects   AzureStorage              2026-07-13T09:29:41.512013+00:00  0:00:31
# a90d2...  Backup           Completed  projects   AzureStorage              2026-07-13T09:31:02.113224+00:00  0:00:24

Restore, and prove that you can

Restores come in two sizes: the whole share, or an item-level restore that pulls back a single file or directory. The second is the one you will actually use, on the Tuesday afternoon somebody saves over the quarterly report. You list the recovery points, pick one, and restore either in place or into a different share. Two definitions carry real weight, in the exam and in your incident reviews alike. RPO is the recovery point objective: how much work you can afford to lose, a number your backup frequency quietly decides for you. RTO is the recovery time objective: how long the business will tolerate waiting while you put the data back. A daily snapshot policy hands you a worst-case RPO of 24 hours. If the finance team goes pale at that, snapshot more often. Then rehearse. An untested backup is a theory, not a safety net, so restore into an alternate share on a schedule and compare what comes back. One boundary for the rest of the course: virtual machine backup, cross-region restore and Site Recovery belong to the later *Backup, DR & updates* lesson. Here, the file-share layer is yours.

# list recovery points for the share
az backup recoverypoint list \
  --resource-group rg-files --vault-name rsv-files-neu \
  --container-name stcontosofiles --item-name projects \
  --backup-management-type AzureStorage --workload-type AzureFileShare -o table
# Name                Time                       Consistency
# ------------------  -------------------------  --------------------
# 932891234567890123  2026-07-13T09:31:04+00:00  FileSystemConsistent
 
# item-level restore: pull back ONE overwritten file, in place
az backup restore restore-azurefiles \
  --resource-group rg-files --vault-name rsv-files-neu \
  --container-name stcontosofiles --item-name projects \
  --backup-management-type AzureStorage --workload-type AzureFileShare \
  --rp-name 932891234567890123 \
  --source-file-type File --source-file-path "reports/q2-summary.xlsx" \
  --restore-mode OriginalLocation --resolve-conflict Overwrite
 
# whole-share rehearsal restore to a DIFFERENT share (safe test pattern):
# target share must already exist, in an account in the vault's region
#   az backup restore restore-azurefileshare ... \
#     --restore-mode AlternateLocation --resolve-conflict Overwrite \
#     --target-storage-account stcontosofiles \
#     --target-file-share projects-restore --target-folder restored

Be honest about the bargain. Azure Files buys you a file server nobody has to maintain, and charges you in per-operation billing, port-445 reality checks and identity plumbing. Snapshots buy near-instant recovery points that live *with* the data they protect, which is why the vaulted tier, or geo-redundant backup storage, is what saves you when a whole account disappears. Look at the hardening still left on the table and notice how much of it is network work: private endpoints, restricting 445, deciding which subnets may reach the share at all. That is where the course goes next, into virtual networks and NSGs (network security groups, the per-subnet firewall rules in Azure), the layer that every mount command above quietly crossed.

Put it plainly: for a lot of lift-and-shift work, Azure Files is a straight swap for the old file server. Same path habits, same drive letter, Microsoft running the disks. You can mount from your own building over VPN or ExpressRoute, or from Azure virtual machines. Three access stories matter and you should be able to tell them apart: account keys, identity-based authentication through Microsoft Entra Domain Services or AD DS, and share-level RBAC (role-based access control, where a role grants a named person or app read or write on the share). Pick identity-based whenever the environment lets you.

Backup is its own product, with its own vaults and policies, not a checkbox on the storage account. Recovery Services vaults hold backup data plus Site Recovery metadata. Backup vaults are the newer container used for some workload types. Soft delete on the vault matters more than it sounds: it slows down the attacker who encrypts production and then goes hunting for the backups. And practice the restore. A backup you have never restored is a guess, not a control.

Try this

Build the small version of everything above. Create an Azure file share on a storage account, write down the SMB endpoint it gives you, then create a Recovery Services vault and enable backup for that share. If file-share backup SKUs (stock keeping units, Azure's word for a service tier) are not on offer in your region, point the vault at a lab virtual machine instead.

RG=rg-lab-files
az group create -n $RG -l eastus
az storage account create -g $RG -n contosolabfs$RANDOM -l eastus --sku Standard_LRS --kind StorageV2
SA=$(az storage account list -g $RG --query "[0].name" -o tsv)
az storage share-rm create --storage-account $SA -g $RG -n teamshare --quota 100
az storage share-rm list --storage-account $SA -g $RG -o table
 
az backup vault create -g $RG -n rsv-lab -l eastus
az backup vault list -g $RG -o table

$ az storage share-rm list --storage-account contosolabfs1234 -g rg-lab-files -o table
Name       Quota
---------  -----
teamshare  100
 
# Sample output
$ az backup vault list -g rg-lab-files -o table
Name     Location
-------  --------
rsv-lab  eastus

Takeaway

The line to carry out of here: Azure Files gives you SMB and NFS shares with no file server virtual machine to look after, and Azure Backup, working through a Recovery Services vault, snapshots those shares and virtual machines on a policy you write yourself.

Next: write a backup policy with a retention period you could defend to an auditor without flinching, run an on-demand backup, then prove the whole thing by restoring into an alternate location.

Related