Microsoft Azure — Azure Files & File Sync

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure files & file sync with production-ready configurations, best practices, and hands-on examples.

Azure Files vs. File Sync: When to Use What

Azure Files provides fully managed file shares in the cloud, accessible via SMB and NFS protocols. It's ideal for lift-and-shift migrations, shared application data, and cloud-native workloads that need persistent storage. Azure File Sync, on the other hand, extends on-premises file servers to Azure by caching frequently accessed files locally while tiering cold data to the cloud. Use Azure Files when you want a pure cloud file share with no on-premises dependency. Use File Sync when you need to centralize file management across multiple offices, reduce WAN latency, or migrate gradually from on-premises file servers. A common mistake is using File Sync for workloads that don't require local caching—this adds unnecessary complexity and cost. For cloud-only apps, stick with Azure Files. For hybrid scenarios with active on-premises users, File Sync is the right choice.

#!/bin/bash
# Create a storage account and an Azure Files share
RESOURCE_GROUP="rg-files-prod"
STORAGE_ACCOUNT="stfilesprod$(openssl rand -hex 4)"
SHARE_NAME="appdata"
LOCATION="eastus"

az group create --name $RESOURCE_GROUP --location $LOCATION
az storage account create --name $STORAGE_ACCOUNT --resource-group $RESOURCE_GROUP --sku Standard_LRS --kind StorageV2 --enable-large-file-share
az storage share create --account-name $STORAGE_ACCOUNT --name $SHARE_NAME --quota 100

echo "Storage account: $STORAGE_ACCOUNT"
echo "Share: $SHARE_NAME"

Provisioning Azure Files with Terraform

Infrastructure as Code is non-negotiable for production. Use Terraform to provision Azure Files shares with consistent naming, quotas, and networking. Key resources: azurerm_storage_account (with account_kind = FileStorage for premium performance), azurerm_storage_share, and azurerm_storage_account_network_rules to restrict access. Always enable soft delete on shares to prevent accidental data loss. For private connectivity, deploy a Private Endpoint and disable public access. Use lifecycle rules to prevent accidental deletion of critical shares. A common pitfall is forgetting to set 'large_file_shares_enabled' on Standard accounts—without it, shares are limited to 5 TB. Premium shares support up to 100 TB natively.

provider "azurerm" {
  features {
    storage {
      data_plane_available = true
    }
  }
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-files-prod"
  location = "eastus"
}

resource "azurerm_storage_account" "sa" {
  name                     = "stfilesprod${random_string.suffix.result}"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  account_kind             = "StorageV2"
  large_file_shares_enabled = true
  min_tls_version          = "TLS1_2"
}

resource "random_string" "suffix" {
  length  = 6
  special = false
  upper   = false
}

resource "azurerm_storage_share" "share" {
  name                 = "appdata"
  storage_account_name = azurerm_storage_account.sa.name
  quota                = 100
  enabled_protocol     = "SMB"
}

resource "azurerm_storage_account_network_rules" "rules" {
  storage_account_id = azurerm_storage_account.sa.id
  default_action     = "Deny"
  bypass             = ["AzureServices"]
  ip_rules           = ["203.0.113.0/24"]
}

Mounting Azure File Shares on Windows and Linux

Mounting Azure Files requires proper authentication and protocol support. On Windows, use SMB with Azure AD DS or storage account key. Persist the mount using net use with /persistent:yes. For Linux, use cifs-utils with SMB 3.0. Ensure port 445 is open (often blocked by ISPs). For NFS shares, mount via nfs-utils. Production tip: never embed storage account keys in scripts. Use Azure Key Vault or managed identity. For Windows, store the key in Windows Credential Manager. For Linux, use a credentials file with restricted permissions. Also, enable encryption in transit—SMB 3.0 encrypts by default; NFS requires Azure Files encryption at rest.

