Test the design before trusting it with an archive.
Everything can be exercised without buying tape hardware. Start with the published test vectors and a virtual tape library, and move to physical cartridges only once the software and the workflow are understood. Test against material you still hold an independent copy of. Where the software stands today is set out plainly in Current maturity, further down this page.
Choose a starting level
Build Remanence
Remanence is the Rust reference implementation of REM-OBJECT, REM-PARITY, and REM-ENCRYPT, together with the tape stack around them: library robotics and drive control down to the SCSI layer, mount management, drive-health monitoring, and the operational tooling a deployment needs. It talks to the hardware over raw SCSI rather than through the kernel's tape driver, a choice explained through two operational case studies in the project documentation.
Clone the repository, build it with Cargo, and follow the README. The same repository contains the specifications, the test-vector archive, and the verification tools. Tagged releases carry the pinned test-vector archive as a direct download, so an evaluation can start from a fixed, citable version rather than the moving tip.
$ git clone https://github.com/archivetechie/remanence
Latest release → · Quickstart guide → · Command reference → · Troubleshooting →
Verify the test vectors
First confirm that you have the exact published test material, by comparing the checksum of the test-vector archive with the value printed in the specifications:
$ sha256sum specs/publication/remanence-test-vectors.tar 77be73e780e9ff2c265c8357b6ba684b4c69800213820ae1331850f742b1d83d ...
Then run the two verification targets. The first checks the published archive with tools kept separate from the main implementation. The second checks the candidate vectors for the REM-PARITY generation-2 layout that the development branch writes, which are review material rather than a published artifact:
$ make verify-publication-test-vectors $ make verify-in-progress-parity-test-vectors
Passing the first target does not mean the current reader accepts the published parity tape images; it does not, because they describe the earlier layout. The two targets together make that boundary visible and reproducible. The split is explained under the specifications.
Physical testing
A physical deployment needs a Linux server, a compatible SAS host bus adapter (the card that connects the drive to the server), and an LTO drive or library. Previous-generation equipment is inexpensive on the secondary market, but choosing it, keeping it running, and handling media still call for tape experience. A virtual tape library is the lower-risk place to start, and everything on this page except the last level can be done there.
The implementation was developed against a Quadstor virtual tape library and tested on an HPE MSL3040 library with LTO-9 drives. On that hardware it sustained write rates of about 285 MB/s to a single drive and around 640 MB/s across two, with verified reads at about 210 MB/s.
Current maturity
The software is at version 0.1.0 and is alpha. It was published as v1.0.0 in July 2026 and renumbered downward in August 2026, because a 1.0 says that an implementation has been exercised enough to be trusted with irreplaceable material, and this one has not been. The code did not get worse; the label was wrong and was corrected in public. The format specifications are versioned separately and stay at 1.0.
The implementation has run on one virtual library family and one physical library with one drive generation. It is not in production anywhere, including in the archive it was built for. The practice it formalizes, tar with a catalog appended to each tape, has years of production history behind it; the implementation does not, and should be treated as young. The parts that put bytes on tape and get them back are the most mature. The control surfaces above them, the API and the authorization model, are still moving, and the command line may still change.
The specifications are review drafts until 31 July 2027, and breaking changes are allowed until then. Tapes written from a pre-freeze draft carry no guarantee that later software will read them, so keep the source of every evaluation tape. Do not make Remanence the only copy of anything you cannot afford to lose. The project's own status page lists what works and what does not, in detail, and errs toward naming limitations.
Keep verifying
A write that completed without error does not show that the tape can be read back years later. Set up a routine that restores real material from physical cartridges, recalculates its checksums, and records the result, and start it during evaluation rather than after years of media have accumulated. Remanence makes the comparison mechanical, because every archived file carries its expected SHA-256.
Help test the work
Open a GitHub issue for reproducible bugs, specification ambiguities, compatibility findings, or test results. If you build a reader from the specification text and it disagrees with the vectors, that is the most useful report the project can receive. Check the known open items first. Use email for institutional evaluation, operational questions, or interest in testing on other hardware.