High Availability for NFS File Share

For cross-region disaster recovery, one potential workaround is to create a second Premium Azure Files NFS share in another Azure region and synchronize the data between the two shares using Azure compute. You can deploy an Azure Linux VM in the primary or a dedicated replication network, mount both NFS shares, and use native Linux utilities such as rsync to perform incremental synchronization. Alternatively, Microsoft-supported AzCopy can be used for file copying where its supported Azure Files NFS scenarios meet your requirements. The entire solution remains within Azure and does not require a third-party replication product or Azure NetApp Files.

The architecture would consist of a primary Premium NFS share using ZRS in Region A and a similarly configured Premium NFS share in Region B. The VNets can be connected using Azure Global VNet Peering, and the replication VM can access both storage accounts through their private endpoints. A scheduled replication process can continuously or periodically synchronize the primary share to the secondary share. The secondary share is effectively a warm standby that can be made available to the application if the primary Azure region becomes unavailable.

This provides regional DR, but it is asynchronous replication rather than true active-active HA. Your RPO is determined by how frequently the synchronization runs. For example, a five-minute synchronization interval could result in up to approximately five minutes of unsynchronized changes during a regional failure. You also need to account for application consistency, file locking, deleted or renamed files, permissions and ownership, and the possibility of files changing while synchronization is occurring.

For local HA, ZRS is substantially better because replication is synchronous and handled by Azure. If an availability zone fails, Azure maintains the storage service without requiring you to maintain a second file share or perform application-level replication. Your applications continue accessing the same Azure Files endpoint rather than having to switch to another regional share.

For regional DR, you'd need a failover mechanism in addition to replication. This could be implemented with Azure DNS, application configuration, or another Azure-native routing mechanism. During a regional outage, the application or its configuration would be directed to the secondary region's NFS endpoint. The secondary share should not normally be treated as an independently writable copy unless you have designed specifically for conflict resolution and split-brain scenarios.

Azure File Share snapshots can also provide point-in-time recovery within the storage account, but they are not a replacement for cross-region replication. They are useful for recovering accidentally deleted or corrupted files, with the secondary regional NFS share providing protection against loss of the primary region.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin