Remanence is a set of open specifications and a reference implementation for packaging, protecting, and recovering large digital collections on LTO tape. The goal is simple: the archive should remain understandable and recoverable even if the original catalog, application, vendor, or technical team is no longer available.
Storage is not the same as preservation. An archive may survive physically and still become difficult to recover.
The original software may disappear. The catalog may be lost. The vendor may stop supporting the product. The people who built the system may no longer be available.
A long-term archive should be designed for those conditions from the beginning — while still allowing people to retrieve useful material without reading an entire cartridge.
Remanence is for people responsible for digital material that must remain recoverable for decades. It may be relevant if:
You do not need to accept the design on trust. The specifications, implementation, test vectors, and recovery procedures are published so the claims can be examined directly.
Three layers, three responsibilities. Each solves a separate problem, so archive identity, tape recovery, and encryption are not locked inside one application.
Optional off-site protection: REM-ENCRYPT seals sensitive copies stored outside your control, without changing the durable object underneath.
Remanence is deliberately not a hierarchical storage manager. It owns one responsibility — writing archives to tape and reading them back, verifiably, decades on — and exposes everything it does through a complete API and command line. The rest belongs to a larger system: the catalog people search, the policies that decide what is copied where, the scheduling, and the other media a real archive spans.
This is the opposite of the usual product shape. Archive software is typically bought as one application that does everything — and therefore owns everything, which is exactly the dependency this project exists to avoid. A component with an open format below it and open interfaces above it can be wrapped, replaced, or outlived without touching the tapes.
In our own production archive, Remanence runs as the tape layer beneath an orchestration system that manages copies across media against a central catalog and policy database. That layer is where an institution's own rules live, and it is deliberately left to the operator — ours remains internal.
A self-describing archive package. REM-OBJECT packages files and their preservation
information into an openly documented archive object. A standard pax-aware
tar program can extract the files without the original archive
application.
Each file carries a SHA-256 checksum, so restored data can be checked against what was originally written. The object also records where each file lies, allowing a reader to retrieve part of a large file without scanning the entire object.
Why it matters: the archive remains useful even if the original software or operational database is unavailable. Read the REM-OBJECT details →
Recovery information for damaged tape. REM-PARITY arranges archive objects and separate recovery data across the cartridge. If part of the tape becomes unreadable, the recovery data can be used to reconstruct the damaged region.
Bootstrap records stored on the cartridge describe its layout, so the contents can be mapped without depending on the central catalog.
Why it matters: losing a database or a damaged tape region does not automatically mean losing the archive. Read the REM-PARITY details →
Optional protection for copies outside your control. Encryption is not automatically an advantage for long-term preservation: a lost key can make a perfectly intact archive permanently unreadable.
REM-ENCRYPT is intended primarily for sensitive copies stored off-site, or where contractual requirements make encryption necessary. It preserves the object structure needed for partial restoration while keeping encryption separate from the core archive format.
Why it matters: sensitive copies can be protected without making encryption mandatory for every archived object. Read the REM-ENCRYPT details →
The format is specified, not trapped inside one program. The specifications are openly published; the reference implementation, test vectors, and independent reader are available for inspection and testing.
A future implementation can be written from the specification even if the current software, supplier, or institution is no longer available. The design does not ask the archive to depend forever on one vendor, one executable, or one development team.
The project publishes evidence that can be checked independently:
The objective is not to trust the author. It is to make the technical claims reproducible.
The format currently operates as one of two independent systems in a working production archive. It has been developed against a Quadstor virtual tape library and tested on an HPE MSL3040 library with LTO-9 drives.
That is meaningful operational evidence, but it remains a narrow hardware base for a format intended to survive for decades. More independent implementations, hardware environments, and institutional trials are still needed.
Early users should retain an independent archive copy and regularly restore and verify real material from physical cartridges. How and why it was built is on the Why this exists page.
The first leads to conceptual understanding. The second leads to technical proof. The third leads to implementation.