Convert TBZ2 to TAR Online (Reversing Bzip2 Compression)

Reversing Bzip2's Block Compression Without Touching Tar's Own Structure

Converting a .tbz2 file to a plain .tar file only requires reversing bzip2's compression — decoding the Burrows-Wheeler-transformed, move-to-front-shifted, Huffman-coded blocks back into the exact byte stream tar originally produced before compression was ever applied. No repacking of the tar structure itself happens anywhere in this process: the file headers, permissions, ownership fields, and file order tar wrote stay completely untouched, since bzip2 compressed that stream as one continuous pass without altering anything inside it.

This makes the conversion fundamentally different from turning a .tbz2 into a ZIP or a 7Z, where the destination format has a completely different internal layout the files have to be rebuilt into. Here, the source and destination share the identical tar structure — only the compression wrapped around that structure is being removed, not replaced with anything else.

This particular direction is also computationally lopsided compared to most format changes: undoing bzip2's compression is generally faster than the original compression pass was, since decompression skips the expensive search for the best possible Burrows-Wheeler sort and Huffman code assignment — work that only ever has to happen once, at the moment the .tbz2 was first built.

Three Documented Reasons to Remove Compression Instead of Adding It

LTO tape drives include their own built-in hardware compression chip that compresses data as it streams to tape. Feeding that drive data already compressed by bzip2 defeats the hardware compressor almost entirely, since already-compressed bytes look close to random and leave little repetitive structure for the tape drive's own compression to find — in practice, this can actually reduce a tape's effective usable capacity compared to writing genuinely uncompressed data and letting the drive's hardware handle compression instead.

A second documented reason involves deduplicating and delta-based backup tools such as Borg and restic, which work by finding chunks of data that repeat across different backup runs. Bzip2 compression scrambles those repeating byte patterns into a form where matching chunks between two mostly-similar backups no longer look alike at the byte level, breaking the deduplication these tools rely on. Feeding them uncompressed tar data, and letting the backup tool apply its own compression internally after deduplication runs, is the documented, recommended approach in both projects' own setup guides.

A third, less-discussed reason involves rsync's delta-transfer algorithm, which relies on rolling checksums to identify which blocks of a file changed between two versions so only those blocks need to be sent over the network. Because bzip2's Burrows-Wheeler transform reorders bytes based on surrounding context, a tiny change to one part of the original uncompressed data can shift the compressed bytes across an entire block, not just at the point of the actual edit — an avalanche effect that leaves rsync's block-matching with little to latch onto between two versions of the same .tbz2. Comparing or syncing the extracted tar contents directly, rather than the compressed archive, avoids this problem entirely.

What Decompressing Back to Plain TAR Gains and Gives Up

• Gain — compatibility with hardware and software that compresses on its own: LTO tape drives with built-in compression chips and deduplication-based backup tools both perform better on uncompressed input.
• Gain — instant readability without a decompression step: a plain tar file can be listed, scanned, or partially read by any tar-aware tool immediately, without running it through bzip2 first.
• Gain — meaningful diffs and rsync transfers: comparing or syncing extracted tar content byte-for-byte works predictably, unlike comparing two bzip2-compressed archives where a tiny underlying change can shift compressed bytes across an entire block.
• Lose — the size reduction bzip2 provided: a decompressed tar file is always at least as large as, and typically several times larger than, the original .tbz2 it came from.
• Lose — the per-block CRC protection bzip2's compressed format carries: plain tar has no equivalent built-in integrity check comparable to bzip2's per-block CRCs.
• Unchanged — every file's content and permissions: since decompression alone doesn't touch the tar structure, filenames, permissions, and ownership bits carry over exactly as they were.

Which Tools Handle This Decompression Without Extra Installs

