When your NFS share drops, Proxmox backups fill your root disk

NFS is the most common backup target in homelabs. A NAS share is cheap, it is off the host, and Proxmox speaks it natively. It also has three classic gotchas, and the first one is nasty because nothing about it looks broken until the host itself starts failing.

The trap: the mount isn't there, but the directory is

A common way to add a NAS is to mount the share yourself, say at /mnt/backups, and then add that path to Proxmox as a plain Directory storage. It works fine, right up to the morning the mount fails at boot.

When that happens, the share is gone but the empty folder is still there. Proxmox has no way to know the folder was supposed to be a network share, so the nightly job happily writes its archives into it. That folder lives on the host's root disk.

Within a night or two, the host's root filesystem is full, and things start breaking in confusing ways. From the backup job's point of view it all looked fine: it had a target, it wrote to it, and the job finished.

This is one of the four failure modes hiding behind a reassuring green check in the Datacenter view. The storage silently isn't there, and the job either fails (good, if someone hears about it) or writes into an empty local directory and fills your root disk (very bad).

Fix 1: use the native NFS storage type

The cleanest fix is to let Proxmox own the mount. With the native NFS storage type, Proxmox manages the mount and marks the storage offline if it fails, so a dropped share becomes a failed job, not a full root disk.

pvesm add nfs nas-backup --server 192.168.10.40 --export /volume1/proxmox \
  --content backup --options vers=4.1
pvesm status

The share then appears under /mnt/pve/nas-backup, and pvesm status tells you whether Proxmox can actually reach it.

While you are there, keep the archives off the default local storage. It works, and it is the worst choice: the archives sit on the same disk as the host.

Fix 2: if you keep your own mount, mark it as a mountpoint

If you have a reason to keep a Directory storage on a path you mount yourself, tell Proxmox the path must be a mountpoint:

pvesm set nas-backup --is_mountpoint yes

That flag tells Proxmox an empty folder at that path is not enough: something has to be mounted there before it counts as the backup storage.

Gotcha 2: root squash breaks backups

vzdump writes as root. Many NAS defaults map root to nobody, which makes backups fail with permission errors.

The fix is on the NAS side: allow root access for the Proxmox hosts' IPs only. Depending on the NAS, the setting is called no_root_squash or "Map root user to admin". Scope it to the Proxmox hosts rather than opening root access to the whole network.

Gotcha 3: a hung NFS server can freeze the host's tools

A hung NFS server with a hard mount can freeze any process touching it. That includes the backup job, pvestatd and the web UI's storage view, so a NAS that stops answering can make the Proxmox host look broken too.

Two habits keep this from biting:

• If your NAS reboots for updates at 2 a.m., schedule backups away from that window.
• Check the storage before you trust a job.

pvesm status                    # every storage should say "active"
df -h /mnt/pve/nas-backup       # should show the NAS size, not the root disk

That df line is the quickest test for the first trap. If the size it reports is your root disk's size, the share is not mounted and anything written there is going to the host.

While you're on the share: set retention

A share that fills up causes the same pain from the other direction: nothing gets pruned, the share fills, and every job after that fails. Set retention on the storage itself, so every job that writes there inherits it:

pvesm set nas-backup \
  --prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3

Make sure a failure actually reaches you

The native storage type turns a dropped share into a failed job, and a failed job only helps if someone hears about it. By default, failures go to the root mailbox on the host, which nobody reads. On Proxmox VE 8.1 and later, set up a target under Datacenter → Notifications, point backup failures at it, and then force a failure on purpose to prove it works:

vzdump 101 --storage does-not-exist

If no message arrives, fix that before anything else.

Checklist: NFS backup storage

• Backup storage is native NFS (or PBS), or has is_mountpoint set
• Archives are not on the default local storage
• The NAS allows root only for the Proxmox hosts' IPs (no_root_squash / "Map root user to admin")
• Backups are scheduled away from the NAS's update and reboot window
• pvesm status shows every storage as "active"
• df -h /mnt/pve/nas-backup shows the NAS size, not the root disk
• Retention is set on the storage with --prune-backups
• A forced failure produces a notification you actually read

Found this useful? Subscribe on YouTube for the daily video, or follow the RSS feed.