Possible to fix VMA backup file?

[kotakomputer]

Backup was successful using Proxmox 3, but restore failed:

# vma verify vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo

** (process:129318): ERROR **: not a vma file - wrong magic number
Trace/breakpoint trap
#

Detail restore message:

restore vma archive: lzop -d -c  /var/lib/vz/dump/vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo|vma extract  -v -r /var/tmp/vzdumptmp129114.fifo - /var/tmp/vzdumptmp129114
CFG: size: 296 name: qemu-server.conf
DEV: dev_id=1 size: 26843545600 devname: drive-ide0
CTIME: Thu Sep 12 10:19:02 2013
Formatting  '/var/lib/vz/images/36189/vm-36189-disk-1.qcow2', fmt=qcow2  size=26843545600 encryption=off cluster_size=65536  preallocation='metadata' lazy_refcounts=off 
new volume ID is 'local:36189/vm-36189-disk-1.qcow2'
map 'drive-ide0' to '/var/lib/vz/images/36189/vm-36189-disk-1.qcow2' (write zeros = 0)
progress 1% (read 268435456 bytes, duration 1 sec)
...........
progress 30% (read 8053063680 bytes, duration 50 sec)
lzop: /var/lib/vz/dump/vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo: Checksum error

** (process:129117): ERROR **: restore failed - short vma extent (2494976 < 3801600)
/bin/bash: line 1: 129116 Exit 1                  lzop -d -c /var/lib/vz/dump/vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo
     129117 Trace/breakpoint trap   | vma extract -v -r /var/tmp/vzdumptmp129114.fifo - /var/tmp/vzdumptmp129114
temporary volume 'local:36189/vm-36189-disk-1.qcow2' sucessfuly removed
TASK  ERROR: command 'lzop -d -c  /var/lib/vz/dump/vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo|vma extract  -v -r /var/tmp/vzdumptmp129114.fifo - /var/tmp/vzdumptmp129114' failed:  exit code 133

Even I decompressed first the restore still error.

This VM contains an MySQL file which I want to retrieve. Is it possible to repair broken vma or just extract all files so I can choose the MySQL file to retrieve?

 

[e100]

lzop: /var/lib/vz/dump/vzdump-qemu-101-2013_09_12-10_19_00.vma.lzo: Checksum error

Looks like your backup is is corrupted, you should figure out how that happened. Bad RAM would be my first guess.

The only way I can see you *maybe* recovering is to manually extract everything so you can tell lzop to ignore the checksums:

-F, --no-checksum
Do not store or verify a checksum of the uncompressed file when compressing or decompressing. This speeds up the operation of lzop a little bit (especially when decompressing), but as unnoticed data corruption can happen in case of damaged compressed files the usage of this option is not generally recommended. Also, a checksum is always stored when compressing with one of the slow compression levels (-7, -8 or -9), regardless of this option.

 

[kotakomputer]

The .vma.lzo (4 GB) file was extracted to vma (7 GB). Now, how to extract the vma so I see every files inside. Hope, the MySQL file not corrupted because I have deleted the original VM.

 

[dietmar]

Now, how to extract the vma so I see every files inside.

# vma extract <filename> <targetdir>

 

[kotakomputer]

# vma extract <filename> <targetdir>

Solved.