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
For me, even just being able to manually trigger the sync via PowerShell or from the console would go a long way and should be straightforward to implement. I need to be able to initiate a sync on another server if the primary one fails. Ideally they would always be synchronized, but kicking off a sync job would be a great first step.
Any updates on this? Would love to have a sync frequency at least at 4 hours.
Stefan He commented
So far, the only way I've found to pull a file from Azure Cloud is to create a duplicate file over 26kB with the matching name. This seems to cause a conflict and causes the FileSynced server to pull down the version on the cloud with a -Cloud appended to its name.
So if I have "Example.csv" uploaded on the cloud. I can create a file called "Example.csv" on the server.
This causes the file sync to pull "Example - Cloud.csv" from the cloud.
Then you just delete "Example.csv" and rename "Example - Cloud.csv" to "Example.csv"
Microsoft - any update on when this will be delivered? My product won't move to this until this issue is resolved. No updates or a possible release schedule is only hurting yourselves as we look for alternatives elsewhere. We can't wait forever...
Tim Ellis commented
How painful? Here's a scenario for you.
Field Employee says: "Hey boss did you get the contract I just put in azure files? It needs to be reviewed and signed right away."
Boss: "Sorry I have to wait 24 hrs to get the file on our local server."
Field Office: "Okay I'll just hand deliver it because it is faster."
Do you see the problem here? You can snail mail something in 24 hrs. How painful is it? What a silly question.
Dou Yan commented
How painful? pretty pretty pretty pretty much!!!!
I don't believe Microsoft doesn't enable it.
It's a must have basic requirement.
Peter Young commented
We'd like Microsoft to address this problem asap. It's not a big job for MS but it really improve the user experience a log.
Yong Peng commented
Need this to be implemented as soon as possible. It's quite painful to wait until 24 hours, especially for mass files processing.
I 'd like to sync those changes down to endpoints immediately. Its painful to wait 24 hrs...
I have clients that write to an Azure File Share and would like to sync those changes down to endpoints. Its painful to waif 24 hrs... need this done much sooner!
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.