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 how deeply you want to test.
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.
Remanence is the Rust reference implementation for REM-OBJECT, REM-PARITY, and REM-ENCRYPT. 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.
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 →
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.
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.
In the current production use case, Remanence operates alongside a second independent archive system rather than replacing every existing copy. New evaluators should follow a similarly conservative approach: test the design while retaining an independently readable established copy.
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.
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.