On-Tape Format (LTFS and JSON Sidecar)
Updated July 17, 2026
On-Tape Format (LTFS and JSON Sidecar)
An archive tool asks you to trust it for decades. Hiberden's answer to that is open formats: everything it writes can be read, verified, and restored with standard tools, without Hiberden installed anywhere. This article describes exactly what lands on your media.
One standard TAR
Every archive is a single standard TAR file. The layout is the same on every destination: a file on local disk or NAS, an object in your cloud bucket, or a file on an LTFS tape volume. The TAR headers carry the real file paths and real modification times. There is no proprietary container and no encryption layer you need Hiberden to unwind: any tool that opens TAR opens your archive.
On tape specifically, Hiberden writes through LTFS, the open Linear Tape File System. The mounted cartridge behaves like a filesystem, and the archive sits on it as an ordinary file. Any LTFS-capable system can mount the cartridge and copy the TAR off, no Hiberden involved. See Tape (LTO-9 / LTFS) for how the drive side works.
The JSON sidecar
Next to every TAR sits a plain JSON sidecar named <name>.tar.hiberden.json. It records:
- A spec version, so a reader knows which revision of the format it is looking at.
- The archive's SHA-256. This is the mandatory root of trust: every verification in Hiberden re-reads the copy and compares against this hash.
- The archive's size and when it was written.
- A per-file manifest: for each file, an ordinal id, its size, its byte offset inside the TAR, and its own SHA-256.
- BLAKE3 second hashes, on by default. This is one switch for the whole archive: when it is on, the sidecar carries an archive-level BLAKE3 and a BLAKE3 for every entry in the per-file manifest, always together. A sidecar never has one without the other. SHA-256 remains the mandatory root of trust either way.
- Genuinely optional extras: an ASC MHL validation record, and a detached Ed25519 signature that gives per-install tamper evidence, verifiable offline.
A copy of the manifest also rides inside the TAR as its final member, so the archive carries its own manifest even if the sidecar file is lost.
One deliberate choice: the sidecar contains no file names and no paths. Names stay inside the TAR, where the data is. The manifest identifies files by ordinal and byte offset, which means a sidecar can be copied, indexed, or handed to someone without revealing your directory structure.
Those recorded byte offsets and per-file hashes are also what make restoring a single file possible from disk, NAS, and cloud: Hiberden reads just the recorded byte range and checks it against the file's own hash.
Spanned tape sets
An archive too big for one cartridge is split across several. Each cartridge then holds a part file plus its own per-cartridge sidecar, recording the segment's offset, length, and hash, the cartridge's volume label, and its position in the set. One chain manifest describes the whole set: how many cartridges, in what order, and the aggregate hash.
The result is that any single cartridge can identify itself and prove its own segment intact, and the chain manifest proves the complete set.
Everything works without Hiberden
The whole point of this design is that no piece of it depends on Hiberden existing:
- LTFS mounts anywhere LTFS runs.
- The TAR opens with standard tools.
- The sidecar is plain JSON you can read in a text editor.
Hiberden also ships a reconstruct path that rebuilds and re-verifies an index from the TARs and sidecars alone, which is useful after moving media to a new machine. But the guarantee does not rest on that feature. If Hiberden ever disappears, your tapes are still your tapes.
This is the same philosophy as Verified 3-2-1 Archiving: protection you can check for yourself, not a status you are asked to take on faith.