Proxmox Backup to NAS: Step-by-Step Setup Guide

Why Proxmox backup to NAS is mandatory, not optional

You spin up Proxmox, roll out five VMs, everything runs fine. Backups land right there, on the node’s local disk, in /var/lib/vz/dump. The disk dies, and the VMs die with it, along with their backups. Sound familiar?

Proxmox backup to NAS solves exactly this problem: data copies live physically on a different device, with a different controller, often in a different part of the rack or even a different building. If the server running Proxmox burns out, the NAS stays alive, and recovery takes hours, not weeks of searching for a way to get the data back.

By the end of this setup you’ll have a working NFS storage on the Proxmox side, a backup job with a schedule and retention policy, and a working procedure to confirm the backup actually landed on the NAS, not just “ran without errors” in the UI. Below we’ll cover why this setup breaks, a step-by-step recipe with commands and tables, and a verification section so you don’t have to guess whether it’s working.

The whole thing, including setting up the NFS export on the NAS side, takes anywhere from 30 minutes for a home lab to a couple of hours for a production cluster with several nodes and firewall rules for NFS traffic.

Reasons Proxmox-to-NAS backup breaks right at the setup stage

NFS storage looks simple: give it an IP, give it a path, done. In practice it breaks on a couple dozen small details, and some of them only show up a week later, when the backup job quietly stops writing new copies.

Most of these causes are fixed at setup time, if you follow the recipe in order and don’t skip the verification step after each action. Skipping showmount -e on the NAS before adding storage to Proxmox saves you ten minutes now and costs you an hour of troubleshooting later.

Recipe: connecting a NAS to Proxmox for backups over NFS

Prep work: what you need before you start

Before you go into Datacenter → Storage, settle three things. First: the NAS is already up, NFS server is enabled on it, the share is created. Second: you have root access to Proxmox over SSH. Third: the network between the node and the NAS doesn’t go through a Wi-Fi bridge or a 100 Mbit switch, otherwise backing up a 500 GB VM will take all night.

If the NAS and Proxmox sit in the same VLAN with no external access, you can skip the port setup entirely. But if there’s a router with ACLs between them, open 2049 both ways and don’t forget 111 if the NAS still runs NFSv3 for compatibility with older clients.

Step 1. Set up the NFS export on the NAS side

Before Proxmox can mount anything, the NAS has to serve the share. The logic is the same for Synology, TrueNAS and QNAP: create a folder for backups, enable the NFS service, allow access to the specific IP of the Proxmox node, not the whole subnet.

For TrueNAS SCALE and any Linux NAS with an NFS server, the export config looks like this:

/mnt/tank/proxmox-backup 192.168.1.50(rw,sync,no_subtree_check,no_root_squash)

Here 192.168.1.50 is the Proxmox node’s IP. no_root_squash is needed because vzdump writes files as root, and without this option the NAS maps root to nobody, and the write fails with an access error. For multiple nodes, list them space-separated or use a subnet CIDR if you have more than five nodes.

After editing /etc/exports on a DIY NAS, apply the changes:

exportfs -ra
exportfs -v

Expected result: the second command should show a line with the export path and the specified IP or subnet in brackets. If there’s no line, the exports file wasn’t applied, check its syntax.

Step 2. Verify the NFS export is reachable from the Proxmox node

Don’t add storage to Proxmox blind. First make sure the NFS export is actually visible from the node.

showmount -e 192.168.1.100

Expected result: the command should return a list of exports, including /mnt/tank/proxmox-backup or a similar path. If you get “RPC: Program not registered” or a timeout, the problem is on the NAS side: either the NFS service is off, or the NAS firewall blocks port 111 or 2049.

If showmount isn’t available on the node itself, install the NFS client utilities package:

apt update
apt install -y nfs-common

Step 3. Add the NFS storage to Proxmox via the web interface

Go to Datacenter → Storage → Add → NFS. Fill in five fields: ID (any name, for example backup-nas), Server (NAS IP or hostname), Export (the path returned by showmount), Content (make sure to check Backup, other content types aren’t needed for this task), Nodes (you can leave “All” for a cluster or pick a specific node).

After saving, Proxmox mounts the NFS share at /mnt/pve/backup-nas on its own. You won’t need to mount anything by hand, systemd units handle that automatically.

Same result via CLI, if you prefer the command line or are setting up several nodes with a script:

pvesm add nfs backup-nas --server 192.168.1.100 --export /mnt/tank/proxmox-backup --content backup --options vers=4.1