#!/bin/bash
# Mount Azure Files share on Linux
STORAGE_ACCOUNT="stfilesprod1a2b3c4d"
SHARE_NAME="appdata"
MOUNT_POINT="/mnt/appdata"
STORAGE_KEY=$(az storage account keys list --account-name $STORAGE_ACCOUNT --query "[0].value" -o tsv)

sudo mkdir -p $MOUNT_POINT
sudo mount -t cifs //$STORAGE_ACCOUNT.file.core.windows.net/$SHARE_NAME $MOUNT_POINT \
  -o vers=3.0,username=$STORAGE_ACCOUNT,password=$STORAGE_KEY,dir_mode=0755,file_mode=0644,serverino

echo "Mounted successfully"

Azure File Sync: Architecture and Deployment

Azure File Sync syncs an Azure Files share with on-premises Windows Servers. The sync agent runs as a service and uses a sync group to define which servers sync which share. Cloud tiering automatically moves cold files to Azure, leaving a stub on the local volume. This saves local storage while keeping file metadata intact. Deploy the Storage Sync Service resource, create a sync group, register your servers, and add the Azure Files share as a cloud endpoint. Critical: use the latest sync agent version—older versions have known performance issues. Also, monitor sync health via Azure Monitor and set alerts for sync errors. A common mistake is enabling cloud tiering on volumes with insufficient free space—the agent needs at least 10% free to operate.

# Register server with Azure File Sync
$ResourceGroup = "rg-filesync-prod"
$StorageSyncService = "sss-prod"
$SyncGroup = "sg-appdata"
$CloudEndpoint = "ce-appdata"
$ServerEndpoint = "se-fs01"

# Register server (run on the on-prem server)
Register-AzStorageSyncServer -ResourceGroupName $ResourceGroup -StorageSyncServiceName $StorageSyncService

# Create server endpoint with cloud tiering
New-AzStorageSyncServerEndpoint `
  -ResourceGroupName $ResourceGroup `
  -StorageSyncServiceName $StorageSyncService `
  -SyncGroupName $SyncGroup `
  -Name $ServerEndpoint `
  -ServerResourceId (Get-AzStorageSyncServer -ResourceGroupName $ResourceGroup -StorageSyncServiceName $StorageSyncService).ResourceId `
  -CloudTiering $true `
  -VolumeFreeSpacePercent 20 `
  -LocalCacheMode "UpdateLocallyCachedFiles"

Performance Tuning for Azure Files

Azure Files performance is governed by share quotas and IOPS limits. Standard shares have baseline IOPS of 1,000 and burst up to 3,000. Premium shares offer up to 100,000 IOPS with consistent low latency. For high-throughput workloads, use Premium (FileStorage) tier. To maximize throughput, mount multiple connections and use multiple threads. On Linux, tune mount options: rsize=1048576,wsize=1048576,noatime. On Windows, disable TCP autotuning and enable SMB Multichannel. Monitor performance metrics like FileShareEgress and FileShareIngress in Azure Monitor. A common bottleneck is the client-side network—ensure your VM or on-prem link has sufficient bandwidth. Also, avoid small random I/O; batch writes to improve throughput.

# Disable TCP Autotuning for better SMB performance
netsh int tcp set global autotuninglevel=disabled

# Enable SMB Multichannel
Set-SmbClientConfiguration -EnableMultiChannel $true

# Increase SMB credits for better throughput
Set-SmbClientConfiguration -CreditsMin 256 -CreditsMax 8192

# Restart SMB client
Restart-Service lanmanworkstation

Security: Authentication and Authorization

Azure Files supports two authentication methods: storage account key (shared key) and Azure AD DS (for SMB). For production, use Azure AD DS to enforce identity-based access control. Assign RBAC roles like 'Storage File Data SMB Share Contributor' to users or groups. For NFS, only root access is supported—use export policies to restrict client IPs. Always disable public network access and use Private Endpoints. Enable encryption in transit (SMB 3.0 encrypts by default; enforce TLS 1.2 for REST API). For auditing, enable diagnostic logs for file share operations and send to Log Analytics. A critical security practice: rotate storage account keys regularly and use separate keys for different applications.

