Failed to decompress LZ4 block

[brunofernandez]

Hi there

I've actually a problem with one of my backup jobs.
Each time the backup starts, the job fails wit this error:

Code: Select all

Error: Client error: Failed to decompress LZ4 block: Incorrect decompression result or length (result: '-416297', expected length: '524288'). 

It seems like my backup files are corrupted.

The backups are acutally stored on a Solaris server who acts as a CIFS Server. After talking with a Unix admin they told me that they had a disk error and had to change one of them.
This could maybe be the reason for the corrupted file?

this backup job is not that important so that i've deleted the actual backup files and started the jobs again.
everything is ok again.

but i would like to know how to go on when this occurs to my productive enviroment! i don't would like to delete all my restore points and beginn from zero.

thx for your help.

regards
bruno

[veremin]

Seems like problems with underlying storage device resulted in backup file corruption. Therefore, it's recommended to do both test backup data in automatic fashion with SureBackup functionality, and follow 3-2-1 backup rule, using backup copy jobs.

This way, you will be aware about any issues related to inconsistent backup data and, also, you will be protected against accidental data corruption problems.

Thanks.

[brunofernandez]

we have only the standard edition. so Surebackup is no option for us.
copying the files to another server could be a good idea. but i think that they backup the unix system allready with netbackup.
so i could restore the files from the netbackup and then restore the VMs with veeam

have to check this with our unix admin. thx and regards!

Bruno

[veremin]

The backup copy job doesn't copy backup file as a whole, but rather synthetically creates required restore points in "target" location from VM data in source backup repositories. I still suggest looking into this functionality, since not only will it give you all-in-one solution, but also it will reduce the number of steps needed for restoration procedure.

Thanks.

[rjaworski]

Here is a common fix that works on most of repository - related issues with various Veeam B&R versions

Before retrying backup on failing VM’s go to the path on the repository, rename the folder containing most recent backup of failing VM’s.
In Veeam, go to ‘backup and replication’ tab->backups->disk, right click the failing job, then “delete from disk” ( don’t worry, you have renamed the folder so you will only remove the entry from Veeam’s library)
Once this is completed, you can rename the folder back to the original name or simply leave it “as is”, it doesn’t matter. Now go to repositories, and edit the repository’s properties, on the last page select “import backups from repository” (Simple re-synchronizing repository will not work). Once backups are re-imported you can retry job without running active full back for all VM’s included in the job. You will actually run a full backup, but only on failing VM’s (and rebuild what it was missing). You could either try simply running active full backup, but there is not always time for that.
I hope this is pretty straight forward, just a few clicks that might save you some time.

[Delo123]

I would certainly make sure the repository is ok before you start storing backups again. They should recalculate raid parity on that array to make sure everything is ok again. Sure Backup will not help here (at least it didn't help us) since the corrupt data isn't necessarily touched when booting the vm. We had this on one of our Exchange Vm's some years ago and nocited the issue after 80% had been migrated by live vmotion... Instant recovery will then instantly stop and all your data is gone "again", so please be very carefull regarding data corruption...