Keeping old tapes readable during a migration.

Suppose an archive changes software before replacing a tape library that still has useful life. The existing cartridges were written by the old application and the new ones use the new format. The drives can read both. But each application also moves cartridges, loads drives, positions tape, reserves devices, and keeps its own record of what is mounted where, and two applications cannot safely do that to the same hardware at once.

The usual answer is to split the library into logical partitions with drives dedicated to each application. That prevents collisions, but neither side can borrow an idle drive from the other. If the new system can read the old format itself, the drives can stay in one pool. This helps in that particular arrangement. Most migrations will run old and new on separate hardware, and then the reader simply removes the dependency on the old software.

The example depends on media compatibility. IBM documents, for instance, that an LTO-9 drive can read and write both LTO-8 and LTO-9 cartridges; other combinations differ. IBM also states that a drive assigned to one logical library cannot be shared with another, and HPE's MSL3040 guide assigns at least one drive to each partition. A format reader changes none of these hardware rules.

Remanence's SCSI and library layers know about drives, slots, filemarks, tape records, and position. They do not know what archive format is in those records. Format-specific code lives above that line, and a reader for another format plugs in there. It can probe a source to identify the format, say what it is able to do, and expose the files it finds through one common reader interface.

The interface is read-only. It does not define a way to write another vendor's format. And although "plug-in" is a fair description, readers are Rust modules compiled in when a binary is built. Remanence does not load code at run time.

probe, scan, and stream_all are the operations in the public Rust interface. Damage reporting is part of scan and stream rather than a separate operation. A reader may support indexed single-file reads; the one we use does not. The present command line also requires the operator to name the format and the source.

Much of our existing tape archive was written by a proprietary application we no longer run. We had the tapes but no supported version of the software that could recover them on the systems we use now. We reverse-engineered the on-tape format from the evidence left on the tapes and wrote a read-only reader. An open specification would have spared us most of that work, which is one reason the REM formats are published.

A reader solves the tape side. The application above Remanence can import the old catalog so that legacy and native copies appear in one search. When someone asks for a file, that application picks the copy and asks Remanence to use the matching reader. The person asking does not need to know which program wrote the tape.

The catalog, the database, and the search interface belong to that application, not to Remanence. If the old software still has a dependable API, the application could send legacy restores there instead; a direct reader is useful when that connection is unavailable, or when the archive should no longer depend on the old software. An imported catalog says what should be on a tape. It does not prove the tape is readable.

Stock Remanence ships with no legacy readers. They live in the separate Remanence adaptors project, which builds Remanence with the chosen readers linked in. The tools still require the operator to name the format and the source; automatic detection and shared-drive scheduling are not implemented.

A reader cannot overcome a drive or cartridge mismatch, and it cannot supply a missing encryption key. A reverse-engineered reader may also meet a variant of the format it has never seen. Restored and migrated files still need to be checked before old tapes are retired.

Inspect the reader interface → ·  See the adaptors → ·  Read the command reference →

The reader we used for our own migration handles the uncompressed BRU and BRU-PE variants we have tested. It is migration tooling, not part of Remanence core. The archives were written by software from TOLIS Group, which ceased operations and support in 2020; OWC later acquired the product technology and customer base. See the contemporary notice and the acquisition announcement.