resource "azurerm_private_endpoint" "file_pe" {
  name                = "pe-files-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  subnet_id           = data.azurerm_subnet.snet.id

  private_service_connection {
    name                           = "psc-files"
    private_connection_resource_id = azurerm_storage_account.sa.id
    is_manual_connection           = false
    subresource_names              = ["file"]
  }

  private_dns_zone_group {
    name                 = "pdnszg-files"
    private_dns_zone_ids = [azurerm_private_dns_zone.dns.id]
  }
}

resource "azurerm_private_dns_zone" "dns" {
  name                = "privatelink.file.core.windows.net"
  resource_group_name = azurerm_resource_group.rg.name
}

Monitoring, Alerting, and Backup

Production Azure Files requires proactive monitoring. Enable diagnostic settings to stream logs to Log Analytics. Key metrics: FileShareEgress, FileShareIngress, FileShareSyncEgress (for File Sync), and FileShareQuotaUsage. Set alerts for quota usage >80%, sync health errors, and authentication failures. For backup, use Azure Backup for Azure Files—it supports snapshot-based backups with up to 365 daily retention. Alternatively, use Azure File Sync with cloud tiering as a backup strategy (but not a replacement). Test restore regularly. A common oversight: not monitoring sync errors in File Sync. Use the Storage Sync Service's 'Sync Health' blade to see per-item errors. Also, set up action groups to notify the on-call team.

resource "azurerm_monitor_metric_alert" "quota_alert" {
  name                = "file-share-quota-80"
  resource_group_name = azurerm_resource_group.rg.name
  scopes              = [azurerm_storage_share.share.id]
  description         = "Alert when file share quota usage exceeds 80%"

  criteria {
    metric_namespace = "Microsoft.Storage/storageAccounts/fileServices/shares"
    metric_name      = "FileShareQuotaUsage"
    aggregation      = "Average"
    operator         = "GreaterThan"
    threshold        = 80
  }

  action {
    action_group_id = azurerm_monitor_action_group.ag.id
  }
}

resource "azurerm_monitor_action_group" "ag" {
  name                = "ag-files-prod"
  resource_group_name = azurerm_resource_group.rg.name
  short_name          = "files-alert"

  email_receiver {
    name          = "oncall"
    email_address = "oncall@example.com"
  }
}

Disaster Recovery and Business Continuity

For disaster recovery, Azure Files supports geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS). In a regional outage, Microsoft fails over to the paired region. However, failover is manual for Azure Files—you must initiate it via Azure Portal or CLI. For faster recovery, use Azure File Sync with multiple server endpoints in different regions. Alternatively, replicate shares to a secondary region using AzCopy or Azure Data Factory. Test your DR plan quarterly. A common mistake: relying on GRS without testing failover. GRS failover can take hours and may lose up to 15 minutes of data (RPO). For zero RPO, use Azure File Sync with sync groups spanning regions.

#!/bin/bash
# Initiate storage account failover to paired region
STORAGE_ACCOUNT="stfilesprod1a2b3c4d"
RESOURCE_GROUP="rg-files-prod"

az storage account failover --name $STORAGE_ACCOUNT --resource-group $RESOURCE_GROUP

echo "Failover initiated. Monitor status with:"
echo "az storage account show --name $STORAGE_ACCOUNT --query statusOfSecondary"

Cost Optimization and Tiering Strategies

Azure Files costs depend on tier (Standard vs. Premium), redundancy (LRS, GRS, etc.), and data stored. Standard is cheaper per GB but has lower IOPS. Premium is expensive but offers consistent performance. Use lifecycle management to move cold data to cool or archive tiers (if using Blob Storage). For File Sync, cloud tiering reduces local storage costs—set tiering policies based on last access time. Monitor cost with Azure Cost Management and tag resources. A common waste: over-provisioning premium shares with large quotas. Start small and scale up. Also, delete unused shares and snapshots. For infrequently accessed data, consider Azure Archive Storage with AzCopy for retrieval.

