Can't restore backups from another Proxmox server

[philled]

I'm trying to sort out the process for restoring vzdump backups taken on server A to server B. The steps I follow are:

1) Take backup with vzdump on server A.
2) Copy .vma file from server A to a NAS over CIFS.
3) Copy .vma file from NAS to server B over CIFS placing it in /var/lib/vz/dump/
4) In the web UI I go to the VM > shut it down then choose Backup > Restore

This always results in an error like this:

restore vma archive: vma extract -v -r /var/tmp/vzdumptmp29105.fifo /var/lib/vz/dump/vzdump-qemu-100-2017_11_02-18_11_48.vma /var/tmp/vzdumptmp29105
CFG: size: 325 name: qemu-server.conf
DEV: dev_id=1 size: 4294967296 devname: drive-virtio0
CTIME: Thu Nov 2 18:11:51 2017
new volume ID is 'local-zfs:vm-100-disk-1'
map 'drive-virtio0' to '/dev/zvol/rpool/data/vm-100-disk-1' (write zeros = 0)

** (process:29106): ERROR **: can't open file /dev/zvol/rpool/data/vm-100-disk-1 - Could not open '/dev/zvol/rpool/data/vm-100-disk-1': No such file or directory
temporary volume 'local-zfs:vm-100-disk-1' sucessfuly removed
TASK ERROR: command 'vma extract -v -r /var/tmp/vzdumptmp29105.fifo /var/lib/vz/dump/vzdump-qemu-100-2017_11_02-18_11_48.vma /var/tmp/vzdumptmp29105' failed: got signal 5

I've tried with compression and without compression and both fail with the same error. If I back up the VM and restore it to the same machine, that works - but is a bit pointless because I want to take a backup that can be restored on another Proxmox server if the main server dies.

Clearly the problem is to do with the "Could not open" part - but why? What am I doing wrong that it can't open this file?

 

[dcsapak]

do you have a zfs root pool on server B ?

 

[philled]

do you have a zfs root pool on server B ?

Yes server B has that directory:

# ls -lh /dev/zvol/rpool/data/
total 0
lrwxrwxrwx 1 root root 13 Nov 2 18:51 vm-100-disk-1 -> ../../../zd48
lrwxrwxrwx 1 root root 13 Nov 2 18:51 vm-101-disk-1 -> ../../../zd16
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-101-disk-1-part1 -> ../../../zd16p1
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-101-disk-1-part2 -> ../../../zd16p2
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-101-disk-1-part5 -> ../../../zd16p5
lrwxrwxrwx 1 root root 13 Nov 2 18:51 vm-102-disk-1 -> ../../../zd32
lrwxrwxrwx 1 root root 13 Nov 2 18:51 vm-102-disk-2 -> ../../../zd64
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-102-disk-2-part1 -> ../../../zd64p1
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-102-disk-2-part2 -> ../../../zd64p2
lrwxrwxrwx 1 root root 15 Nov 2 18:51 vm-102-disk-2-part5 -> ../../../zd64p5
lrwxrwxrwx 1 root root 12 Nov 2 18:51 vm-103-disk-1 -> ../../../zd0
lrwxrwxrwx 1 root root 14 Nov 2 18:51 vm-103-disk-1-part1 -> ../../../zd0p1
lrwxrwxrwx 1 root root 14 Nov 2 18:51 vm-103-disk-1-part2 -> ../../../zd0p2
lrwxrwxrwx 1 root root 14 Nov 2 18:51 vm-103-disk-1-part5 -> ../../../zd0p5

 

[philled]

One thing I've just noticed is that if I scp the file directly from server A to server B without it going to a NAS as an intermediate step, the it can be restored just fine on server B. That implies something about copying it to a NAS is messing up the vma file. But why should that be?

This is the command I'm using for scp (192.168.0.103 is server A):
# scp root@192.168.0.103:/var/lib/vz/dump/vzdump-qemu-100-2017_10_26-20_37_59.vma /var/lib/vz/dump/

 

[philled]

I'm starting to think I may have a RAM issue. The problem now seems to be intermittent with no specific pattern. Sometimes it works, sometimes it doesn't.

 

[VGusev2007]

do you have a zfs root pool on server B ?

Dear, @dcsapak I can confirm this bug. I have zpool tank and I have that problem from time to time when restore.

I suggest proxmox don't wait for zfs create a new vol, so if zfs (or server) have some load (e.g. replication job), I can't restore a backup.

I have pve 5.1-36