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
Mike Emard commented
There is now a PowerShell cmdlet you can use to trigger sync to happen on files that were just added to the cloud share directly. https://docs.microsoft.com/en-us/powershell/module/az.storagesync/invoke-azstoragesyncchangedetection?view=azps-2.5.0
Bill Tyler commented
I have been using Azure Files over API access for some time and my usage has grown to the point that the limited number of SAS tokens is a real issue. There is even an issue with adding and removing tokens affects transfers in progress.
I was really looking forward to File Sync being a better option with files transferring in the background in near real time. I set it up and have been testing and just discovered the 24 hours sync schedule. This makes it a no starter. any update on when this will be resolved.?
We have a file transfer solution which uses REST API to push a file into an Azure Files Share. Ideally this would trigger an Azure Files Sync update to ensure our Server Endpoints were in sync. Updating every 24 hours is far too large a timeframe for our use-case, so the lack of this feature has meant we cannot use Azure File Sync for our solution. Instead of our application referencing a local drive on the server we instead need to rely on a flakey network drive mapping to Azure Files Share and using CMDKEY to store credentials - very messy!
Kevin Svec commented
Our firm will be utilizing a DaaS solution where half of our users will be on-prem and the other half on a virtual desktop located in Azure. We really need to be able to keep our files synchronized in real time between our on-prem file server and the Azure File Sync cloud location. While the virtual desktop people will see the changes made by on-prem users almost immediately, the on-prem users won't be able to see the virtual desktop user's changes for 24 hours. This is unacceptable and unreasonable. Steal some of the technology used for OneDrive and bring it into Azure File Sync!
Hey Sebastian - Did you retest since 7.0.0? https://docs.microsoft.com/en-us/azure/storage/files/storage-files-release-notes#agent-version-7000
Improved Azure Backup file-level restore
Individual files restored using Azure Backup are now detected and synced to the server endpoint faster.
Any update on this? We're looking at Azure File Sync. The scenario we have is where the files get corrupted on premise and we need to restore them from the Azure Backup. Waiting 24 hours is too long, and we may have to find a different solution if we can't get this to work.
Hey Chris- Expected and semi-related behavior. Obviously not ideal but the full share restore topic has more moving pieces than what this request is about. Once a restore is complete the server endpoint is blocked from syncing the share until a full charge detection job is completed where duration is based on the number (!!) of files in the share (I forget the published rate, my latest example was 5hrs for 190k files). To me this is the more significant issue, particularly when paired with Recovery Vault’s “speed”....
Chris Martin commented
This is a similar issue...
We are testing the restore of an entire file share to a server endpoint.
We found that it restored the file structure to the endpoint within minutes, but it took over 24 hours for the files to be visible and accessible on the server endpoint.
Is this normal behavior or am I missing something?
Junwei Huang commented
Instant sync up is very important when multiple sync servers exist.
Or why "Azure File Sync" can be named "Sync" for 24h of interval?
We use Azure file share to store configuration files. I can't imagine that we have to wait 24h in order to be able to reload the new configuration. This is a blocker.
Microsoft please prioritize. It makes Azure file sync useless to mobile users. Crazy for a cloud data storage service.
C'mon Microsoft what's the point of UserVoice when one of your main requests hasn't had an update in 18 months?
JB Lewis commented
The change notification mechanism would be greatly helpful in a lot of ways, like making it possible to trigger Azure Automation runbooks based on changes in an Azure File Share!
Please make it happen!
to auto detect changes in file storage is a must to send files through on premise and then forward on through file storage to SFTP method , at present we have 2 scheduled jobs one either end which Is not ideal and can miss the files being created.
This is key feature which makes many of the lift & shift scenarios to be build in better way with in Azure. Please let us know the update on this request as we could see no updates on this last couple of months.
This is one of the features that's holding us back from using AFS. Adding this function will make a lot of difference especially with our remote users. Thanks.
آموزش فن بیان و مهارت های ارتباطی commented
We absolutely need this. thanks for sharing. http://www.behtarinbayan.ir
Please add this capability. Use case is similar to one earlier but in this case we are using a third party backup of the Azure File share. A restore of files/folders takes 24 hours to show up which is unacceptable.
Daniel Herron commented
This seems to be a very strange "feature" to leave out, and would seem to be more of a mandatory requirement of any sync service. Please add to this service ASAP
@ Bram - why write directly to the Azure share? Just write to the local disk and let AFS take care of the upload / tiering to Azure... If you're worried about overflowing the local cache size use the /ipg switch of robocopy to slow it down.