When you compress a massive database dump or critical server backup using the bzip2 utility, the resulting .bz2 file is highly dependent on structural integrity. If that file is partially corrupted during a network transfer, a sudden power failure, or due to a bad sector on a hard drive, the standard bunzip2 decompression tool will immediately throw a fatal error (e.g., “data integrity (CRC) error in data”) and stubbornly refuse to extract any of your data, even the parts that are perfectly fine. To rescue the surviving data from a damaged archive, you must use the bzip2recover command.
Understanding bzip2 Data Blocks
To understand how recovery works, you must understand how bzip2 builds its archives. Unlike older compression formats that treat a file as one massive, continuous stream of data, the bzip2 algorithm breaks the original file into hundreds or thousands of distinct, independent blocks (usually around 900 kilobytes each). It then compresses each block separately and strings them together.
If corruption occurs in block #45, standard decompression tools simply give up. However, block #44 and block #46 are likely perfectly fine. The bzip2recover tool is designed to crack open the broken archive, locate the healthy blocks, and rip them out so you can manually decompress them.
How to Use bzip2recover
The utility requires only one argument: the name of the corrupted file.
bzip2recover corrupted_backup.bz2The moment you run this command, the tool will furiously scan the file, searching for the specific mathematical signatures that mark the start and end of individual data blocks.
It will not attempt to decompress the data; instead, it will extract every single block it finds and save them into your current directory as dozens (or hundreds) of tiny, individual .bz2 files, usually named sequentially like this:
rec00001corrupted_backup.bz2rec00002corrupted_backup.bz2rec00003corrupted_backup.bz2
Decompressing the Recovered Blocks
Once bzip2recover finishes its extraction, your current directory will be flooded with these tiny files. You must now attempt to decompress them.
Because some of these extracted blocks might still contain the original corruption that caused the fatal error in the first place, you should attempt to decompress all of them simultaneously while forcing the system to ignore any errors. You can do this by using the wildcard (*) symbol and the standard bzip2 decompression command.
bzip2 -d rec*corrupted_backup.bz2The decompression utility will attempt to unpack every single recovered block file. If it encounters the damaged block (e.g., block #45), it will still throw a CRC error and fail to extract that specific block. However, it will successfully decompress the healthy blocks, leaving you with a collection of raw text or binary data fragments.
If you were recovering a text-based log file or a SQL dump, you can now use the cat command to glue the surviving, uncompressed blocks back together in sequential order, successfully rescuing the vast majority of your critical data.