Expected result: a command with no output means success. You can verify it right away with the next command from the verification section below.

Step 4. Create a Backup Job with a schedule and retention

Storage is connected, but on its own it doesn’t back up anything. You need a job with a schedule. Go to Datacenter → Backup → Add.

Choose Node (or All), Storage (that same backup-nas), Selection mode (All for every VM/CT on the node or specific VMIDs), Schedule (for example, every day at 02:00), Mode (Snapshot for minimal VM downtime, Stop only if the app inside can’t handle snapshot mode).

Set up retention right away, otherwise the NAS fills up with old copies within a month:

keep-last=3
keep-daily=7
keep-weekly=4
keep-monthly=6

This means: the last 3 backups are always kept, plus 7 daily, 4 weekly, and 6 monthly snapshots with older ones pruned. Proxmox handles rotation automatically on every job run, you won’t need to manually clean up the dump folder on the NAS.

Step 5. Run the first backup manually, don’t wait for morning

Don’t rely on the schedule for your first check. Run vzdump by hand right now, while you’re at the console and ready to troubleshoot an error on the spot.

vzdump 100 --storage backup-nas --mode snapshot --compress zstd

Replace 100 with the actual VMID of your VM or container. The –compress zstd flag gives the best balance of speed and size compared to gzip or lzo for most workloads.

Expected result: the console will show progress logs, ending with a line like “INFO: Finished Backup of VM 100 (00:03:12)”. The file will show up in /mnt/pve/backup-nas/dump/ named vzdump-qemu-100-date.vma.zst or similar for LXC.

Security during NFS storage setup

NFS traffic isn’t encrypted by default, that’s a deliberate tradeoff of speed for simplicity. For a backup network inside a trusted perimeter this is acceptable, but a few things are worth locking down right away, not after an incident.

• Restrict the NAS export to the specific Proxmox node’s IP, not an entire /24 subnet, otherwise any host on the network can read and write to the backup folder.
• Keep NFS traffic in a separate VLAN, isolated from the user segment of the network, especially if you’re backing up VMs with databases or personal data.
• On the Proxmox node itself, through the built-in firewall (Datacenter → Firewall), allow outbound traffic on port 2049 only to the NAS IP, everything else can be dropped by default.
• Don’t use no_root_squash more broadly than needed: apply it only for the specific node IP in the export line, not globally for all NFS server clients.

Encryption in transit for NFS is theoretically possible via Kerberos (sec=krb5p), but for a home lab and most SMB setups that’s over-engineering. If the data is critical, it’s simpler to route NFS traffic over a dedicated physical segment or an IPsec tunnel between Proxmox and the NAS.

How to verify Proxmox-to-NAS backup is actually working

A green checkmark in the Proxmox UI doesn’t guarantee the file physically landed on the NAS disk. Check from both sides.

On the Proxmox side, check storage status:

pvesm status

Expected result: the backup-nas line should show Status: active and correct Total/Used/Available figures matching the real NAS volume size, not zero values.

Confirm the mount is actually alive in the system, not just listed in the config:

mount | grep pve
df -h /mnt/pve/backup-nas

Expected result: mount should output a line with type nfs4 and the NAS address, df will show real used space, growing after each backup.

List the backup files directly in storage, without going through the web interface:

ls -lh /mnt/pve/backup-nas/dump/

On the NAS side, open the file manager or check the same path /mnt/tank/proxmox-backup/dump/ over SSH. The file should show the same modification date and the same size as on the Proxmox node. If the file isn’t there on the NAS but is there on the node, the NFS mount is running in cached mode and the data hasn’t been flushed to disk yet, or these are actually two different paths.

The last and most important check: the backup job’s own log. In the Proxmox web interface, open Datacenter → Backup, pick the job, the Log tab shows the full output of the last run, including the exact start time, end time, and final status, OK or ERROR, for every VM in the job.

tail -n 50 /var/log/vzdump/qemu-100.log

This log lives locally on the Proxmox node regardless of where the backup file itself went, and it stays there even if the NAS is temporarily unreachable. A single line “ERROR: Backup of VM 100 failed” in this file is worth more than an hour spent figuring out why the backup didn’t happen, the morning after.

Troubleshooting: common NFS errors when backing up Proxmox to NAS

You followed the recipe above, and vzdump still fails. Here’s a breakdown of errors you actually run into in production, not in sanitized documentation.

ip -4 addr show | grep inet

nc -zv 192.168.1.100 2049

exportfs -ra

