Azure Files NFS Backup

Automated backup solution for Azure Files NFS via snapshots, using Azure Automation Runbooks.

Problem

Azure Backup does not natively support NFS protocol file shares (official documentation). This solution fills that gap with automated snapshots and configurable retention.

Architecture

┌──────────────────────────────────────────────────────┐
│  Resource Group                                      │
│                                                      │
│  ┌────────────────────┐    ┌───────────────────────┐ │
│  │ Automation Account │    │ Storage Account (NFS) │ │
│  │  + Managed Identity│──▶│  File Share (NFS)     │  │
│  │  + Runbook         │    │  └─ Snapshots         │ │
│  │  + Schedule (daily)│    └───────────────────────┘ │
│  └────────────────────┘                              │
│                                                      │
│  ┌────────────────────┐                              │
│  │ VNet + Subnet      │                              │
│  │  (Service Endpoint)│                              │
│  └────────────────────┘                              │
└──────────────────────────────────────────────────────┘

Features

• No shared key access dependency: uses ARM REST API (management plane) with Managed Identity
• Configurable retention: automatic cleanup of old snapshots
• Daily schedule: scheduled execution at 02:00 UTC (configurable)
• Azure Policy compatible: works in subscriptions that block shared key authentication

Repository Structure

├── deploy/
│   ├── 01-deploy-infra.ps1       # Base infrastructure deployment
│   ├── 02-deploy-automation.ps1  # Automation Account + Runbook + Schedule
│   ├── 03-test-populate-nfs.sh   # Test data (run on Linux VM)
│   └── parameters.json           # Configurable parameters
├── runbook/
│   └── Backup-NfsSnapshot.ps1    # Azure Automation Runbook
├── cleanup/
│   └── cleanup.ps1               # Full PoC cleanup
├── .gitignore
└── README.md

---

Demo Walkthrough (Step by Step)

Follow this guide to deploy the full PoC end-to-end, create test data, run a snapshot, and verify it works.

Prerequisites

• Azure CLI installed and logged in (az login)
• Azure subscription with permission to create resources
• PowerShell 7+ (or Windows PowerShell 5.1)
• The automation Azure CLI extension will be installed automatically by the scripts

Step 1 — Clone the Repository

git clone https://github.com/<your-org>/azure-files-nfs-backup.git
cd azure-files-nfs-backup

Step 2 — Review and Customize Parameters

Open deploy/parameters.json and adjust values if needed:

{
  "resourceGroupName": "rg-nfs-backup-poc",
  "location": "spaincentral",
  "storageAccountPrefix": "stnfspoc",
  "fileShareName": "nfsshare01",
  "fileShareQuotaGiB": 100,
  "automationAccountName": "aa-nfs-backup-poc",
  "runbookName": "Backup-NfsSnapshot",
  "vmSize": "Standard_D4as_v5",
  "retentionDays": 7,
  "scheduleName": "Daily-0200-UTC"
}

Tip: Change location to a region near you. The Storage Account name suffix is generated randomly at deploy time.

Step 3 — Deploy Infrastructure (with test VM)

.\deploy\01-deploy-infra.ps1 -DeployVM

This creates:

Resource	Purpose
Resource Group	Container for all PoC resources
VNet + Subnet	Network with Microsoft.Storage service endpoint
Storage Account	Premium FileStorage (NFS-capable)
NFS File Share	100 GiB share with NFSv4.1 protocol
Linux VM	Ubuntu 22.04 client with NFS auto-mounted

The script outputs the Storage Account name and saves it to deploy/.state.json for the next step.

Step 4 — Populate Test Data

Run this remotely on the VM to create a realistic SAP-like directory structure:

az vm run-command invoke `
  --resource-group rg-nfs-backup-poc `
  --name vm-nfs-client `
  --command-id RunShellScript `
  --scripts @deploy/03-test-populate-nfs.sh

This creates:

• ASCS00/ and ERS01/ directories with log files
• sapmnt/S4H/profile/ with SAP profile configs
• sapmnt/S4H/global/ with a cluster config and a 10 MB binary test file

Step 5 — Deploy Automation (Runbook + Schedule)

.\deploy\02-deploy-automation.ps1

This creates:

Resource	Purpose
Automation Account	Hosts the Runbook and schedule
System-Assigned Managed Identity	Authenticates to ARM without secrets
RBAC assignment	Storage Account Contributor on the Storage Account
Runbook	Backup-NfsSnapshot — published and ready
Schedule	Daily-0200-UTC — runs every day at 02:00 UTC
Job Schedule link	Connects the schedule to the Runbook with parameters

Step 6 — Run a Manual Snapshot Test

Trigger the Runbook manually to verify it works:

# Replace <your-storage> with the actual Storage Account name
az automation runbook start `
  --automation-account-name aa-nfs-backup-poc `
  --resource-group rg-nfs-backup-poc `
  --name Backup-NfsSnapshot `
  --parameters StorageAccountName=<your-storage> `
               ResourceGroupName=rg-nfs-backup-poc `
               FileShareName=nfsshare01 `
               RetentionDays=7

Step 7 — Verify Snapshots

az storage share-rm list `
  --storage-account <your-storage> `
  --resource-group rg-nfs-backup-poc `
  --include-snapshot `
  --query "[].{name:name, snapshotTime:snapshotTime, quota:shareQuota}" `
  -o table

Expected output:

Name         SnapshotTime              Quota
-----------  ------------------------  -------
nfsshare01                             100
nfsshare01   2026-03-14T15:50:28.0000  100

The row with a SnapshotTime is your snapshot. The one without is the live share.

Step 8 — Cleanup

When done testing:

.\cleanup\cleanup.ps1

Or directly:

az group delete --name rg-nfs-backup-poc --yes --no-wait

---

Production Deployment

For existing SAP NFS file shares (ASCS/ERS), you only need the Automation layer — no VM or VNet required.

What Changes

Demo	Production
Deploys VNet, Storage Account, VM	You already have these
Runs both scripts	Run only 02-deploy-automation.ps1
One file share	One schedule + linkage per file share

Steps

1. Update parameters.json with your production Resource Group, Storage Account, and File Share names
2. Run the automation script:

   .\deploy\02-deploy-automation.ps1 -StorageAccountName <your-prod-storage>

3. Assign RBAC — the script does this automatically, but if your Managed Identity needs access to multiple Storage Accounts, run:

   az role assignment create `
     --assignee-object-id <managed-identity-principal-id> `
     --assignee-principal-type ServicePrincipal `
     --role "Storage Account Contributor" `
     --scope <storage-account-resource-id>

4. Repeat for each NFS file share: create a new schedule and link it to the Runbook with the appropriate parameters

Technical Notes

• The Runbook uses Invoke-AzRestMethod against the ARM REST API (PUT with $expand=snapshots) instead of data plane cmdlets (New-AzStorageShareSnapshot), because many enterprise subscriptions block shared key authentication via Azure Policy
• API version: 2025-06-01
• NFS snapshots are instantaneous and file-system consistent
• Authentication is via System-Assigned Managed Identity — no passwords, keys, or certificates stored anywhere

Limitations

• Snapshots reside in the same Storage Account — they do not protect against accidental account deletion
• For cross-region protection, consider complementing with Blob Storage copy or migrating to Azure NetApp Files
• Azure Backup does not support NFS file shares (as of March 2026)

License

MIT