Scenario
Example: NetApp NFS export svm-nfs:/projects is moving to an Azure Files NFSv4.1 share called projects. This file-level copy procedure uses a Linux migration VM with both source and target mounted; it is not SnapMirror and does not preserve NetApp snapshots. Check the selected Azure Files resource provider against Microsoft’s version-specific migration guide.
Before you change production
Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.
1. Confirm Azure Files NFS meets the workload
- Inventory current NFSv3/v4 clients, UID/GID ownership, export rules, ACLs, symlinks, hard links, file counts and sizes, application locks and latency requirements. Azure Files NFS supports NFSv4.1 and UNIX-style permissions but does not support NFS ACLs, Kerberos identity-based authentication, Windows NFS clients, or simultaneous SMB access to the same NFS share. An NFSv3-only client or ACL-dependent workload needs redesign or a different target.
- Choose SSD NFS share sizing, IOPS and throughput and supported redundancy, and review Azure region and resource provider. Decide how NetApp export-policy client restrictions translate to Azure network security controls and root-squash behavior; there is no one-to-one export-policy copy.
Read-only source inventory
vserver nfs show -vserver svm_prod
vserver export-policy rule show -vserver svm_prod
volume show -vserver svm_prod -fields junction-path,security-styleVerify
A pilot workload passes protocol, identity, permissions and latency tests before the full migration.
2. Create secure Azure NFS network and share
- Create an Azure Files NFS share using the chosen supported resource provider and region. Configure VNet access and preferably a private endpoint with private DNS. For on-premises clients, establish VPN or ExpressRoute to the Azure VNet; check name resolution and route to the private endpoint. Azure Files NFS relies on network access controls and UNIX permissions rather than per-user Kerberos authentication.
- Mount from an Azure Linux VM using Microsoft’s portal-generated Linux mount command for that exact share. Ensure your NFSv4.1 client version and encryption-in-transit setting are compatible. Avoid writing a guessed export URL: the mount target differs by Azure resource model.
Verify
A Linux test VM can mount the target and create/read/remove a disposable file; unauthorized networks cannot mount it.
3. Mount both ends and pilot a copy
- Mount the NetApp source with the intended NFS version at /mnt/source and the Azure target with the generated Azure command at /mnt/target. Where supported by the client and Azure share, use nconnect for parallel connections after a pilot proves stability. Ensure the copy host can read all source data and set the intended target ownership.
- Copy a test directory with rsync preserving ownership, groups, permissions, timestamps and links where supported. Dry-run with --itemize-changes, then run a real pilot. Review numeric UID/GID identity mapping, root squash, special files and unsupported ACLs. Applications using database files may require application-native migration rather than an uncoordinated file copy.
Linux pilot example · inspect before copying
rsync -aHn --numeric-ids --itemize-changes /mnt/source/Pilot/ /mnt/target/Pilot/
rsync -aH --numeric-ids --info=stats2 /mnt/source/Pilot/ /mnt/target/Pilot/Verify
Representative files, links, owner IDs and permissions have the intended semantics at the target.
4. Seed the dataset and measure delta
- Start the bulk copy while applications continue writing to the source. Use rsync for moderate datasets; for large namespaces consider Microsoft’s Storage Mover or fpsync guidance for the selected classic NFS share. Choose parallelism after measuring source/target IOPS and network load.
- Run repeated rsync passes and compare transfer statistics, itemized changes, errors and elapsed time. Microsoft documents Storage Mover for on-prem NFS sources; its Azure endpoint support and resource provider scope must be checked before adopting it. Preserve a manifest of skipped files and decide how each will be handled.
Example bulk and dry-run delta commands
rsync -aH --numeric-ids --info=stats2 --log-file=/var/log/projects-seed.log /mnt/source/ /mnt/target/
rsync -aHn --numeric-ids --itemize-changes /mnt/source/ /mnt/target/Verify
The dry-run change list shrinks enough for the approved maintenance window.
5. Final pass, switch clients and validate
- Stop all source writers and verify the export is stable. Run one final rsync pass. If deletions must be mirrored, first inspect a dry run with --delete and confirm the exact root path, then execute it only on an approved dedicated destination; --delete can remove destination-only data.
- Compare file counts, byte totals and selected checksums; test UID/GID ownership and application operations from an Azure client. Update /etc/fstab or application mount definitions with the Azure Files NFSv4.1 target and mount options recommended for that resource type; restart workloads in order. Keep the NetApp source protected from new writes.
Final delta · --delete removes target-only files
rsync -aHn --numeric-ids --delete --itemize-changes /mnt/source/ /mnt/target/
rsync -aH --numeric-ids --delete --info=stats2 --log-file=/var/log/projects-final.log /mnt/source/ /mnt/target/Verify
One writable target serves the application; file metadata, authorization and latency match acceptance criteria.
6. Rollback and operational handover
- If the target fails before it receives production writes, restore original client mounts to the unchanged NetApp export. After target writes begin, stop those writes and use a reviewed reverse-copy/reconciliation plan before reverting; a DNS or fstab reversal alone loses changes.
- Configure supported Azure Files NFS snapshots and monitoring; note that Azure File Sync and Azure file-share backup support differ for NFS. Document private endpoint DNS, VPN/ExpressRoute, mount options, storage performance limits and access governance.
Verify
Application owner confirms recovery, monitoring, data protection and one authoritative copy.