Discussions specific to the VMware vSphere hypervisor
Post Reply
Fred_vBrain
Influencer
Posts: 17
Liked: 6 times
Joined: Sep 26, 2013 6:41 am
Full Name: Manfred Hofer
Location: Austria
Contact:

Checking Backup for corruptness

Post by Fred_vBrain » Apr 29, 2016 10:56 pm

Hi all,

this week was not the week of my home lab. I had an issue with my VCSA and I tried to recover it. Everytime I done it I got the following error message:

Error: Client error: Failed to decompress LZ4 block: Incorrect decompression result or length.

I found some thread an KB articel mentioning that maybe the storage could be the problem. I ran several test the last few days and this is the summary:

1. Restore of the entire VM didn't work because of the LZ4 error
2. Restore of the VM files didn't also not work, same LZ4 erro
3. I tried several Restore point incl. Full and Incremental and all failed with LZ4 errors
4. Instant VM Recovery, Cool. Works. And the VM is running. but I couldn't move the VM to another store. With QuickMigrate same LZ4 error, with mv at the command line read error.

The funny thing is that the backup job including the VCSA has also several other VMs and all of them are recoverable. So only the VCSA had this problem.
I don't want to exclude the Synology as the guilty one, I'm using it as SMB backup target and the new DSM6 software doesn't make me feel that comfortable. Maybe there was the problem. But then again, only one VM?

My question is the following. I don't use SureBackup at the moment but I think it couldn't help me because VM was runnable.

Is there another possibility to check the integrity of the backup files?

Cheers,
Fred
Fred | vBrain.info | @Fred_vBrain

VCAP-DCA/DCD/CIA/CID/DTA/DTD, VCIX-NV, VCIX6-DCV/DTM/NV/CMA, VMCE v7-v9, vExpert 2014-18, vExpert NSX 2016-17, Cisco Champion 2015-18, Veeam Vanguard 2016, Dell EMC Elect 2017

veremin
Product Manager
Posts: 16867
Liked: 1429 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Checking Backup for corruptness

Post by veremin » May 02, 2016 9:45 am

The most reliable way to avoid silent data corruption is to run SureBackup jobs with the entire virtual disk content check enabled.

This way not only will you make sure that the backup file hasn't been changed anyhow since the time it was created, but also you'll confirm that VMs themselves are bootable.

Speaking about your situation, are you able to clone this VM or make a new backup of it?

Anyway, the situation looking more like a backup data corruption is certainly worth being investigated closely by support team.

Thanks.

foggy
Veeam Software
Posts: 18242
Liked: 1558 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Checking Backup for corruptness

Post by foggy » May 02, 2016 10:53 am

I don't think the VM can be cloned or backed up, since the backup file contains some unreadable data, which allows Instant Recovery since it could just not need the corresponding blocks to run the VM from backup, however, the attempts to migrate/full restore/whatever else that requires reading the corrupt data will certainly fail. Despite Vladimir's suggestion to use built-in integrity check, I also recommend to have a second copy of your backups in a secondary location for that kind of failures.

Vitaliy S.
Product Manager
Posts: 22968
Liked: 1555 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Checking Backup for corruptness

Post by Vitaliy S. » May 02, 2016 11:04 am

In addition to all restore options you have already tried, test a FLR wizard to retrieve VCSA database. If it restores well, you can re-use it with a new installation of VCSA.

Post Reply

Who is online

Users browsing this forum: evander, Google [Bot], JPatel1990, krishna.kota@hpe.com and 34 guests