4.6 Azure Files, Snapshots, File Sync, and AzCopy

Managed file shares and operational tools

Azure Files gives administrators SMB and NFS file shares without managing file servers. Standard shares are capacity based and fit many general workloads. Premium shares are provisioned and often selected when applications need low latency or predictable throughput. Before creating a share, decide protocol, redundancy, quota, identity model, network path, backup or snapshot strategy, and whether clients will mount Azure directly or use a Windows Server cache through Azure File Sync.

Share snapshots capture a point-in-time, read-only view of a file share. They are useful before maintenance, migrations, or risky application changes. You can browse snapshot contents and restore files by copying them back. Snapshots consume storage for changed data and must be managed. They are not the same as Azure Backup policy management, which provides scheduled protection, retention, and restore operations through a vault-backed experience.

Portal path for snapshots: Storage account > Data storage > File shares > select share > Snapshots > Add snapshot. To restore, browse the snapshot, select files or directories, and copy them back to the active share. For Azure Backup, use Backup center or Recovery Services vault integration, then configure backup for Azure Files and choose a policy.

Azure File Sync is used when Windows Servers need to keep local access while Azure Files becomes the central cloud endpoint. Core components include Storage Sync Service, sync group, cloud endpoint, registered server, and server endpoint. Cloud tiering can keep frequently used files local while tiering cold file content to Azure, leaving namespace pointers on the server. This helps branch offices with limited disk capacity, but it requires planning for recall behavior, antivirus exclusions, and server health.

A typical deployment sequence is: create a storage account and Azure file share, create a Storage Sync Service in the same region as the storage account where appropriate, install the Azure File Sync agent on Windows Server, register the server, create a sync group, add the Azure file share as the cloud endpoint, and add one or more server endpoints. Do not place overlapping server endpoints on the same server path. Watch sync health, free space, and tiering policy.

AzCopy is a command-line tool for moving data to and from Azure Storage. It is not limited to one service, and it is common in migration and operations tasks. Authentication can use Microsoft Entra login for supported operations or SAS URLs. For repeatable jobs, avoid long-lived SAS tokens and avoid writing secrets into shell history. Use managed identity where the execution environment supports it and AzCopy supports the target scenario.

AzCopy examples:

azcopy login

azcopy copy './reports' 'https://staz104prod01.blob.core.windows.net/reports' --recursive=true

azcopy copy 'https://stsource.blob.core.windows.net/raw?<sas>' 'https://stdest.blob.core.windows.net/raw?<sas>' --recursive=true

azcopy sync './content' 'https://staz104files01.file.core.windows.net/site?<sas>' --recursive=true

Use copy when you want to transfer source objects to a destination. Use sync when the destination should reflect source differences. Be careful with sync delete behavior and test with a small path before running broad jobs. For data migrations, plan permissions, firewall rules, private endpoint routing, throughput, retries, logging, and whether preserved metadata matters.

Troubleshooting Azure Files starts with mount path and protocol. For SMB, confirm TCP 445, DNS, identity or key credentials, storage firewall, private endpoint subresource file, share quota, and NTFS permissions. For NFS, confirm the account and share support NFS, network restrictions are configured because NFS access is network based, and clients mount from allowed networks. For performance issues, inspect share tier, provisioned size for premium, IOPS and throughput limits, client latency, and whether Azure File Sync tiered files are being recalled over a slow link.

Troubleshooting File Sync has its own pattern. If files do not appear in Azure, check agent health, server registration, sync group membership, server endpoint path, conflict files, and errors in the FileSyncSvc event logs. If a user opens a tiered file and it takes a long time, that may be recall from Azure rather than an application defect. If free space keeps dropping, review cloud tiering policy and volume free space policy. If antivirus scans recall every tiered file, configure exclusions according to product guidance.

Case scenario: a branch office has a local Windows file server with 4 TB of files, but only 15 percent is active. Users need LAN-speed access at the branch, headquarters needs central backup, and the company wants cloud-based disaster recovery. Azure File Sync with cloud tiering is a better fit than asking every user to mount the Azure file share directly across the WAN. Add Azure Backup for the file share, monitor sync health, and test restore. If the scenario instead says a one-time migration of 500 GB of blobs from a local folder is needed, AzCopy is the more direct tool.