Enable immediate sync after changes on the Azure file share for Azure File Sync
When I make a change on my server endpoint (Windows File Server), Azure File Sync initiates a sync session very quickly after file save, however for changes on the cloud endpoint (Azure file share), I have to wait at least 24 hours to have changes get synced down to my server endpoints.
Please invest in features to initiate a sync session immediately after changes are made cloud-side, or at least increase the interval of sync from the Azure file share.
Thanks for your feedback! As you mentioned, we initiate a change detection job once every 24 hours to enumerate the Azure file share and scan for changes. This is required for the Azure file share because Azure Files currently lacks a change notification mechanism like Windows Server has (we watching the USN journal on Windows Server to automatically initiate sync sessions on the server after changes are made).
Long term, we would like to build a change notification mechanism directly into Azure Files. Shorter term, we could use your feedback to understand how painful the once every 24 hours change detection is for you. Please vote and/or leave comments on this item to let us know we should invest in work to make the change detection job run more frequently/faster.
Program Manager, Azure Files
How painful is once every 24 hours?
For my current project this is a deal breaker. I need the changes to be automatically detected every couple minutes OR have automatic detection every couple hours but also have the option to trigger the change detection job myself.
Any updates on when this suggestion will switch from PLANNED to STARTED, and how long it will take to implement? For development I can survive with 24hrs but for production, like I said earlier, this is a deal breaker for me. I need to know if I can plan on this feature being complete by the time I will be ready to start production testing, otherwise I will have to go another route.
Mike Somerville commented
let me be clear tho - i would MUCH RATHER use AZURE for this...
Mike Somerville commented
re: " to understand how painful the once every 24 hours change detection is for you."
For me, its not painful at all. Its disappointing that Azure doesn't understand the needs of the market. I am spending my money with AWS. Because Storage Gateway WORKS!
How painful is that for YOU!?
I vote with my IT budget.
Let me know when you fix this.
A ton of effort has gone into setting this up, and to find out that the sync process occurs 24hr is disheartening, I thought we had a solution, build VM's in Azure have remote users simply accessing Azure, use azure shares to reduce latency of VPN, all users are happy local and remote,,,,, not so fast if it will be 24+ hours for file sync, no collaboration available. Guess we are stuck with VPN for now, or do we find an entirely different product
Please, if you can't figure out near-instantaneous sync like with OneDrive, then at least make a customizable time frame. *Minimum* of 1 hour. More frequently may be desirable in some circumstances. Or a way to force a change detect, even if it's through Powershell for a start.
Rob Ganister commented
100% agree with the previous comment about restoring files and having to wait 24 hours for them to show up. Really a big oversight.
Let me reiterate what is one of the biggest pain points that keeps us from going full production with Azure File Sync. One of the touted benefits is a cloud-based replica of a local file share, and the ability to take advantage of near-instant cloud backups, which is awesome. The problem in this scenario is that restoring files from a vault back into the synchronized storage account means the change only happens on the Azure side. It happens almost instantly, but the restored files are not synchronized back to the on-prem storage for up to 24 hours. The net result is that it takes me up to 24 hours to restore files, which is simply unacceptable for us. Perhaps automatically or manually-triggered after a restore job would be an acceptable workaround. PLEASE help us restore files back into on-prem production in a reasonable amount of time.
Could you make it so that we can trigger the change detection job ourselves?
We are looking at Azure File Sync as a solution for on of our current problems. Down the road we would like to have changes be made to the File Share and then have sync spread those file to our different data centers, basically making Azure our source of truth. We can't do this if the sync is only once every 24 hours.
Our alternative is to create our own sync service. If we were to do that, we plan to look to Azure Event Grid to detect when changes are made to the file share. Couldn't you do something similar?
This is a huge need for our company!!!! 24 hours is too long of a time for any files to be synced. It makes the service not what the name or the description is made out to be.
We are attempting to push our production to Azure and this is an extreme hold back for us using Azure as a whole.
This is a very important feature, that will make several of our use cases viable. As it stands, we will have to have a VM in azure to upload the files to so that it fires the change notifications. It's hardly ideal.
Yogesh S commented
Since this is a critical feature for our business. Waiting for 24 hours for the File Sync to complete is not an ideal option. Could you please provide the Sync feature to be more frequent than the existing 24 hours time frame. Could you lease provide this feature at the earliest ?
Because we are getting several complaints from our customers asking for this feature(The files to be Synced for within 24 hours).
Kindly provide us a time frame or update on this request like when we could expect this option ?
Yogesh S commented
Since this is a critical for business, could you please provide this feature at the earliest ?
Please provide us a ETA for this feature because we are getting several complaints from our customers asking for this feature.
Eric Mucci commented
24 hours makes single item restores from Recovery Vault pretty painful... at minimum could you trigger a detection job for this use case?
Needs to be live synch and not 24 hrs. Anything more frequent than 24hrs is better.
Or at least publish something where we can set the refresh period.
This + AD integration for ACL's are two features critically missing which will likely force us to put in a VM and then DFS-R for something we should have been able to use a service for.
Our use case is hybrid network shares where at the end of our next on prem refresh period we just turn off the local cache servers.
How long do we have to wait to get this feature implemented Microsoft? Such an important thing should be at the top of your list.
Glad I found this issue. this is my story:
Add file to sync'd folder (My server)
File appears on Cloud File Store seconds later (Azure)
Delete file from File Share on Azure Portal (Azure Portal)
The file remained on the source directory, I assumed the sync failed, when I added the file to the local or source directory again it did not appear (sync) in the Azure File Share. I thought that I had somehow put the two folders out of sync and played about for some time testing all sorts.
I guess I would have to wait 24 hours for the files to be sync'd correctly? I wont be deleting the file from Azure but had no idea of this limitation which wasted my time, the portal should have a warning when making changes to files on the cloud side.
Aaron Axvig commented
This is obviously important to make the product have any point at all...
Tomasz Foltman commented
How Painful? this feature is absolutely critical to be any alternative to DFS.
Topher Wilkes commented
Definitely an issue! So I made a change in the cloud but it doesn't sync for 24 hours. If I then make a change on the local server share it syncs the change to the cloud straight away but those older cloud changes STILL don't sync back to the local server... Doesn't even make sense.