Backup Restore Issues

[ane]

Good Morning

I am having the same restore error in diferent machines I have tried to restore one backup. We had to make a fast backup after a CRYPTO infection. I shut down the the machine first and backup it up to an external hdd and restore a previous day full virtual machine. We have try to restore the "encrypted" widnows server 2012 r2 machine in a isolated enviroment with new proxmox 5.1 installation (same as the initial machines) to check some files and folder structure.

But I am facing the same error all times and at the same process percentage. At 84% it fails allways.
I have see in the forum that there is any option of enter in the machine data. How do you see it? This machine has a partition where the data is stored. I need acces to that partition only. I dont need to power up the windows machine.


progress 84% (read 595282493440 bytes, duration 15440 sec)
lzop: Input/output error: /mnt/backups//dump/vzdump-qemu-112-2018_12_17-09_44_03.vma.lzo

** (process:24257): ERROR **: restore failed - short vma extent (3174400 < 3801600)
/bin/bash: line 1: 24256 Exit 1 lzop -d -c /mnt/backups//dump/vzdump-qemu-112-2018_12_17-09_44_03.vma.lzo
24257 Trace/breakpoint trap | vma extract -v -r /var/tmp/vzdumptmp24254.fifo - /var/tmp/vzdumptmp24254
Logical volume "vm-111-disk-1" successfully removed
temporary volume 'local-lvm:vm-111-disk-1' sucessfuly removed
TASK ERROR: command 'set -o pipefail && lzop -d -c /mnt/backups//dump/vzdump-qemu-112-2018_12_17-09_44_03.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp24254.fifo - /var/tmp/vzdumptmp24254' failed: exit code 133

 

[dietmar]

What is the output of

# pveversion -v

 

[ane]

root@pve:~# pveversion -v
proxmox-ve: 5.2-2 (running kernel: 4.15.17-1-pve)
pve-manager: 5.2-1 (running version: 5.2-1/0fcd7879)
pve-kernel-4.15: 5.2-1
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.2-pve5
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-4
libpve-common-perl: 5.0-31
libpve-guest-common-perl: 2.0-16
libpve-http-server-perl: 2.0-8
libpve-storage-perl: 5.0-23
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.0-3
lxcfs: 3.0.0-1
novnc-pve: 0.6-4
proxmox-widget-toolkit: 1.0-18
pve-cluster: 5.0-27
pve-container: 2.0-23
pve-docs: 5.2-3
pve-firewall: 3.0-8
pve-firmware: 2.0-4
pve-ha-manager: 2.0-5
pve-i18n: 1.0-5
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.1-5
pve-xtermjs: 1.0-5
qemu-server: 5.0-26
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.8-pve1~bpo9

 

[ane]

Hello, I have told initially that the target server was runing 5.1 as this was written in the CD but I see that it is in fact 5.2.
I dont know if this could affect the restore process.

 

[dietmar]

Please can you test with latest version?

 

[ane]

Hello.

Tried to restore in the 5.3 version and same error at 84% restore process.

 

[dietmar]

Can you decompress the file manually?

# lzop -d -c /mnt/backups//dump/vzdump-qemu-112-2018_12_17-09_44_03.vma.lzo

Or does that fail also?

 

[sb-jw]

It looks the Backupfile is inconsistent, we have such Problems too. You can try to restore an older one or create a new one and then restore this.

We were are able to solve the Problem with moving the Files from a Synology NAS to an CEPH Cluster. What exactly helped to repair the backups, i dont know, it might be the ECC RAM or Scrubing from CEPH or only moving the Files.

 

[ane]

Hi Dietmar

We have been trying to uncompress as you told us but same issue. It has happened all times we have tried to restore in the same percentage of the restoration. Always near 83%

We dont have other backups as it is the backup of the day before a crypto hit us. We need this backup to check some folder structure made that day.

If the backups in inconsistent, how can we predict of expect this? I mean, if the backup process says it is OK. And one day after if it can be corrupted, what can I do to avoid that?

Thanks

 

[sb-jw]

If the backups in inconsistent, how can we predict of expect this? I mean, if the backup process says it is OK. And one day after if it can be corrupted, what can I do to avoid that?

You need a restore plan to verify your Backups are ok, but normally thats not the Job of a Software. Software can fail, without you know it - so its up on you to verify the restore possibility.

As i wrote here already, we were able to solve this Problem with a simple Moving of the Backup from the current used Space to another Storage (NFS with CEPH in background). Setup up a new VM (e.g. with FreeNAS or OMV) and try it. So i think you have nothing to loose.

And if you really need Backups, then its now the best time to create an Backup and Restore plan. Backups are often ignored or neglected, but its very important for an Company.