pvesm set backup-nas --disable 0
umount -f /mnt/pve/backup-nas
pvesm status

pvesm status
proxmox-backup-client prune --help

umount -l /mnt/pve/backup-nas
mount /mnt/pve/backup-nas

pvesm set backup-nas --content backup

If the NAS is ancient and refuses to serve v4.1, fall back to v3 explicitly in the storage options, don’t expect Proxmox to sort out the version mismatch on its own in reasonable time.

pvesm set backup-nas --options vers=3

After changing the protocol version, the storage needs to be remounted, otherwise Proxmox keeps using the old connection until the next reboot or manual umount.

Alternatives to NFS: SMB, Proxmox Backup Server and rsync for NAS backups

NFS isn’t the only way to pair Proxmox with a NAS. There are three other working options, each with its own niche.

SMB/CIFS instead of NFS for backup storage

Proxmox can mount CIFS directly from the web interface, without fiddling with /etc/fstab. For Synology this is often even simpler than NFS, because SMB is configured out of the box there and permissions are managed through DSM’s standard ACLs.

pvesm add cifs backup-smb --server 192.168.1.100 --share proxmox-backup --username backup-user --password 'secret' --content backup

The downside of SMB versus NFS: slightly higher protocol overhead on small files and mandatory username/password authentication, which has to be stored in the storage config. For backing up large vma files, the speed difference is barely noticeable on a gigabit network.

Proxmox Backup Server as a replacement for the vzdump plus NFS combo

If Proxmox-to-NAS backups via vzdump are already set up and running, but retention and speed start to choke, the next logical step is a dedicated Proxmox Backup Server. At the time of writing, PBS 4.2 is current, an update within the 4.x branch. Check the latest releases on the official download page before installing.

PBS gives you chunk-level deduplication, incremental backups after the first full one, built-in checksum verification, and single-file restore from a disk image without unpacking the entire VM. The difference is fundamental: NFS plus vzdump just drops files on disk, PBS stores data in its own indexed datastore.

For a home lab and a small infrastructure with up to five VMs, NFS plus vzdump handles the job without extra infrastructure. PBS pays off once you’re dealing with dozens of VMs and NAS space starts running tight due to the lack of deduplication.

rsync and rclone as a manual alternative for tricky cases

If the NAS doesn’t serve NFS or SMB properly, only object storage or a cloud service, you can move dump files with a script via rsync or rclone on a cron job, without Proxmox storage integration. This is less transparent in terms of status in the Proxmox UI, but it works with almost any transport.

rsync -avz --delete /var/lib/vz/dump/ backup-user@nas:/volume1/proxmox-backup/dump/

The downside: Proxmox doesn’t know whether the copy physically landed on the NAS, and won’t reflect this in its storage status. You need a separate script or alerting system to monitor whether this sync actually succeeds.

Maintenance: not losing Proxmox backups after everything is set up

What to back up, how often, and where to keep copies

You need to back up not just VM disks, but Proxmox’s own config: /etc/pve, /etc/network/interfaces, the storage.cfg list. Without this, recovering a cluster after a full node loss turns into reconstructing it from memory.

The 3-2-1 rule applies literally here: at least three copies of data, on two different media, with one copy physically offsite. A NAS in the next rack over covers only two out of the three points. The third requires cloud storage or a second site.

How to restore a VM from a NAS backup

Test restores no less than once a quarter, otherwise you find out about a corrupted archive during a real incident, not during a calm test run.

qmrestore /mnt/pve/backup-nas/dump/vzdump-qemu-100-2026_09_15-02_00_01.vma.zst 999 --storage local-lvm

Expected result: the command deploys the backup into a new VM with VMID 999, so the original 100 isn’t overwritten. Verify that the VM with the new ID starts and boots, then delete the test VM.

Monitoring backup status and free space on the NAS

A standalone backup job without monitoring is a gamble: it works until someone forgets to check the logs. Set up e-mail notifications right in the Backup Job (Notification field), and for production add external monitoring through Zabbix or Grafana with an alert for free NAS space dropping below 15%.

df -h /mnt/pve/backup-nas | awk 'NR==2{print $5}'

Set up an hourly cron check that sends an alert if used space exceeds a threshold, or if storage suddenly shows Status: unknown in pvesm status.

Automatic remount after a node reboot

NFS storage added through Datacenter → Storage mounts automatically when pve-cluster and pvestatd start, a separate fstab entry isn’t needed and is actually harmful: two mounting mechanisms start fighting each other. After rebooting the node, check that the mount came up right away, without manual intervention.

