ghettoVCB NFS Storage: Back Up VMs to a NAS

Backing up to a NAS over NFS is one of the most common ghettoVCB setups, and one of the easiest to get subtly wrong. A NAS is cheap storage, it sits apart from the host, and it is the separate copy that saves you when a datastore fails. But NFS on ESXi has two different modes, a disk format restriction, and performance quirks that do not exist with local storage. This guide explains both NFS modes, how to choose between them, and how to test an NFS backup before you trust it.

Start with the goal, because it decides the mode. You want backups on storage that is physically separate from the host’s VM datastores, reachable over the network, and fast enough that a full VM copy finishes inside your backup window. A NAS on the same gigabit switch as the host, with enough free space, usually meets that goal. A NAS across a slow link, or one shared with heavy daytime traffic, may not. Measure the copy speed with a real backup before you schedule nightly runs against it, because a backup that overruns its window collides with the working day.

Persistent NFS Datastores

The simpler mode is a persistent NFS datastore. You add the NFS export as a datastore on the host, in the usual way, and it stays mounted. ghettoVCB then treats it like any other destination: you set VM_BACKUP_VOLUME to a folder on that datastore, and backups land there. The datastore is visible in the client, you can browse it, and the backup folders sit where you expect them. This mode is easy to understand and easy to check, which counts for a lot in backup work.

The restriction to remember is the disk format rule. On non-VMFS volumes such as NFS, only 2gbsparse and thick formats can be used for the backed-up VMDK files. Set DISK_BACKUP_FORMAT accordingly, and test a backup and a restore with that format before you schedule anything. A persistent NFS datastore also stays connected all the time, which means it is visible to anything on the host. That is convenient, and it is also a reason to keep the export permissions tight, so only the host can write to the backup share.

Non-Persistent NFS: Connect, Back Up, Disconnect

The second mode is non-persistent NFS, and it exists for hosts that do not have a persistent NFS datastore. When ENABLE_NON_PERSISTENT_NFS is set to 1, the script connects the host to an NFS export itself, runs the backup, and disconnects when it finishes. You configure the connection with the NFS settings in the configuration file: NFS_SERVER, NFS_VERSION, NFS_MOUNT, NFS_LOCAL_NAME, and NFS_VM_BACKUP_DIR. When this mode is on, VM_BACKUP_VOLUME is ignored, because the NFS settings define the destination instead.

Non-persistent mode has a real technical advantage. Because the script creates an NFS datastore link for the export, rather than using a plain Unix mount, monolithic and thick VMDK backups become possible, instead of the 2gbsparse splits that a plain mount would require. That matters if you want single-file VMDK backups on NAS storage. It also means the connection is only present during the backup, which some administrators prefer. The trade-off is complexity: more settings, more ways for a connection failure to stop the backup, and more to check in the log when something goes wrong.

Choosing Between the Two Modes

Choose persistent NFS when the NAS is always available, the host can keep the datastore mounted, and you value simplicity and easy browsing of the backup folders. Choose non-persistent NFS when the host has no persistent NFS datastore, when you want the connection present only during backups, or when you need monolithic or thick VMDK files on NAS storage. Either mode can protect your VMs well. The wrong choice is the one you did not test, so run a full backup and a test restore in the mode you picked, and confirm the files, the format, and the restore all behave as expected.

Whichever mode you choose, keep the backup share’s permissions narrow. The export should be writable by the ESXi host and readable by as few other systems as possible. Backup folders contain full copies of your VMs, including their data, and a world-writable backup share is a data leak waiting to happen. Check the permissions from the NAS side as well as the host side, because the two views do not always agree.

Performance and Reliability on NFS

NFS backups are network backups, and the network is part of the backup system. A full VM copy over a 1 Gb link takes far longer than the same copy to local storage, and a large VM can easily overrun a nightly window. If your backups are slow, check the link speed, check whether other traffic shares the link during the backup window, and consider a dedicated backup network or a faster link for the NAS. Also remember that the snapshot stays open for the whole copy, so a slow copy means a long-lived snapshot, more delta growth, and more consolidation work when the snapshot is deleted. Speed is not just convenience here. It affects the health of the running VM.

Reliability matters as much as speed. If the NFS connection drops mid-backup, the run fails, and you must check for a leftover snapshot before the next run. The script will skip a VM with an existing snapshot by default, so a dropped connection can silently cost you the next night’s backup too. Read the log after every NFS run, check the snapshot state, and treat any connection error as a prompt to investigate the NAS and the network, not just to re-run the job.

Test an NFS Backup Before You Trust It

Run a dry run against one VM, then a real backup, and confirm the files land on the NAS
Check the VMDK format matches the NFS restriction: 2gbsparse or thick, or monolithic via non-persistent mode
Register the backed-up VMX from the NAS copy and boot it in an isolated test, without touching production
Time the full backup and confirm it fits inside your nightly window with room to spare
Check the snapshot is gone after the run, and read the full log for connection warnings
Confirm the NFS export permissions allow only the host to write to the backup share

That test list is the whole NFS story in miniature. A backup that passes it is a backup you can schedule. A backup that fails any item is a setup problem, and setup problems are cheapest to fix before the schedule starts depending on them.

Conclusion

NFS gives ghettoVCB a separate, affordable backup destination, in two modes. Persistent NFS datastores are simple and browsable, with the 2gbsparse or thick format restriction. Non-persistent NFS connects and disconnects around each backup and allows monolithic or thick VMDK files through a datastore link. Choose the mode that fits your host, keep the share permissions tight, mind the network speed, and test a backup and a restore before you schedule. A NAS backup that has been proven by a restore is one of the best values in small VMware environments.

ghettoVCB with NFS Storage: Back Up VMs to a NAS