resource "azurerm_storage_management_policy" "policy" {
  storage_account_id = azurerm_storage_account.sa.id

  rule {
    name    = "tier-cold-after-30-days"
    enabled = true
    filters {
      prefix_match = ["archive/"]
    }
    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 30
        tier_to_archive_after_days_since_modification_greater_than = 90
        delete_after_days_since_modification_greater_than          = 365
      }
    }
  }
}

Troubleshooting Common Issues

Common Azure Files issues include mount failures, slow performance, and sync errors. For mount failures, check port 445 connectivity (test with Test-NetConnection on Windows or nc on Linux). Ensure SMB 1.0/CIFS is disabled. For slow performance, verify share IOPS limits and client tuning. Use Azure Monitor to check for throttling (FileShareThrottling metric). For File Sync, check the event log for errors (Event ID 9100, 9301). Common sync errors: access denied (check NTFS permissions), file locked (close open handles), or cloud tiering stuck (free space). Use the File Sync troubleshooting guide and the 'Sync Health' blade. A production tip: enable verbose logging on the sync agent for detailed diagnostics.

# Test connectivity to Azure Files on port 445
$StorageAccount = "stfilesprod1a2b3c4d"
$TestResult = Test-NetConnection -ComputerName "$StorageAccount.file.core.windows.net" -Port 445

if ($TestResult.TcpTestSucceeded) {
    Write-Host "Port 445 is open"
} else {
    Write-Host "Port 445 is blocked. Check firewall or ISP restrictions."
}

Migration Strategies: On-Premises to Azure Files

Migrating file shares to Azure Files can be done via AzCopy, Azure File Sync, or Storage Migration Service. For large datasets (>10 TB), use Azure File Sync to gradually migrate while users continue working. For smaller datasets, AzCopy is faster. Plan for downtime if using AzCopy (final sync). Use Azure Data Box for offline migration of >50 TB. Always validate data integrity after migration with checksums. A common mistake: not accounting for NTFS permissions. Azure Files with AD DS preserves ACLs; without AD DS, permissions are lost. Use robocopy with /COPYALL to preserve permissions during migration. Also, test application compatibility—some apps require local file paths.

#!/bin/bash
# Migrate on-premises share to Azure Files using AzCopy
SOURCE_PATH="/mnt/oldshare"
DEST_URL="https://stfilesprod1a2b3c4d.file.core.windows.net/appdata?<SAS-token>"

azcopy copy "$SOURCE_PATH/*" "$DEST_URL" --recursive --preserve-smb-permissions=true --preserve-smb-info=true

echo "Migration complete. Verify with:"
echo "azcopy list $DEST_URL"

Advanced: Hybrid Cloud with Azure File Sync and DFS-N

For large enterprises, combine Azure File Sync with Distributed File System Namespaces (DFS-N) to provide a unified namespace across multiple file servers and Azure shares. Deploy DFS-N on-premises, add Azure Files shares as targets, and use File Sync to keep them in sync. This allows transparent failover and load balancing. Ensure DFS-N replication is disabled for sync folders to avoid conflicts. Use DFS-N with folder targets pointing to the local server endpoint. For disaster recovery, add a cloud-only target. A common pitfall: DFS-N referrals can cause clients to connect to a slow target. Configure referral ordering to prioritize local servers.

# Add Azure Files share as DFS-N target
$NamespacePath = "\\domain\namespace\appdata"
$TargetPath = "\\stfilesprod1a2b3c4d.file.core.windows.net\appdata"

New-DfsnFolderTarget -Path $NamespacePath -TargetPath $TargetPath -ReferralPriorityClass "site-cost-normal"

Write-Host "DFS-N target added. Clients will see both on-prem and cloud paths."