Zlib decompression error: [-3] | Failed to decompress LZ4 block

KB ID: 1795
Product: Veeam Backup & Replication
Version: 5.x, 6.x, 7.x, 8.x, 9.x
Published:
Last Modified: 2017-12-07

Challenge

Backup or restore fails with either of the following errors:

Error: Client error: Zlib decompression error: [-3].

OR


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

 

Cause

Cyclic Redundancy Check (CRC) failed while extracting data from a backup file. This indicates that one or more blocks in that file are corrupted.
 
Typically this error indicates hardware malfunction during storage or transmission of the backup file. Most types of storage are subject to a small degree of unrecoverable failure – this is commonly called Bit Rot.

Solution

If you are attempting restore and have multiple copies of the backup file, try using a different copy. If you have other restore points, try an older full backup or an incremental associated with an older full. If you are unable to recover the complete VM, file level recovery may still be possible.
 
If the error is encountered during backup, try running an active full backup. This will bypass the need to read data from previous backup files.
 
The Windows event log on the repository server may contain Disk Event 7: “The device… has a bad block.” If so, run CHKDSK /F or /R. A small number of bad blocks are normal on most storage devices. If additional bad block events occur after running CHKDSK, check the SMART status and consider replacing the disk. If using a Network Attached Storage device, contact your storage vendor to determine what diagnostics are available.

More Information

Veeam Backup & Replication 6.5 added network traffic verification in order to detect corruption which might occur when sending data from a proxy to a repository or other proxy. Decompression errors in 6.5 and later are unlikely to be caused by a malfunctioning NIC, router, or other network device if the repository server is using a local disk. However, when backing up to a CIFS share, malfunctioning network hardware may be the cause of corrupted files.
 
Synthetic full backups and reverse incremental backups both have the potential to copy data from corrupted backup files. Active full backups do not copy any data from existing backup files. Although it is best to perform periodic full-VM recovery tests, you can schedule monthly or quarterly active full backups to reduce the possibility that your latest backup contains corrupted data.
How helpful is this article: 
4.3 out of 5 based on 45 ratings

Couldn't find what you were looking for?

Below you can submit an idea for a new knowledge base article.

Request new content

Report a typo on this page:

Please select a spelling error or a typo on this page with your mouse and press CTRL + Enter to report this mistake to us. Thank you!

Orphus system