Clarification regarding Azure File Sync group, shares & endpoint confusion?

Question

Hi People,

I need some guidance in understanding how Azure File Sync groups, shares & (Cloud & Server) endpoints related to each other.

Under what circumstance, the files will be overwriting each other or can cause some data loss issue?

Is the analogy the same as DFS-R file server technology?

If anyone can share the link or explain it here with a diagram, that'd be greatly appreciated.

Thank you in advance.

Answer 1

Hi @EnterpriseArchitect

Below is my response to your question and for your reference url's are updated.

Clarification on Azure File Sync Group
A sync group defines the sync topology for a set of files. Endpoints within a sync group are kept in sync with each other. A sync group must contain one cloud endpoint, which represents an Azure file share and one or more server endpoints. A server endpoint represents a path on a registered server.
A server can have server endpoints in multiple sync groups. You can create as many sync groups as you need to appropriately describe your desired sync topology.

Clarification on Cloud endpoint
A cloud endpoint is a pointer to an Azure file share. All server endpoints will sync with a cloud endpoint, making the cloud endpoint the hub. The storage account for the Azure file share must be located in the same region as the Storage Sync Service. The entirety of the Azure file share will be synced, with one exception: A special folder, comparable to the hidden "System Volume Information" folder on an NTFS volume, will be provisioned. This directory is called ".SystemShareInformation". It contains important sync metadata that will not sync to other endpoints. Do not use or delete it!

Distributed File System (DFS)
Azure File Sync supports interop with DFS Namespaces (DFS-N) and DFS Replication (DFS-R).

----------

Please don’t forget to "Accept the answer" and up-vote wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

@EnterpriseArchitect Start by specifying an Azure file share to sync with - this is the sync group's first cloud endpoint. You can specify a folder on your servers you want to sync later.

Adding more information to the above response:

• Under what circumstance, the files will be overwriting each other or can cause some data loss issue?
  Removing a server endpoint isn't like rebooting a server! Removing and recreating the server endpoint is almost never an appropriate solution to fixing issues with sync, cloud tiering, or other aspects of Azure File Sync. Removing a server endpoint is a destructive operation. It may result in data loss in the case that tiered files exist outside of the server endpoint namespace. See Why do tiered files exist outside of the server endpoint namespace
• DFS-R is not supported by Azure Files, Azure File Sync is our answer for most DFS-R replication scenarios. AFS works very similarly to DFS-R, but is based on a different sync technology. Azure File Sync has distinct advantages over DFS-R, DFS-R, except for Azure File Sync surfaces these as files within the user’s namespace rather than requiring admin action to resolve. Using the weighting mechanism in DFS-N to bias all traffic to one server unless it’s down seems like a reasonable way to resolve this problem: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/set-target-priority-to-override-referral-ordering
• Azure File Sync: Integration with DFS Namespaces
• DFSR to Azure File Sync | DFS cross domain Migration | Azure File Sync Agent issue and Solution

For more information, refer here

Hope this helps!

Kindly let us know if the above helps or you need further assistance on this issue.

-------------------------------------------------------------------------------------------------------------

Please don’t forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Disclaimer: This response contains a reference to a third-party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there.
There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.