NFS export definitions decide which local paths clients can mount, which clients may reach them, and which options apply to that access. Backing up those definitions before a risky edit, rebuild, or migration gives the server a known export state that can be restored and reloaded without reconstructing access rules from memory.
Linux NFS servers read export definitions from /etc/exports and files ending in .exports under /etc/exports.d. The active export table is then rebuilt with exportfs, so a complete backup needs the source files plus a verification command that proves the restored definitions are active.
The backup protects export configuration only. It does not back up the shared data under the exported directories, NFS daemon settings such as /etc/nfs.conf, firewall rules, Kerberos keys, or client mount files. Treat the restore step as a configuration rollback because extracting over live export files can remove entries created after the backup.
Related: How to list NFS exports on a server
Related: How to reload NFS exports
Related: How to create an NFS export
$ sudo exportfs -s /srv/nfs/projects 192.0.2.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)
exportfs -s shows active exports in a format close to /etc/exports syntax, which makes the restored state easier to compare later.
$ sudo mkdir -p /root/nfs-export-backups
Use a root-owned location while the archive is being prepared because export files can reveal internal hostnames, client networks, and security options.
$ sudo tar --create --verbose --file /root/nfs-export-backups/nfs-exports-backup.tar /etc/exports /etc/exports.d /etc/exports tar: Removing leading `/' from member names tar: Removing leading `/' from hard link targets /etc/exports.d/ /etc/exports.d/projects.exports
The archive stores relative paths such as etc/exports so it can be restored under the filesystem root with --directory /.
$ sudo tar --list --file /root/nfs-export-backups/nfs-exports-backup.tar etc/exports etc/exports.d/ etc/exports.d/projects.exports
The backup should include /etc/exports and every expected drop-in file under /etc/exports.d. Files in /etc/exports.d that do not end in .exports are not read by exportfs.
$ sudo cp /root/nfs-export-backups/nfs-exports-backup.tar /var/backups/nfs-exports-backup.tar
For rebuild or migration work, keep another copy outside the server being changed. A local-only archive can disappear during a failed rebuild, disk replacement, or rollback attempt.
$ sudo tar --extract --verbose --file /var/backups/nfs-exports-backup.tar --directory / etc/exports etc/exports.d/ etc/exports.d/projects.exports
This overwrites matching export definition files. If another tool manages a drop-in, confirm that restoring the saved file will not fight the tool's next regeneration pass.
$ sudo exportfs -rv exporting 192.0.2.0/24:/srv/nfs/projects
exportfs -r synchronizes the active export table with /etc/exports and /etc/exports.d/*.exports, including removals from the saved files.
$ sudo exportfs -s /srv/nfs/projects 192.0.2.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)
Compare the path, client selector, and options with the baseline captured before the change. If the restored table differs, inspect the source file and reload again before sending clients back to the server.
Tool: Config Drift Checker
$ sudo mount -t nfs4 files.example.net:/srv/nfs/projects /mnt/projects
Run this from a client that already has the mount point prepared. A successful client mount proves more than exportfs parsing: DNS or host resolution, firewall access, NFS service state, and exported path permissions must also be correct. Related: How to manually mount an NFS export on Linux