Whilst Large efforts have been made to move enterprises away from the use of general purpose file servers to other solutions such as OneDrive and SharePoint, they remain a staple part of most companies’ server estates, providing storage for applications, and halfway houses for solutions such as managed file transfer and FTP to other organizations. File servers do however pose a degree of risk, as without provisioning as highly available pairs they pose single points of failure within some organizations, with minimal consideration given to HA/DR within their implementation. A simple solution to this has now entered Public Preview in the form of Azure File Sync
What is it?
Azure File Sync provides a serverless solution to synchronize the data from multiple file servers in a multi-master model, with synchronization endpoints either being additional servers or within Azure Files (a secure file storage solution within Azure leveraging SMB 3.0 and encryption of data at rest). Within the target servers, Azure file sync exists as a small footprint agent installation, with the orchestration and intelligence hosted as a service within Azure.
As the name suggests, the tool is primarily for synchronizing a disparate estate of file servers, either providing more localized copies of data or high availability. However, alongside this, it provides the opportunity to tier files into Azure storage based on the frequency of their access and subsequently reduce storage requirements. Infrequently accessed files will be transitioned to cloud storage, with a pointer left in the on-premises file system. In the event a user attempts to access one of these files, Azure File Sync will seamlessly recall the file for the user.
In addition to the user facing capabilities of Azure File Sync, it also provides a reduction in administrative overhead in allowing for centralized backup of file data: backups can be taken of the Azure File Storage and recalled as file level restores should this be required. In doing so, the need to backup potentially heavily duplicated data on multiple synchronized file servers is removed.
In the above example, the HR department based in a branch office require access to a particular share within the corporate file server infrastructure: in order to improve their user experience, a local file server has been provisioned and the HR share has been synchronized to it with the use of Azure File Sync. In doing so, users are able to work from a localized copy of the data improving access times, however still have the ability to fall back to the centralized file server infrastructure in the event of a local server outage. It is also worth noting that in this event, once the local server is brought back online, Azure File Sync will instantly update the file/folder metadata of the branch server to allow for access of the latest copies of files from the cloud tiered copies, until data is fully resynchronized.
File Server Migration
Azure File Sync also presents the opportunity to migrate or consolidate file servers: by leveraging the agent to sync data to Azure files, additional file servers can then be attached to this sync group. Once attached to the sync group, users can even be served from the new server instantaneously, relying on pulling files from the cloud tier. Doing so allows for rapid hands-off migrations of data, with the ability to report on synchronization progress throughout, far surpassing legacy tools such as Robocopy and DFS Replication.
Potential Future Usage
Whilst Azure Files does not currently support the use of ACLs in order to limit user visibility of data, this has been confirmed in the roadmap: this offers potentially the largest benefit of Azure File Sync as a migration tool – by allowing for traditional file shares to be transformed to a resilient, serverless backend such as Azure Files, administrative overhead is massively reduced for file shares, alongside the assurance of geo-redundancy of data and rigorous backups through Recovery Services Vaults. When ACLs come into general availability within Azure Files, a strong use case is presented to transitioning the majority of the legacy file estate to such a service. In doing so, costs are reduced, responsibility for patching and maintenance is removed, and resiliency is improved.