Test the architecture before trusting it with an archive.
You can begin with a virtual tape library, reproduce the published test vectors, and confirm that independent readers agree — before using physical cartridges or irreplaceable material.
Choose a starting level
Choose how deeply you want to test.
Physical testing requirements
A physical deployment requires a Linux server, a compatible SAS host bus adapter, and an LTO drive or library. Previous-generation equipment may reduce cost, but hardware selection, compatibility, maintenance, and media handling still require tape experience.
A virtual tape library provides the lower-risk starting point for evaluating the format and software before working with real cartridges. The format itself was developed against a Quadstor virtual library and tested on a physical HPE MSL3040 library with LTO-9 drives. On that hardware the implementation sustained measured write rates of about 285 MB/s to a single drive and around 640 MB/s aggregate across two, with verified reads at about 200 MiB/s.
Build Remanence
Remanence is the Rust reference implementation for REM-OBJECT, REM-PARITY, and REM-ENCRYPT — and a working tape stack around them: library robotics and drive control down to the SCSI layer, mount management, drive-health monitoring, and the operational tooling a real deployment needs. It drives the hardware over raw SCSI rather than the kernel's tape driver — a deliberate choice, explained through two operational case studies in the project documentation. Clone the repository, build it with Cargo, and follow the versioned instructions in the README. The same repository contains the specifications, the test-vector archive, and the verification tools.
$ git clone https://github.com/archivetechie/remanence
Tagged releases are published as well, and the latest release carries the pinned test-vector archive as a direct download — so an evaluation can start from a fixed, citable version rather than the moving tip.
First commands
The repository documentation walks through the working vocabulary: writing a first archive object, restoring it, and verifying what came back, with a full command reference behind it.
Quickstart guide → · Command reference → · Troubleshooting →
Verify before trusting
First, confirm that you have the exact published test material. Calculate the SHA-256 checksum of the downloaded test-vector archive and compare it with the value printed in the specification:
$ sha256sum specs/publication/remanence-test-vectors.tar b9be8760fd4a85a922e5fa8eaf86840eec0719a5407030b9f6a35f0606ea79bd ...
Next, run both the Rust implementation and the independent Python reader. Both should reproduce every valid example and reject each malformed example with the required error.
Agreement does not prove that every future archive operation is safe, but it confirms that the two implementations interpret the published format consistently. These checks are cheap to run and are the right first step for any institution evaluating the software.
Current maturity
The project is young and has been published early so that others can inspect and test it. The on-tape structures and recovery behavior are the parts intended to remain durable; command-line interfaces and operational workflows may continue to change.
Remanence is not yet in production deployment, here or elsewhere. The practice it formalises — tar with an appended catalog — has years of production history behind it; the implementation itself is young and should be treated as young. Evaluators should test the design while retaining an independently readable, established copy of anything irreplaceable.
Ongoing verification
An archive is not verified because the write completed. Establish a continuing routine that restores real material from physical cartridges, recalculates its checksums, and records the result.
Remanence makes this comparison mechanical, because every archived file carries its expected SHA-256 value. The routine should begin during evaluation — not after years of media have accumulated.
Help test the work
Open a GitHub issue for reproducible bugs, specification ambiguities, compatibility findings, or test results. Use email for institutional evaluation, operational questions, or interest in testing on additional hardware.