In this article, I will share with you how Azure File Sync can replace your DFS Replication (DFS-R) solution to minimize the storage footprint on-premises, operation cost, and provide secure protection for your files against any malicious attack or accidental deletion.
Table of Contents
Introduction
Azure File Sync is a great platform as a service (PaaS) solution, which can help you to centralize your files in the cloud and then install a sync agent on Windows Server on-premises or in Azure (IaaS VM) to provide fast local access to your files. The local file server and Azure are constantly syncing and replicating, so you have one centralized location for your files with multi-site access powered by fast local caches and cloud tiering.
Cloud tiering enables frequently accessed files to be cached locally such that the full file content is present on the server, whereas less frequently accessed files are tiered to the cloud. This is desirable for those files that you are not using very often but you still want them to be around.
Before Azure File Sync was introduced back in July 2018, we used to rely on DFS-Replication (DFS-R) solution to synchronize our files across multiple servers whether for multi-site access or as a disaster recovery solution. While Distributed File System Replication (DFS-R) might be appropriate for basic needs, however, the high-volume environment can expose problems with the solution for maintaining adequate storage capacity, replication issues, as well as high operational overhead.
DFS Replication Replacement
As mentioned in the introduction, Azure File Sync and DFS-R are both replication solutions used for the same purpose, however, in most cases, I recommend replacing DFS-R with Azure File Sync for the following added values:
- Cloud tiering (optional) – store only recently accessed data on local file servers and free up storage space by moving low frequently accessed data to the cloud.
- Quick scale with multi-site access – provide write access to the same data across Windows Server in different branch offices and Azure Files.
- Fast disaster recovery – Replace on-premises file server(s) within a couple of minutes when disaster strikes, restore file metadata immediately and recall data as needed.
- No complicated network is required, you just need internet connectivity to access the replicated files from anywhere.
- Full support of your existing Active Directory (NTFS ACLs) on-premises without any extra steps.
- Get detailed reporting and monitoring (alerting) by leveraging the power of Azure Files and Azure Monitor.
- Azure Backup integration – no need to back up your data on-premises, you can save a lot on storage management, and reduce operational/licensing costs.
- Optimize and reduce storage cost in the cloud by leveraging the new “Transaction Optimized”, “Hot”, and “Cool” tier for your workload.
There are a few scenarios where you would want to use DFS-R and Azure File Sync together, such as:
- Not every on-premises file server needs a copy of your file data to be connected directly to the internet.
- You need to consolidate the branch office server’s data onto a single hub file server, for which you would like to use Azure File Sync.
- Migrating from a DFS-R deployment to an Azure File Sync deployment. In this scenario, you will have both solutions running side by side for a short period until the data is fully migrated to Azure File Sync, and then retire DFS-R.
Protection against Ransomware
As we are seeing today, Ransomware has evolved, and it is targeting file shares, shadow copies, and backups whether the data is on-premises or in the cloud. The good news is you can leverage the power of Azure Backup (PaaS) service to integrate with Azure Files (Sync) to lock down your file share which gives you an extra level of protection against tampering and deletion.
As of writing this article, enabling Azure Backup for Azure File Shares gives you an additional copy in the snapshot (Azure file share). Please remember that Azure File Sync alone is NOT a backup solution, if your data gets encrypted by Ransomware or deleted, Azure File Sync will be happy to sync your corrupted data to Azure as well. However, when you enable Azure Backup you can effectively go back point in time without worrying about cleaning on-premises resources, reinstalling a backup software, and restoring. Also, you get prioritized access to the data in the share via SMB connection to the Azure File Share directly if needed.
Additionally, Microsoft is working on enabling Azure File shares (backup) transfer to Recovery Services Vault instead of relying on share snapshots that remain within the same file share (storage account), this will also give you an additional copy and layer of protection against scenarios where ransomware is taking down the file share because the data will remain protected outside of the file share/storage account, and even if someone (intentionally or not) deleted the snapshots, the data will remain in the Recovery Services Vault to restore from.
Summary
Azure File Sync is more than capable to replace the replication/synchronization portion of DFS-R while adding additional value with several significant features that make an Information Technology department’s job easier.
Azure File Sync extends on-premises file servers into Azure by providing cloud benefits while maintaining performance and compatibility with your existing applications and infrastructure. Azure Files and Azure File Sync give you the ability to share files without the need to deploy the underlying server infrastructure which provides several benefits when building an Azure-based PaaS application.
- Learn more on how Azure Backup Integrates with Azure File Sync – Part I
- Learn more on how Azure Backup Integrates with Azure File Sync – Part II
I hope this article gave you a broad overview of how Azure Files (Sync) can help you overcome high-volume data management and security threats.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
Thanks for the article, I was led to believe that Azure Files does not sync back to a file server except for once a day. Therefore even though the server syncs to Azure instantly, if one makes a change in Azure, that change only replicates back in 24hrs. Would DFS, therefore, have an advantage over Azure Files?
Hello Jake, thanks for the comment.
Yes, correct, if you access Azure file share directly, it won’t sync back to the file server except for every 24 hours.
You could use the following approach to force it to sync back every 1 hour, but this method has some limitations.
With DFS-R, the sync is almost instantly between two or a dozen of file servers, but you need to maintain a full VM in Azure and you won’t get the benefit from cloud tiering and backup as illustrated in this article.
The instant sync for Azure Files is coming, but I don’t have any ETA when it will happen.
Hope this helps!
Hi,
I like your blog, Thank You for all your articles! All what you are describing is so real and tested. I love that approach. Just WOW.
Quick questions about the idea of replacing DFS-R with Azure Files Sync
1) does it work in that way that AFS will sync me files between on-prem servers too ? will it act DFS-R instantly ? (I guess yes, but want to confirm)
2) How the synchronization will happen actually ? will be that flow Server 1 -> Server 3
or Server 1 ->Azure Storage -> Server 3 ? – it is important from performance and costing perspective – as cloud downloads increase bill.
Hi Przemyslaw, thank you for the kind words, really glad the article helped!
To your two questions:
1) Yes, AFS keeps your on-premises servers in sync with each other, so it does replace DFS-R for multi-site access. The difference is it’s not peer-to-peer. Changes go up to the Azure file share first, then down to the other servers. And it’s near-real-time, not instant like DFS-R, so it feels fast but it’s not continuous byte-level replication.
2) The flow is always Server 1 → Azure Storage → Server 3, never server-to-server directly. The Azure file share is the central hub, and every server syncs only with it. So your instinct is right: one change uploads once, then downloads to each other server. The good news is you can make this predictable by deploying the file share with the provisioned v2 billing model instead of pay-as-you-go. With provisioned v2 you pay for the storage, IOPS, and throughput you provision, and transaction costs no longer apply, which removes the unpredictable churn-driven charges that AFS would otherwise generate. Just keep in mind that egress (download) costs still apply separately, so cloud tiering recalls will still pull data down. Microsoft now recommends provisioned v2 for all new deployments anyway, so it’s a solid default.
Hope this helps!