Checking Backup for corruptness

[Fred_vBrain]

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

[veremin]

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]

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.]

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.