Why this matters beyond the homelab: An alert firing on the day something breaks is the easy case. This one fired on the day the symptom finally became visible, months after the actual failure. The gap between those two dates is the whole story.
The alert
Grafana flagged Node-A’s pve-root volume at 85% capacity. Node-A (FCM2250) isn’t supposed to be anywhere near that: it’s the compute node, not the storage node, and its root volume has no business holding gigabytes of anything.
df -h confirmed the number. du -sh /* pointed straight at /var/lib/vz/dump, full of vzdump backup archives that had no reason to be there. Every VM and LXC on the fleet has backups configured to land on an NFS share hosted on Node-B (192.168.1.11), not on local storage.
The actual root cause
The backup storage was defined in Proxmox as a Directory storage pointing at a local path, with the NFS share mounted over that path. That setup has a sharp edge. When the mount is missing, the path still exists as an empty directory on pve-root, and Proxmox sees a perfectly healthy directory and writes into it. It has no way to tell “wrote to the NFS share” from “wrote to whatever happened to be at that path when the share wasn’t there.”
The nofail option on the mount is a smaller part of the story than it first looked. It only tells the system to keep booting if the mount fails, which is the right choice for a mount that shouldn’t block boot. It says nothing about what a backup job does afterward. The thing that was actually missing was a check that something is really mounted at the path before writing to it.
The mount had been silently broken since April. Every nightly vzdump job since then wrote its archive straight onto pve-root, and nothing in that chain threw an error, because nothing was configured to expect one. Four months of nightly backups, all landing in the wrong place, discovered only when the wrong place ran out of room.
The fix
Restoring the actual NFS mount and re-running backups against it reclaimed 66GB and dropped the volume from 85% to 11%. That cleared the symptom. The structural fix came afterward and is one line:
pvesm set ext-backup --is_mountpoint yes
With is_mountpoint set, Proxmox refuses to use the storage unless something is actually mounted there, so a dropped share makes the backup fail loudly instead of quietly filling the root volume. Defining the share as an NFS-type storage instead of a Directory is the other correct approach, since NFS storage is mount-aware by design. Finding the problem took longer than fixing it, because the failure mode doesn’t announce itself.
The lesson
A mount that matters needs two things: something that fails when it’s gone, and something that notices. nofail is the right choice when a mount is genuinely optional and shouldn’t block a boot, and it is the wrong thing to lean on for anything a backup job depends on. A backup job that writes to the wrong place succeeds just as quietly as one that writes to the right one. If the path matters, tell Proxmox to check that it’s a real mountpoint.
Update, October 2026
A later review caught the part of this I had understated: the Directory-type storage, not nofail, was the real hazard. The same thing happened again on Node-C, where the backup mount failed around late July and roughly 46GB of archives landed on its root volume before the storage was moved to is_mountpoint yes and the stray copies were cleaned up. The local drive is now a rolling working set with a keep-last retention policy, and Azure holds the full history.