PBS Backup issue on only 1 node out of 3

L

lucid13

New Member
Sep 19, 2025
8
1
3
Hi All,

I've been looking for a while but haven't found any resolution to my issue. I have 3 separate proxmox nodes on 3 machines. I set up a PBS instance on a 4th machine (Synology NAS). Right now 2 of my nodes back up with no issue. The 3rd node does not back up and is giving errors. The only difference with this 3rd instance is that I have Proxmox running on a ZFS pool. I'm running Proxmox 8.4.14 on all nodes and PBS 3.3.3. Here's what I'm getting as an error on the first LXC (I've tried starting from the 2nd but get the same errors).

INFO: starting new backup job: vzdump 300 301 302 303 304 305 306 307 308 309 310 311 312 --prune-backups 'keep-last=3' --node pve3 --storage pbs --fleecing 0 --notes-template '{{guestname}}' --all 0 --mode snapshot
INFO: Starting Backup of VM 300 (lxc)
INFO: Backup started at 2025-12-19 14:39:40
INFO: status = running
INFO: CT Name: redacted
INFO: including mount point rootfs ('/') in backup
INFO: including mount point mp0 ('data') in backup
INFO: found old vzdump snapshot (force removal)
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: suspend vm to make snapshot
INFO: create storage snapshot 'vzdump'
INFO: resume vm
INFO: guest is online again after 5 seconds
INFO: creating Proxmox Backup Server archive 'ct/300/2025-12-19T19:39:40Z'
INFO: set max number of entries in memory for file-based backups to 1048576
INFO: run: lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client backup --crypt-mode=none pct.conf:/var/tmp/vzdumptmp34244_300/etc/vzdump/pct.conf root.pxar:/mnt/vzsnap0 --include-dev /mnt/vzsnap0/./ --include-dev /mnt/vzsnap0/.data --skip-lost-and-found --exclude=/tmp/?* --exclude=/var/tmp/?* --exclude=/var/run/?*.pid --backup-type ct --backup-id 300 --backup-time 1766173180 --entries-max 1048576 --repository backup@pbs@192.168.1.116:synology_nfs
INFO: Error: fstat "/mnt/vzsnap0/.data" failed - ENOENT: No such file or directory
umount: /mnt/vzsnap0data: no mount point specified.
command 'umount -l -d /mnt/vzsnap0data' failed: exit code 32
ERROR: Backup of VM 300 failed - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client backup '--crypt-mode=none' pct.conf:/var/tmp/vzdumptmp34244_300/etc/vzdump/pct.conf root.pxar:/mnt/vzsnap0 --include-dev /mnt/vzsnap0/./ --include-dev /mnt/vzsnap0/.data --skip-lost-and-found '--exclude=/tmp/?*' '--exclude=/var/tmp/?*' '--exclude=/var/run/?*.pid' --backup-type ct --backup-id 300 --backup-time 1766173180 --entries-max 1048576 --repository backup@pbs@192.168.1.116:synology_nfs' failed: exit code 255


Any help would be much appreciated!
 
Last edited:
that's a hell of an output... not sure about everyone else but I really like seeing each INFO output in it's own line...

anyway, I see: fstat "/mnt/vzsnap0/.data" failed - ENOENT: No such file or directory
 
Sorry I fixed the formatting.

Is there a reason that "/mnt/vzsnap0/.data" wouldn't be created during backup? I don't have any issues with my other nodes.
 
My recommendations... go through each error as they were found. check that first one that I mentioned... is it mounted? If it's not mounted well... it'll fail right there.
 
Pouch6867 said:
My recommendations... go through each error as they were found. check that first one that I mentioned... is it mounted? If it's not mounted well... it'll fail right there.
Click to expand...
Unfortunately, when I search "Error: fstat "/mnt/vzsnap0/.data" failed - ENOENT: No such file or directory" I get my own posts. The folder /mnt/vzsnap0 is empty. I didn't have to create anything for my other nodes. It just worked.
 
Last edited:
could you post the config of the affected container?
 
fabian said:
could you post the config of the affected container?
Click to expand...
I skipped the first container thinking it could be an isolated issue, but the same error happens on any subsequent container. This server has a zfs pool of 2 ssd's for proxmox and VM data. There's also another zfs pool for a media NAS. I'm only trying to back up the system data so I can upgrade all of my nodes to 9.1, but this node is the only one giving me issues. It's also the only one that I'm running zfs on for proxmox and apps.
 
please post the config(s) nevertheless..
 
I mean "pct config XXX", where XXX is the container's ID
 
Code: 
Linux pve3 6.8.12-15-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-15 (2025-09-12T11:02Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Dec 22 11:41:58 EST 2025 on pts/0
root@pve3:~# pct config 300
arch: amd64
cores: 2
features: keyctl=1,nesting=1
hostname: container1
memory: 2048
mp0: vault:subvol-305-disk-1,mp=data,backup=1,size=20000G
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:6C:D8:C0,ip=dhcp,ip6=auto,type=veth
onboot: 1
ostype: debian
parent: vzdump
rootfs: local-zfs:subvol-300-disk-0,size=5G
swap: 512
unprivileged: 1
unused0: data:300/vm-300-disk-0.raw
 
Code: 
mp0: vault:subvol-305-disk-1,mp=data,backup=1,size=20000G

the "data" there should be "/data". it seems this is not handled correctly in the backup code, but works by chance during regular startup.
 
  • Like
Reactions: lucid13
fabian said:
Code: 
mp0: vault:subvol-305-disk-1,mp=data,backup=1,size=20000G

the "data" there should be "/data". it seems this is not handled correctly in the backup code, but works by chance during regular startup.
Click to expand...
That worked! Thank you so much. I'll be sure to pay closer attention when mounting drives.
 
  • Like
Reactions: fabian
Hi,

This issue doesn’t appear to be related to Proxmox Backup Server or the NAS.

On the affected node, the containers have an extra data folder attached. During backup, Proxmox tries to include that folder, but it’s not available at the moment the backup snapshot is created, so the backup fails.

This is why:
  • The other two nodes back up successfully
  • All containers on this one node fail in the same way

As a test, you can try running the backup without that extra data folder, or exclude it from the backup. If the backup succeeds, then that folder is the cause.

To fix it permanently, the data folder needs to be stored in a location that supports snapshots, or marked so it’s not included in backups.
 
You must log in or register to reply here.
Top Bottom