systemctl status pvestatd
mount | grep backup-nas

Updating Proxmox safely without losing access to NAS storage

Before updating Proxmox VE or the NAS, check NFS protocol version compatibility: sometimes a kernel update changes client behavior, and storage that’s been running on vers=3 for years suddenly starts flapping offline. Snapshot the storage.cfg config before updating.

cp /etc/pve/storage.cfg /root/storage.cfg.backup-$(date +%F)
apt update && apt list --upgradable

After updating, immediately check pvesm status and run a test vzdump on a minimal VM, before trusting the schedule to run unattended overnight. If storage didn’t come back up, restore the config from your saved copy and restart pvestatd.

cp /root/storage.cfg.backup-2026-09-19 /etc/pve/storage.cfg
systemctl restart pvestatd

Ongoing security for your backup infrastructure

• Keep the backup network in a separate VLAN and don’t expose port 2049 beyond the trusted network perimeter.
• Restrict access to the Proxmox web interface through a firewall or VPN, not a bare password exposed to the internet.
• Rotate SSH keys for node access regularly, especially if multiple engineers have access to the server.
• Encrypt critical backups separately if the NAS is physically accessible to outsiders, for example sitting in an unguarded remote office.
• Check permissions on the NAS export folder: 750 owned by backup-user is enough, 777 is a hole that will be found by more than just your own services.
• Keep a changelog of modifications to /etc/exports and storage.cfg via git or a plain changelog file, so that six months from now you know who changed an access rule and why.

A single drop of nicotine kills a horse. One forgotten no_root_squash line applied to an entire subnet instead of one IP kills the isolation of your whole backup infrastructure at once.

FAQ: common questions about Proxmox backup to NAS

Why doesn’t Proxmox backup to NAS work after setup?

Most often the storage mounted fine during setup but dropped after a NAS or node reboot due to a stale file handle. The second common cause: the Backup content type isn’t checked for the storage, so vzdump simply doesn’t see the storage in the available list when creating a job. Check pvesm status and the contents of /etc/pve/storage.cfg before digging deeper.

How do I verify a NAS backup is working correctly?

Cross-check three sources at once: status in pvesm status on the Proxmox node, the actual file in the dump folder on the NAS via a file manager or SSH, and the job log in Datacenter → Backup → Log. If all three sources show the same file with the same date and size, the backup actually landed.

What do I do if I get a permission denied error when backing up to a NAS?

Nine times out of ten this is root_squash on the NAS side, which maps Proxmox’s root to nobody with no write permission. Add no_root_squash to the export line specifically for the Proxmox node’s IP, not the whole subnet, and re-read exports with exportfs -ra.

How does NFS backup to NAS differ from Proxmox Backup Server?

NFS plus vzdump just drops full dump files onto the NAS disk, no deduplication, no incrementals. Proxmox Backup Server stores data in its own datastore with chunk-level deduplication, incremental backup support, and single-file restore without unpacking the whole image.

How do I set up NFS storage in Proxmox if the NAS doesn’t support NFSv4.1?

Explicitly set vers=3 in the storage options via pvesm set or in the web interface. NFSv3 additionally requires port 111 open for portmapper, don’t forget it on the NAS firewall and on any intermediate routers.

How do I back up a VM to Synology through Proxmox?

On Synology, enable the NFS service in Control Panel, create a Shared Folder for backups, in its NFS Permissions settings add a rule with the Proxmox node’s IP and the “no squash root as everyone” option for a dedicated user. From there, follow the same recipe: showmount from the node, add storage via Datacenter → Storage → Add → NFS, run a test vzdump.

vzdump doesn’t see the NFS storage, what do I do?

Check that the storage has the Backup content type checked in its settings, not just Images or ISO. Without that checkbox, Proxmox mounts the NFS share but completely ignores it when picking a destination for a backup job.

What to expect after setting up Proxmox backup to NAS

After going through this recipe, you’ll have NFS storage set up with verified reachability, a backup job with a schedule and retention that prunes old copies on its own without manual intervention, and a working procedure to confirm the backup file actually sits on the NAS, not just shows a green checkmark in the UI.

From here it’s an ongoing process, not a one-time setup: a test restore once a quarter, a free space check on the NAS once a month, and a verification that storage comes back up after restarting pvestatd with every Proxmox update. These three habits are what separate infrastructure where backups actually save you when a disk fails, from infrastructure where backups exist only as an entry in a config file.