Every few years someone declares tape dead. Earlier this year it was DOGE staffers reportedly mocking the Library of Congress for still using tape. Before that it was the cloud. Before that it was cheap spinning disk. Tape has been "dying" for roughly thirty years now.
It isn't dying. The numbers say the opposite, and the reason most people miss this is that they're still picturing tape the way it worked in 2005: write a reel, label it by hand, put it on a shelf, forget what's on it. That workflow is dying. The medium underneath it is having its best decade ever — but only if you stop treating it like a glorified USB stick and start treating it like what it actually is: a storage tier that needs the same indexing, metadata, and search infrastructure you'd expect from any modern filesystem.
This post covers three things: why the "tape is dead" narrative is wrong by the numbers, why the common ways people do use tape (pure backup target, raw LTFS) leave most of its value on the table, and what a real solution looks like, a global namespace, a persistent catalog, and (looking forward a bit) AI generated descriptive metadata that makes a multi-petabyte cold archive as searchable as your local filesystem.
The numbers don't lie
In 2024, the LTO Program — the joint body run by HPE, IBM, and Quantum that governs the Linear Tape-Open standard — shipped a record 176.5 exabytes of compressed tape capacity. That's the fourth consecutive year of growth, and a 15.4% jump over 2023.
A couple of things stand out in that chart. First, the 2020 dip is the pandemic — new data center buildouts paused and tape shipments fell 8% before snapping back with 40% growth in 2021. Second, the climb since then hasn't slowed down at all. The LTO Program's own attribution is blunt about why: enterprises adopting AI/ML workloads are generating enormous volumes of unstructured data, and tape is where a meaningful chunk of it ends up once it goes cold.
To put 176.5 exabytes in perspective against the rest of the storage industry: in early 2025 alone, hard drive vendors shipped roughly 361 exabytes in a single quarter, putting annualized HDD shipments somewhere north of 1,400 exabytes. So tape isn't winning a head-to-head capacity war against disk — it was never going to, and that's not the point. Tape occupies a specific niche (cold, durable, offline, cheap) inside a much larger storage market that IDC pegs as growing toward hundreds of zettabytes of new data created annually by the back half of this decade. The interesting story isn't "tape vs. disk." It's that the cold tier of that exploding datasphere is, by a wide margin, choosing tape — and the market backs that up too: analysts size the global tape storage market at somewhere around $5–6 billion in 2026, growing at a 7–8% CAGR through the early 2030s.
Why now, specifically
A few forces are converging at once:
- HDD prices have gone the wrong way. AI demand for nearline drives has pushed enterprise HDD prices up — some consumer-facing drives are reportedly up an average of 46% since last September. For the first time in a decade, the "just buy more disk" answer is getting noticeably more expensive.
- Ransomware made the air gap matter again. Roughly 90% of organizations worldwide have experienced a ransomware attack, by IDC's count, and a tape sitting in a drawer with no network or USB path is fundamentally un-attackable in a way that a "cold" but still-attached HDD is not.
- AI/ML training and inference data is enormous and mostly cold. You don't need fast random access to last year's training corpus. You need it to exist cheaply, durably, and verifiably for a long time — which is exactly tape's value proposition.
None of this is hypothetical vendor spin. It's the LTO Program's own technology providers and IDC analysts saying it on the record, and the shipment numbers back it up year over year.
The actual cost case, including the part everyone leaves out
Here's a comparison most articles on this topic don't make: tape vs. HDD vs. SSD, and tape vs. cloud cold storage — because that last one is where the real surprise is.
At 2026 retail pricing, an 18TB-native LTO-9 cartridge works out to roughly $0.005/GB. A 20TB enterprise HDD lands around $0.030/GB. A 4TB NAS SSD is closer to $0.075/GB. All three of those are one-time costs — you pay once and the bytes are yours.
Cloud cold storage looks irresistibly cheap by comparison on a per-month basis. AWS S3 Glacier Deep Archive, for instance, is published at $0.00099/GB-month — a fraction of a cent. But "per month" is the catch: that's a recurring charge for as long as the data exists, not a purchase.
Run the math out and the crossover points are almost comically close. Cloud cold storage costs more, cumulatively, than an LTO-9 cartridge's entire one-time purchase price after about five months of retention. It passes the cost of an equivalent amount of enterprise HDD storage at around two and a half years. And this is before counting retrieval fees, request fees, or egress — Glacier Deep Archive in particular charges per-GB to get your own data back out, on top of a mandatory 180-day minimum storage commitment. For data you're keeping for 5, 10, or 30 years (LTO media carries a 30-year archival rating), the cloud's "low monthly price" framing quietly becomes the most expensive option on the table.
This isn't an argument against cloud storage in general — it's excellent for hot and warm data with unpredictable access patterns. It's specifically an argument that "cold archive" and "cloud" are not synonyms, and that the economics tilt hard toward owned, offline media the longer your retention window gets.
Where most tape setups go wrong
So tape is cheap, durable, and having a renaissance. Given that, why does it still have a reputation as something only enterprise IT departments bother with?
Because the tooling around it never grew up. Walk into most home labs or small shops running tape and you'll find a workflow that looks like this: write data to a cartridge, label it by hand with a Sharpie, put it on a shelf. Need a file back? Find the right tape (maybe), restore the entire archive set, then go looking for your file inside it.
Two specific approaches dominate, and both have a structural weakness that doesn't show up until you're a year or two into using them.
Tape as a pure backup target. This is the "3-2-1 rule" use case — tape as your offsite, air-gapped third copy. It's a legitimate and important use of tape, but it's also where tape's reputation problem comes from: a backup set is something you restore wholesale, in a disaster, not something you browse day to day. If tape is only ever your backup target, you've correctly captured its durability and its air-gap security, but you've left its cost-per-GB advantage completely untapped for anything except disaster recovery. You're paying for the cheapest storage medium that exists and using it like an expensive one you're afraid to touch.
LTFS as a primary archive. LTFS (Linear Tape File System) was genuinely useful when it landed — for the first time, you could mount a tape cartridge and have it behave like a USB drive, no proprietary restore software required. For an interchange format between studios or broadcast houses, it's still great. But LTFS was designed for a "write a reel, hand it to someone, they mount it" workflow. It is a transport format, not a living archive, and the cracks show fast once you try to use it as your primary cold tier:
- There's no catalog. You cannot search the contents of an ejected tape without physically mounting it first.
- Every cartridge is its own isolated volume. A 50-tape archive is fifty disconnected filesystems, not one coherent library.
- Finding a file means knowing — or guessing — which physical cartridge it lives on.
- There's no demand-loading. Applications can't transparently request a file; a human has to manually restore it first.
- Metadata lives only on the tape itself. Lose or damage the cartridge, and you lose the index along with the data.
Both patterns share the same root cause: there's no persistent, off-media index that knows what's on your tapes. Without that, tape stays stuck as either a write-only insurance policy or a manual, file-by-file restore chore — and most people understandably give up and just buy more disk.
The fix: a global namespace and a catalog
The fix looks less like "better tape software" and more like "treat your tape library the way a search engine treats the web" — index everything centrally, keep the index separate from the thing it describes, and let the physical location of any given object become an implementation detail.
Concretely, that means two things working together: a global namespace (your entire collection of tapes presents as one coherent filesystem, not fifty islands) and a catalog (a persistent, queryable index of every object you've ever archived, regardless of whether the media holding it is currently online).
In a system like this, every archive operation writes a row into a small database — something like:
CREATE TABLE catalog (
id INTEGER PRIMARY KEY,
file_path TEXT NOT NULL,
version INTEGER NOT NULL,
volume_uuid TEXT NOT NULL, -- which cartridge, identified by UUID, not /dev/nst0
volume_offset INTEGER NOT NULL, -- exact byte position on that volume
payload_size INTEGER NOT NULL,
blake3_hash TEXT NOT NULL,
archived_at DATETIME DEFAULT CURRENT_TIMESTAMP,
custom_metadata TEXT -- more on this below
);
A few design choices here matter more than they look like they do:
Identify volumes by UUID, not device path. /dev/nst0 changes when you move a drive to a different port. A UUID burned into the volume's header at format time doesn't. This is what lets a catalog survive hardware shuffling without breaking every restore path.
Version instead of overwrite. Tape is sequential and append-only — you literally cannot punch a hole in the middle of a cartridge to update a file in place. Treat that as a feature: every re-archive of a file becomes a new row with an incremented version, which gives you point-in-time rollback essentially for free.
Make the volumes self-describing, independent of the catalog. If every object is preceded by a small header containing its own path, hash, and metadata, the catalog becomes an index, not a dependency. Lose the database — drive failure, rm -rf, whatever — and you can rebuild it by scanning the raw tape for header magic bytes. This is the property that makes the difference between "we lost our archive" and "we lost an afternoon re-indexing it."
With that in place, search stops requiring a mounted tape drive at all:
$ archive find "project_alpha_final.mov"
Found 1 result:
/archive/video/2024/project_alpha/project_alpha_final.mov
Volume: 83ad72b7 | Size: 47.2 GB | Written: 2024-11-14
Status: OFFLINE — cartridge not currently mounted
You get a full answer instantly, with zero tape movement, even though the cartridge is sitting on a shelf in a box somewhere. That's the part LTFS structurally cannot do — its index lives only on the medium it's describing.
The other half of "global namespace" is transparent access: instead of a restore being a separate job a human has to remember to run, the filesystem layer can intercept an open() call (on Linux, fanotify is the relevant kernel interface) for a file that's currently offline, pause the requesting process, and prompt for the right cartridge by UUID. The application doesn't know a tape was ever involved — from its point of view, the file was just slow to open. This is conceptually identical to enterprise Hierarchical Storage Management (HSM), minus the enterprise price tag and the dedicated hardware requirement.
Taking it further: AI-generated descriptions as searchable metadata
A catalog that indexes paths, sizes, hashes, and timestamps solves "where is this file." It doesn't solve "what's actually in this file" — and for a multi-petabyte cold archive accumulated over years, that second question is often the one you actually have.
POSIX extended attributes (xattrs) are an underused piece of infrastructure here. Linux, macOS, and most Unix filesystems let you attach arbitrary key-value metadata directly to a file's inode, independent of its contents — user.camera.operator, user.project.codename, whatever your workflow needs. If your archiving pipeline already scrapes xattrs at write time (which it should, since editorial and scientific tools frequently rely on them), then attaching one more attribute costs nothing architecturally:
# Conceptual sketch — generate a description, attach it as an xattr,
# let the existing archive pipeline pick it up like any other tag.
description = vision_model.describe(video_path) # e.g. a multimodal model
xattr.set(video_path, "user.ai.description", description.encode())
xattr.set(video_path, "user.ai.tags", ",".join(description.tags).encode())
That's it — no new pipeline, no separate database to keep in sync. Whatever process already pulls xattrs into the catalog's custom_metadata column at archive time picks up the AI-generated description the same way it picks up a manually-set tag. A vision-language model can describe what's in a video frame; an ASR model can transcribe spoken audio into the same field; an embedding model can index the description for semantic search instead of just exact-match. None of this requires touching the underlying archive format — it's additive metadata riding along on a mechanism the system already needs for ordinary tags.
The payoff is a search experience that goes well beyond filenames:
$ archive search --semantic "drone footage of a mountain, no people visible"
Found 3 results across 2 volumes (0 tapes mounted):
/archive/footage/2023/alps_b-roll_07.mov (Volume a1f9, OFFLINE)
/archive/footage/2024/denali_aerial_02.mov (Volume 83ad, OFFLINE)
/archive/footage/2024/denali_aerial_04.mov (Volume 83ad, OFFLINE)
For media production, scientific archives, surveillance footage, or just a chaotic personal NAS, that's the difference between "I know it's in here somewhere" and actually finding it. And critically, the search itself never touches a tape drive — it's a query against the hot, SSD-backed catalog database. The tape only spins up once you actually want the bytes.
Putting it together
None of these pieces are individually exotic — xattrs have existed since the early 2000s, SQLite is older than most of us, and fanotify has been in the kernel for over a decade. What changes the picture is using them together, deliberately, instead of treating tape as an isolated dumb-storage device that occasionally gets a file copied onto it.
The pattern is: write data to the cheapest durable medium that exists, index it centrally and redundantly (catalog plus self-describing volumes), make retrieval transparent instead of a manual restore job, and use cheap, off-the-shelf AI to make the contents — not just the filenames — searchable. Tape's economics have always been good. What's been missing is software that takes that seriously enough to build real infrastructure around it instead of a Sharpie and a shelf.
You can find most of these features in an open-source, single-binary archive system in Rust called HuskHoard — and most of the concrete examples above (the catalog schema, the demand-load mechanism, the xattr capture pipeline) come directly out of that project. It's AGPL v3. Other catalogs include open metadata and Amundsen Tape is still relevant in 2026 if we apply the tools we have available in 2026 not those that were used in 2006.
Sources: LTO Program Technology Provider Companies (HPE, IBM, Quantum) annual media shipment reports, 2020–2025; IDC Global DataSphere research; AWS S3 published pricing (verified 2026); Tom's Hardware, Blocks & Files, and TechTarget reporting on tape and HDD shipment trends. Cost figures reflect 2026 retail media pricing and exclude drive amortization, power, and (for cloud) retrieval/egress fees.
Top comments (0)