Professional LTO tape backup in Rust, talking raw SCSI to the drive on three operating systems — and built on the principle that the tape, not the database, is the truth.
This is an architecture study of a project in progress, not a shipped product. The workspace, the CI and the design are done; the engine does not yet write a tape. I am publishing it because the design decisions are the interesting part and they are already made — but nobody should read this page and expect a demo.
Broadcasters, post-production houses, hospitals and engineering firms archive to LTO tape, because it is the only medium where storing a petabyte for a decade is affordable and where the archive is not one ransomware event away from gone. The software that drives those tapes — Yoyotta, Retrospect, Acronis — is expensive, and much of it leans on vendor drivers that make installation an act of faith.
Backup Engine is my attempt at that product: LTFS and TAR, tape cataloguing, partial restore, checksum verification and the drive's own AES-256 hardware encryption, with an interface a working operator can use without a manual.
The application never touches SAS, Thunderbolt or fibre. Those are transport layers the HBA and the operating system already solved. Once the drive appears to the system, the engine sends SCSI command blocks to it through whatever pass-through each OS provides — and those three mechanisms have nothing in common.
unsafe.Concentrating the risk is the whole point. In a memory-safe language the interesting question is not "is this safe" but "where is the part that isn't, and how small can I make it". Here the answer is one crate with a clear contract: send a command descriptor block, get sense data back. Everything else is ordinary safe Rust that can be tested on a laptop with no tape drive attached.
The same decision has a commercial consequence. Not depending on IBM's proprietary drivers means one signed installer per operating system with nothing to download afterwards. The vendor drivers are used when present and never bundled — redistributing them requires an agreement I do not have.
The catalog is a SQLite database mapping every file to its tape, partition, block position, checksum and timestamps. It is what makes partial restore fast: instead of streaming an entire cartridge, the job issues a LOCATE and lands on the file.
But it is deliberately not authoritative. A dedicated job scans an existing tape — reading the LTFS index, or walking TAR headers — and rebuilds the catalog from scratch, shallow for metadata only or deep to re-read the data and recompute checksums. Two things follow from that, and both matter to somebody who has to trust this software with an archive:
I learned this the expensive way on a different project: a server's backups were written inside the same virtual machine they were protecting, the VM was rolled back, and the backups went with it. The lesson generalises past that incident — an index that shares a failure domain with nothing, and can be rebuilt from the medium itself, is the only arrangement that survives the failure you did not plan for.
There are two editions. The Free one limits how much you can write. Neither limits reading, restoring, or verifying — not by volume, not by expiry, not ever.
This is a deliberate commercial constraint, and I would argue it in any room. Backup software is bought for the worst day of somebody's year. A product that holds a customer's own archive hostage behind a lapsed licence, at the exact moment they need it, has failed at the only thing it was for. Limiting writes is a business model; limiting restores is a hostage situation.
Licensing itself is offline and signed with Ed25519 — no phone-home, because the machine attached to the tape library in a broadcast facility is frequently a machine with no route to the internet, and that is a correct security posture rather than a problem to be worked around.
An LTO drive and a library are expensive, so development runs against mhvtl, a virtual tape emulator on Linux. The engine sends real SCSI commands to an emulated device, which means the pass-through layer, positioning, filemarks and spanning logic can all be exercised before any hardware exists.
What the emulator cannot tell me is how the real thing fails: media errors, a drive asking to be cleaned, WORM cartridges, a tape filling mid-write and triggering a span. Those paths are designed and will need a real library to be trusted. Saying so now is cheaper than discovering it in front of a customer.
The implementation is heavily AI-assisted. What is mine is the shape of the thing: concentrating all unsafe code behind one trait, deciding that the catalog is derived rather than authoritative, choosing to talk SCSI directly instead of depending on vendor drivers, and setting the rule that restore is never licensed. Those are the decisions the project will live or die by, and none of them came from a model.
The idea. The rules the build has to follow — programming and commit discipline, the test harness, the security model, and how the product is organised for market. Choosing the technology. Coordination, and the instructions that direct the work. Testing against real signal, real audio and real hardware, and the fine tuning until it behaves. Deciding what ships and what gets rolled back.
The implementation itself — the code, the platform plumbing, the first drafts of documentation.
It is worth being concrete about the risk here, because this is a project where getting it wrong destroys someone's archive. A model will produce plausible SCSI code that compiles and is wrong in ways that only appear against real hardware. That is exactly why the unsafe surface is one small crate with an explicit contract instead of FFI scattered through the codebase — the architecture is designed so that the part I cannot fully verify by reading is as small as I can make it.
I do not write every line. I do read every line I integrate, and this project does not ship to anyone until it has been verified against a real tape library. Where I am still working: measuring instead of estimating, and closing the gap between what I can review and what I could write unaided.
Broadcast and live-event engineer, São Paulo, Brazil. Partner at VENG (Vídeo Engenharia) — professional AV, broadcast technology and technical training. I build systems for environments where the media is the asset: live video, archive, remote operations, and AI applied to production workflows.
Archive, storage and workflow architecture for broadcast and post-production.
Delivered through VENG — archive systems, live captioning, remote support platforms.
Applied AI and media engineering for AV professionals, in Portuguese, English or Spanish.
Remote technical collaboration with teams outside Brazil — contract projects, partnerships and joint work across time zones.
joao@video.eng.br · +55 11 99602-1111