Azure File Sync and Cloud Tiering
Azure File Sync answers a specific objection to putting file shares in the cloud: latency and protocol compatibility. It caches Azure file shares on an on-premises Windows Server or a cloud VM, centralising the organisation's shares in Azure Files while keeping the flexibility, performance, and protocol support of a local file server. The server becomes a fast cache of the cloud share, and any protocol Windows Server offers — SMB, NFS, FTPS — can serve that data locally.
You can run as many caches as you need, anywhere in the world, all pointing at the same share.
What it works with
Two constraints worth establishing before designing around it:
- SMB shares only. NFS shares aren't supported.
- Classic file shares only. Shares created through the
Microsoft.FileSharesresource provider aren't supported.
The agent
The Azure File Sync agent is a downloadable software package installed on a Windows Server. It bridges the server and the Azure file share, turning the local server into a fast cache of the centralised cloud share.
Cloud tiering
Cloud tiering is an optional feature, and it's the part that makes File Sync interesting rather than just a sync tool. With it enabled, frequently accessed files stay cached locally on the server and everything else is tiered to Azure Files according to policy.
The mechanics:
- A tiered file is replaced locally with a pointer: a reparse point holding a URL to the file in Azure Files. The file name and metadata stay visible; the data doesn't stay local.
- Opening a tiered file transparently recalls its data from Azure Files. The user doesn't need to know, or care, where the file actually lives.
- Tiered files show greyed icons and the offline (
O) file attribute, so it's visible at a glance which files are cloud-only.
The practical effect is that a server with a small local disk can front a share far larger than that disk, with the working set held locally and the long tail in Azure.
What it's for
Application lift and shift. Move applications needing access from both Azure and on-premises, with write access to the same data from Windows Servers and Azure Files simultaneously.
Branch offices. Back up branch office files, and stand up a new server that connects to Azure storage without shipping data around.
Backup and disaster recovery. After implementing File Sync, Azure Backup backs up the on-premises data. File metadata restores immediately and the data is recalled on demand, which makes recovery fast in wall-clock terms even when the dataset is large — you're not waiting for a full restore before the server is usable.
Archiving with cloud tiering. Only recently accessed data stays on local servers; older data moves to Azure Files automatically.
Setting it up
Synchronising a file share with an on-premises server takes three things, and all three are required:
- Create a sync group. The sync group is what manages synchronisation across locations and it defines the Azure file share (the cloud endpoint) and the servers participating (the server endpoints).
- Register the server. Registration establishes the trust relationship that lets the on-premises server communicate with Azure resources.
- Install the Azure File Sync agent on the server. The agent is what actually moves and synchronises files between the two environments.
A note on restores
If you're using Azure File Sync alongside Azure Backup, the two coordinate. When a restore runs, the Backup service tells the sync service which paths are being restored, which triggers a background change detection on those files. Changed files sync down to the server endpoint in parallel with the restore into Azure Files, rather than waiting for it to finish.