Convert TBZ to TAR Online (Removing Bzip2 Compression)
Why stripping bzip2 compression back off a tar archive is a deliberate, well-documented step in several real backup and storage workflows, not a downgrade.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Stripping the Bzip2 Layer Back to a Plain Tar Container
Converting a TBZ file to a plain TAR is the simpler of the two directions this pair can go: it only requires reversing bzip2's compression, decoding the Burrows-Wheeler-transformed, Huffman-coded blocks back into the exact original byte stream tar produced before compression was ever applied. No repacking or rebuilding of the tar structure itself happens — the file headers, permissions, and layout tar originally wrote stay completely untouched, since bzip2 compressed that stream as one continuous pass without altering what was inside it.
This makes a TBZ-to-TAR conversion fundamentally a decompression operation rather than a format change in the way TBZ-to-ZIP or TBZ-to-7Z conversions are, where the target format has an entirely different internal structure. Here, both the source and the destination share the exact same tar layout; only the compression wrapped around that layout is being removed.
Because of that, this particular conversion is also computationally asymmetric compared to most format changes: undoing bzip2's compression is generally faster than the original compression pass was, since decompression skips the expensive step of searching for the best possible Burrows-Wheeler sort and Huffman code assignment, work that only has to happen once, when the file is first compressed.
Why Anyone Would Deliberately Remove Compression Instead of Adding It
One well-documented reason involves LTO tape drives, which include their own built-in hardware compression chip that compresses data as it streams to tape. Feeding that drive data that's already been compressed by bzip2 defeats the hardware compressor almost entirely, since already-compressed data looks close to random at the byte level and has little repetitive structure left for the tape drive's compression to exploit — in practice, this can actually reduce the effective usable capacity of a tape slightly compared to writing genuinely uncompressed data and letting the drive's own hardware handle compression instead.
A second real reason involves backup tools that rely on deduplication or delta compression across multiple versions of similar data, such as Borg or restic. These tools work by finding chunks of data that repeat across different backup runs, but bzip2 compression scrambles those repeating byte patterns into a form where matching chunks between two backups of mostly-the-same data no longer look similar at the byte level, breaking the deduplication these tools depend on. Feeding them uncompressed tar data, and letting the backup tool apply its own compression internally after deduplication, is the documented, recommended approach.
What Decompressing to Plain TAR Gains and What It Gives Up
- Gain — compatibility with hardware and software that compresses on its own: tape drives with built-in compression chips and deduplication-based backup tools both work better on uncompressed input.
- Gain — instant readability without a decompression step: a plain tar file can be inspected, listed, or partially read by any tar-aware tool immediately, without first running it through bzip2.
- Gain — faster access for tools that need to scan the archive repeatedly: repeated reads of a decompressed tar avoid paying bzip2's decompression cost every single time.
- Lose — the actual size reduction bzip2 provided: a decompressed tar is always at least as large as, and typically several times larger than, the original TBZ 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.
- Lose — nothing about the files' actual content or permissions: since decompression alone doesn't touch the tar structure, filenames, permissions, and ownership bits carry over unchanged.
Where Plain TAR Files Get Used Instead of a Compressed Variant
Every major operating system's tar implementation handles this decompression step directly: GNU tar's -j flag and BSD tar's equivalent both decompress a TBZ and either write out a plain .tar file or extract its contents directly, skipping an intermediate uncompressed file entirely if that's all that's needed. Windows 10's built-in tar.exe (based on bsdtar) supports the same -j flag since Insider Build 17063 in 2018, so no additional software is required on any of the three major platforms just to strip bzip2 compression back off.
Enterprise backup software that targets tape libraries, along with deduplicating backup tools like Borg, restic, and Bacula, generally documents this exact recommendation in their own setup guides: feed the tool (or the tape drive) uncompressed data, and let the destination handle compression at whichever stage actually benefits from it, rather than compressing twice or compressing in a way that defeats a later, more effective compression stage.
A related but distinct case involves network transfers over a link that already applies its own compression, such as an SSH connection using its -C compression option. Sending a bzip2-compressed TBZ over that link wastes CPU time on both ends compressing data that's already compressed, without shrinking the actual bytes transferred any further, so stripping the bzip2 layer first and letting the transport-level compression do the work once is the more efficient order of operations.
Real Reasons People Report Needing an Uncompressed Tar Archive
A recurring pattern on backup and sysadmin forums involves someone noticing their LTO tape usage is worse than expected after switching to pre-compressed archives, and 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 in the worst cases actual usable tape capacity comes out slightly lower than if the original uncompressed data had simply been written directly.
A second documented complaint involves deduplication ratios collapsing after someone starts feeding a tool like restic or Borg pre-compressed TBZ archives instead of raw files or plain tar streams — support documentation for these tools consistently explains that compression scrambles the very 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 afterward, 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 without paying the decompression and recompression cost bzip2 requires each time — some workflows decompress a frequently-accessed TBZ 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. This trade only makes sense when disk space is cheap relative to CPU time, which is increasingly common on modern storage but wasn't always the case on the older Unix systems where compress and bzip2 first became standard.
TBZ's Compressed Stream Against a Plain Uncompressed Tar
| Feature | TBZ (compressed) | Plain TAR (uncompressed) |
|---|---|---|
| File size | Smaller, depends on content | Larger, matches original data size |
| Good for LTO tape hardware compression | No, defeats the drive's own compressor | Yes, lets the drive compress effectively |
| Good for deduplicating backup tools | No, breaks chunk matching | Yes, preserves byte-level similarity |
| Read/access speed | Slower, needs decompression first | Faster, direct access |
| Built-in error detection | Per-block CRC via bzip2 | None built in |
| Conversion complexity | N/A | Simple decompression, no repacking |
Common Questions About Converting TBZ Back to Plain TAR
Why would I want to remove compression instead of keeping it?
Several real workflows benefit from it: LTO tape drives with built-in hardware compression work better on uncompressed input, and deduplicating backup tools like Borg and restic need uncompressed data to detect repeated chunks across backups.
Does decompressing a TBZ to TAR change any of the files inside?
No. This conversion only reverses bzip2's compression step; the underlying 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.
Will the resulting TAR file always be much larger than the TBZ?
Usually yes, since removing bzip2's compression restores the data to its original, uncompressed size, which is typically several times larger depending on how compressible the original content was.
Can I decompress a TBZ without any extra software?
On Linux and macOS, yes — tar's built-in bzip2 support handles it directly. On Windows 10 (build 17063 and later), the built-in tar.exe supports the same decompression from the command line.
Is decompressing a TBZ to TAR slower or faster than compressing it originally was?
Faster, generally. 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.