GNU tar's -j flag and BSD tar's equivalent both decompress a .tbz2 directly, either writing out a plain .tar file or extracting its contents straight away, skipping an intermediate uncompressed file entirely if that's all that's needed. Windows 10's built-in tar.exe, based on libarchive, supports the same decompression from the command line since version 1803, so no additional software is required on any of the three major desktop platforms just to strip bzip2 compression back off a .tbz2.

Enterprise backup software targeting tape libraries, along with deduplicating tools like Borg, restic, and Bacula, generally documents this exact recommendation directly in their own setup guides: feed the tool, or the tape drive, uncompressed data, and let whichever stage actually benefits from compression handle it, rather than compressing twice or in an order that defeats a later, more effective compression pass.

A related case involves network transfers over a link that already applies its own compression, such as an SSH connection using its -C option. Sending a bzip2-compressed .tbz2 over that link wastes CPU time on both ends compressing data that's already compressed, without shrinking the transferred bytes any further, so stripping the bzip2 layer first and letting transport-level compression do the work once is the more efficient order of operations.

Documented Complaints That Trace Back to Compressing Too Early

A recurring pattern on backup and sysadmin forums involves someone noticing their LTO tape usage is worse than expected after switching to pre-compressed .tbz2 archives, then tracing the cause back to feeding the tape drive's own hardware compressor data that's already been through bzip2 — since already-compressed data has little repetitive structure left, the drive's compression chip can't do much with it, and actual usable capacity ends up slightly lower in the worst cases than writing uncompressed data directly.

A second documented complaint involves deduplication ratios collapsing after someone starts feeding a tool like restic or Borg pre-compressed .tbz2 archives instead of raw files or plain tar streams — support documentation for both tools consistently explains that compression scrambles the byte-level similarity deduplication depends on to find matching chunks across backup runs, and the fix is decompressing first and letting the backup tool's own internal compression handle it at a stage where it doesn't interfere with matching.

A third, more everyday scenario involves needing to quickly inspect or edit one file inside an archive repeatedly without paying bzip2's decompression and recompression cost each time — some workflows decompress a frequently accessed .tbz2 into a plain tar once and keep it that way specifically to avoid repeating bzip2's relatively CPU-heavy block-sorting step on every single access, a trade that only makes sense when disk space is cheaper than CPU time, which is increasingly common on current storage.

TBZ2's Compressed Stream Against a Plain Uncompressed Tar

Common Questions About Converting TBZ2 Back to Plain TAR

Why would I want to remove compression instead of keeping it?
Several documented workflows benefit from it: LTO tape drives with built-in hardware compression work better on uncompressed input, deduplicating backup tools like Borg and restic need uncompressed data to detect repeated chunks, and rsync's delta transfers work more efficiently on uncompressed content.

Does decompressing a TBZ2 to TAR change any of the files inside?
No. This conversion only reverses bzip2's compression step; the tar structure, including filenames, permissions, and file data, remains exactly as tar originally wrote it.

Why does pre-compressing data hurt my tape backup capacity?
LTO tape drives include their own hardware compression chip. Feeding it already-compressed data, which looks close to random at the byte level, leaves little for that chip to compress, and effective usable capacity can end up slightly lower than writing genuinely uncompressed data.

Why does a small edit change so much of my TBZ2's compressed bytes?
Bzip2's Burrows-Wheeler transform reorders bytes based on surrounding context, so a single change to the source data can shift compressed output across an entire block, not just at the edit point, which is why tools that rely on byte-level similarity, like rsync, struggle to compare two versions of a compressed archive directly.

Can I decompress a TBZ2 without any extra software?
On Linux and macOS, yes — tar's built-in bzip2 support handles it directly. On Windows 10 (version 1803 and later), the built-in tar.exe supports the same decompression from the command line.

Is decompressing a TBZ2 to TAR faster than the original compression was?
Generally yes. Bzip2 decompression skips the computationally expensive search for the best Burrows-Wheeler sort and Huffman code assignment that compression requires, since that work only needs to happen once when the archive is first built.