ERROR: Backup failed - start failed Unit already exists

[genesio]

I noticed that the backup only fails if executed in "stop" mode. Snapshot mode always works correctly

 

[Kirill xSide]

I noticed that the backup only fails if executed in "stop" mode. Snapshot mode always works correctly

In my case, the error occurs in the stop mode and in the suspend mode, on the second launch of the backup, in fact, in my opinion, the backup service gives a command to stop or suspend the guest OS, the command is executed on the guest OS, but does not return a message about the completed the command that causes the timeout to perform the operation prescribed in the backup service logic, after the guest OS is frozen, and therefore we see a frozen scope

 

[Deon]

This has been on ongoing problem for me for more than a year now, on numerous VM's - Windows and Linux Guests. Some running with virtio, some running in sata mode. This occurs if the backup mode is Snapshot and in Stop mode. When is it going to be fixed? I only run daily backups, never twice on the same day, but daily at least one of my VM backups will fail. Not always the same one in consecutive days, sometimes the same one 3 days in a row - no consistency with the failures.


vzdump 102 --node node1 --mode stop --storage qnap-2bay-nas-vmbackups --mailnotification failure --mailto my@emailaddress.com --quiet 1 --compress lzo

102: 2019-06-25 22:30:02 INFO: Starting Backup of VM 102 (qemu)
102: 2019-06-25 22:30:02 INFO: status = running
102: 2019-06-25 22:30:03 INFO: update VM 102: -lock backup
102: 2019-06-25 22:30:03 INFO: backup mode: stop
102: 2019-06-25 22:30:03 INFO: ionice priority: 7
102: 2019-06-25 22:30:03 INFO: VM Name: BlueBox1.5
102: 2019-06-25 22:30:03 INFO: include disk 'sata0' 'ssdpool:vm-102-disk-1' 165G
102: 2019-06-25 22:30:03 INFO: stopping vm
102: 2019-06-25 22:30:19 INFO: creating archive '/mnt/pve/qnap-2bay-nas-vmbackups/dump/vzdump-qemu-102-2019_06_25-22_30_02.vma.lzo'
102: 2019-06-25 22:30:19 INFO: starting kvm to execute backup task
102: 2019-06-25 22:30:20 INFO: restarting vm
102: 2019-06-25 22:30:22 INFO: guest is online again after 19 seconds
102: 2019-06-25 22:30:22 ERROR: Backup of VM 102 failed - start failed: org.freedesktop.systemd1.UnitExists: Unit 102.scope already exists.


vzdump 103 --node node1 --mailnotification failure --compress lzo --mailto my@emailaddress.com --storage qnap-2bay-nas-vmbackups --quiet 1 --mode stop

103: 2019-06-24 18:00:02 INFO: Starting Backup of VM 103 (qemu)
103: 2019-06-24 18:00:02 INFO: status = running
103: 2019-06-24 18:00:03 INFO: update VM 103: -lock backup
103: 2019-06-24 18:00:03 INFO: backup mode: stop
103: 2019-06-24 18:00:03 INFO: ionice priority: 7
103: 2019-06-24 18:00:03 INFO: VM Name: Vault
103: 2019-06-24 18:00:03 INFO: include disk 'virtio0' 'saspool:vm-103-disk-0' 300G
103: 2019-06-24 18:00:03 INFO: stopping vm
103: 2019-06-24 18:00:35 INFO: creating archive '/mnt/pve/qnap-2bay-nas-vmbackups/dump/vzdump-qemu-103-2019_06_24-18_00_01.vma.lzo'
103: 2019-06-24 18:00:35 INFO: starting kvm to execute backup task
103: 2019-06-24 18:00:36 INFO: restarting vm
103: 2019-06-24 18:00:38 INFO: guest is online again after 35 seconds
103: 2019-06-24 18:00:38 ERROR: Backup of VM 103 failed - start failed: org.freedesktop.systemd1.UnitExists: Unit 103.scope already exists.



root@node1:~# pveversion -v
proxmox-ve: 5.4-1 (running kernel: 4.15.18-14-pve)
pve-manager: 5.4-6 (running version: 5.4-6/aa7856c5)
pve-kernel-4.15: 5.4-3
pve-kernel-4.15.18-15-pve: 4.15.18-40
pve-kernel-4.15.18-14-pve: 4.15.18-39
pve-kernel-4.15.18-13-pve: 4.15.18-37
pve-kernel-4.15.18-12-pve: 4.15.18-36
pve-kernel-4.15.18-11-pve: 4.15.18-34
pve-kernel-4.15.18-10-pve: 4.15.18-32
pve-kernel-4.15.18-9-pve: 4.15.18-30
pve-kernel-4.15.18-7-pve: 4.15.18-27
pve-kernel-4.15.18-5-pve: 4.15.18-24
pve-kernel-4.15.18-4-pve: 4.15.18-23
pve-kernel-4.15.18-1-pve: 4.15.18-19
pve-kernel-4.15.17-2-pve: 4.15.17-10
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.15-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-10
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-52
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-43
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-28
pve-cluster: 5.0-37
pve-container: 2.0-39
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-22
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-52
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2

 

[mira]

It should be fixed in qemu-server 5.0-54. The package will soon hit our pvetest repository.

 

[Deon]

It should be fixed in qemu-server 5.0-54. The package will soon hit our pvetest repository.

Ok great - thank you. Will look out for the update.

 

[genesio]

I can confirm that I got no more backup errors with the new update

Thank you

 

[Deon]

I can also confirm that the latest updated fixed the issue, I haven't had one failure/error on the backup.
Thank you

 

[t.lamprecht]

OK, great - thanks for the feedback and especially much thanks to @wbumiller for doing the ungrateful "systemd unit scope waiting over DBus" work here which finally solved this issue.

 

[Kirill xSide]

OK, great - thanks for the feedback and especially much thanks to @wbumiller for doing the ungrateful "systemd unit scope waiting over DBus" work here which finally solved this issue.

Colleagues, the question of updating. Backup issue fixed in qemu-server 5.0-54 update. When updating one node in a cluster, won't the cluster become out of sync?

 

[t.lamprecht]

Colleagues, the question of updating. Backup issue fixed in qemu-server 5.0-54 update. When updating one node in a cluster, won't the cluster become out of sync?

No, you can (and should!) update a stable minor update without issues, i.e, as long as you do not change the 5.X/Stretch repositories out with 6.X/Buster ones for a major upgrade you should be always fine to upgrade over the WebGUI, or over CLI with

apt update
apt full-upgrade

But yes, you should not run the cluster with one node on very old updates and one node on very new, but as the upgrade is normally unproblematic it should be no issue to just update all nodes to the latest version of the Release you're currently using - it won't make the cluster out-of-sync, or the like.