Backup Error "vma_writer_register_stream 'drive-scsi0' failed" (PVE 6.1-7)

[nidaren]

I was having exactly same problem as the OP (with the same error reported), but in my case reboot of the proxmox helped and after I was able to make the backup with no issue.
I remember I have made an update and upgrade right before the error occurred, but not sure if it does have any impact on its occurrence.

 

[Dominic]

Thanks for fixing my small mistake in the zfs get all We suspected compression to be responsible, now apparently those worked better than uncompressed.

Some more questions:

1. You said that with the cloned templates backups work. That means you could just delete the old template and use the working cloned ones?
2. Is it possible that there is a connection between load and failing backups? Is your ZFS doing less when the backups succeed?

Additionally, for Windows 4k blocksize might be beneficial.

@nidaren Just to be sure: "same problem" also means that your template is on ZFS?

 

[bootsie123]

Hi! Sorry for the long gap in between responses. Thanks for the blocksize tip for windows by the way!

For your first question, yes. I could delete the old templates and use the working cloned ones. However, I have a few linked clones using the templates. Is there a way I could switch which template it uses?

For the answer to your second question, I don't believe there is a connection between the load and failing backups. I haven't tried with all of the VMs stopped, however, I have tried when the VMs were running at idle and I still came across the same error.

Since last time, it seems that my VMs are backing up fine now. It's just the templates that keep getting the error when they backup.

 

[Dominic]

Hi!

When load is not the problem, we assume that there is something going wrong with the blocksizes in the bad templates. Therefore the easiest/least headache solution might be to create a full clone or backup & restore of your remaining linked clones that use the templates and forget about the problematic templates. Are we talking about much disk space that this would cost?

 

[bootsie123]

That could work. I have enough disk space. Theoretically, I shouldn't have any more problems with new templates right? It would be great to not have to redo my templates, but I wouldn't mind it if that fixed the issue.

I did a little test and created a new VM template much like the other ones and it seems to work

 

[Dominic]

I did a little test and created a new VM template much like the other ones and it seems to work

Testing this and having backups is certainly a good idea. This way any unexpected problems

Theoretically, I shouldn't have any more problems with new templates right?

remain small problems.

 

[bootsie123]

I guess that settles the issue. I'll set up some new templates and clone the linked VMs. I'll set this topic to solved after a few weeks of monitoring if all goes well. Thanks for the help and all of the patience with trying to work this out!

 

[bootsie123]

Many updates after I'm still running into this issue even after creating a new VM and converting it into a template and then backing it up. However, I've decided that I don't think it's worth pursuing the issue any further. Thinking back on it now it seems a little redundant to automatically backup templates since they are read-only anyway and shouldn't be changing. Instead, only one backup is really necessary. Granted it doesn't get corrupt and it's saved in a few different locations

INFO: starting new backup job: vzdump 112 --remove 0 --storage prox_backup --node vmworld --mode stop --compress zstd
INFO: Starting Backup of VM 112 (qemu)
INFO: Backup started at 2020-06-05 12:02:16
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: Windows-10-v4-No-Apps
INFO: include disk 'scsi0' 'local-zfs:base-112-disk-0' 32G
INFO: include disk 'efidisk0' 'local-zfs:base-112-disk-1' 1M
INFO: creating archive '/mnt/data/backup/dump/vzdump-qemu-112-2020_06_05-12_02_16.vma.zst'
INFO: starting template backup
INFO: /usr/bin/vma create -v -c /mnt/data/backup/dump/vzdump-qemu-112-2020_06_05-12_02_16.tmp/qemu-server.conf exec:zstd --rsyncable --threads=1 > /mnt/data/backup/dump/vzdump-qemu-112-2020_06_05-12_02_16.vma.dat drive-efidisk0=/dev/zvol/rpool/data/base-112-disk-1 drive-scsi0=/dev/zvol/rpool/data/base-112-disk-0
INFO: vma: vma_writer_register_stream 'drive-scsi0' failed
ERROR: Backup of VM 112 failed - command '/usr/bin/vma create -v -c /mnt/data/backup/dump/vzdump-qemu-112-2020_06_05-12_02_16.tmp/qemu-server.conf 'exec:zstd --rsyncable --threads=1 > /mnt/data/backup/dump/vzdump-qemu-112-2020_06_05-12_02_16.vma.dat' 'drive-efidisk0=/dev/zvol/rpool/data/base-112-disk-1' 'drive-scsi0=/dev/zvol/rpool/data/base-112-disk-0'' failed: got signal 5
INFO: Failed at 2020-06-05 12:02:16
INFO: Backup job finished with errors
TASK ERROR: job errors

It's worth noting that at one point I did receive the more detailed output of the vma failed at some point. Although I don't record those logs and can't really find it again