Data Archaeology · AI Capability

The Backup Is the API

Format obsolescence just stopped being a death sentence. For forty years, data outlived its software but died with its container — no client, no vendor, no access. Then a model researched a dead format, wrote its driver, and opened the door. Here is what that reprices, and the one discipline that keeps a recovery from becoming a loss.

I kept a Lotus Notes mailbox for the better part of two decades. Twenty-odd years of email, from my time at IBM in the mid-nineties onward, sitting in a single .nsf file — and I could not open it. The client was Java, it was on an old machine, and the software world around it had quietly fallen apart. The data was all in there. It even had full-text search once, if you already knew what you were looking for. But the container had died around the contents, and so, practically speaking, the contents had died too. I deleted it. Not long ago, in a cleanup, I threw twenty years of my own working life away — because under the rules I’d operated by my whole career, it was dead weight.

Then, a few days later, I found out those rules had changed — and I went looking through my backup drives to see what else I’d been wrong about.

The death sentence that held for forty years

Every practitioner who has ever managed data for a living knows the fear, even if they’ve never named it. The preservation field named it: the digital dark age — “a lack of historical information in the digital age … a direct result of outdated file formats, software, or hardware that becomes corrupt, scarce, or inaccessible as technologies evolve.”¹ A decade ago Vint Cerf, one of the fathers of the internet, warned publicly that we were sliding into exactly this — a “forgotten century” lost to “bit rot,” where old files become useless junk because the software that read them is gone.² The canonical line in the discipline, from Jeff Rothenberg, is grimmer and funnier: “digital information lasts forever — or five years, whichever comes first.”³

Notice the precise shape of the problem, because the whole argument turns on it. Preservation people divide the threats into three: hardware failing, media becoming unreadable, and — the deepest one — comprehensibility: “a document with a long-abandoned file type that can’t be interpreted by any modern machine.”⁴ The bits are fine. The disk spins. What’s missing is a program that understands the format. And for proprietary formats, the received wisdom was blunt about how final that is: in such a case, one reference states plainly, “it might be impossible to write appropriate software to read the file.”¹

Read that again, because it is the sentence this whole piece exists to overturn. Impossible to write appropriate software to read the file. That was true — not as a law of physics, but as a law of economics. Writing a parser for an undocumented, proprietary format is a specialist project: weeks of reverse-engineering for a payoff of one old archive nobody was sure was worth reading. Nobody funds that. So the container’s death became the data’s death, and the field’s entire defensive doctrine followed from it — migrate formats forward before they orphan, keep registries of which formats are going extinct,⁵ keep lots of redundant copies so nothing is lost,⁶ and above all don’t miss the migration window, because once you do, it’s gone.

That doctrine was correct. It was correct for forty years. It was correct right up until the premise underneath it — that writing the reader is prohibitively expensive — stopped being true.

Case one: the backup is the API

Some months ago, well before I understood it as anything more than a neat trick, I hit a data bug in a client system I couldn’t get into. What I did have was a Salesforce backup: a pile of zip files, CSV exports of every table in the deployment. So I pointed Claude at it and said, in effect, go into the backups and find the data behind this bug — how often does it occur, what does it look like.

It wrote its own software. It opened the zip files, read the CSVs, worked out the relationships between the tables, and ran its own joins and queries across them — reconstructing a working query layer over a dead export, with no Salesforce login, no API, no connector, nothing but a folder of backup files. It found the problem. And here is the part that turned a debugging convenience into something I now think is categorical: I have been answering client questions out of that little self-built tool ever since. The backup stopped being a backup and became the system of record.

Full data-layer archaeology with zero system access — no credentials, no connector — still producing answers months later. The backup is the API.

At the time I filed it under “clever.” Imagine the day, though. I gave one instruction — go have a look at the backups — and the model manufactured the entire access layer to a system it was locked out of, off nothing but the exhaust the system had left behind. That was months ago, when the models were comparatively stupid. I didn’t see the general principle yet. I needed it to happen a second time, on a harder container, before I’d believe it was a rule and not a fluke.

Case two: manufacturing the reader

So back to the Lotus Notes mailbox — the one I’d deleted. Once I started to suspect the old rules had changed, I went digging through my backup server, and I got lucky: sitting there were some Acronis disk images from old machines. Acronis writes a proprietary format — .tib and later .tibx — that ordinarily only Acronis’s own software will open;⁷ the kind of thing a third-party tool developer looks at and calls “a lot of work against a potentially moving target.” I set a model loose on them with a simple instruction and some scratch space, and it built tooling to crawl inside the images and list what was there. It found not one but several old .nsf files — and, better than the email, a projects archive: everything I’d built and documented across twenty years, in its original wrapping.

Then came the part I keep turning over in my head. Notes stores its data in the .nsf format — a proprietary, non-relational object store that, in practice, only the Notes and Domino software reads.⁸ There is no casual Python connector for it. The format is genuinely hard: people have run multi-year open-source projects just to reverse-engineer enough of it to extract data forensically.⁹ I fully expected this to be a wall.

It wasn’t. The model went out, found what the internet knew about the NSF format, and wrote its own driver in C++ to open it — then used that driver to replicate the mailbox’s contents into a Postgres database. No connector existed, so it manufactured one. It reached into a container whose mainstream moment had passed a decade and a half ago and simply opened it.

That is the moment the rule broke, and it is worth stating at full strength because something categorical happened here, not merely something impressive:

This is not science fiction, and it is not one heroic model on one lucky day. Writing code against an unfamiliar target, iterating until it works, is now something frontier models do at industrial scale: in a year-long study, Google reported an LLM-driven tooling effort that generated 74% of the code changes across dozens of real migrations, cutting migration time roughly in half.¹⁰ And notice why the NSF job succeeded — not because the model recited a spec from memory, but because it ran its driver against the actual file and iterated until the data came out clean. Raw generation alone isn’t enough; the research is clear that models need to test against the real environment and correct themselves,¹¹ which is exactly what opening a container is: write the reader, run it against the bytes, fix what breaks, repeat. Environment-in-the-loop is not a caveat here. It is the mechanism.

Two cases now, on two dead containers, a decade of format apart: the Salesforce export queried by self-written tooling, and the NSF mailbox opened by a self-written driver. In my own work I have a rule for exactly this — two instances pointing at one move is no longer an anecdote, it’s earned promotion to a principle. The principle is the title of this piece. The backup is the API, and by extension so is the disk image, the orphaned mailbox, the dead database, the export from a SaaS tool that shut down. The reader was never something you had to already own. It is now something you make.

Which means every “dead” archive on earth got repriced overnight — and repriced on the axis nobody was watching. We already knew comprehension had gotten cheap; models summarise anything. What just changed is that reach got cheap. The long tail of obscure, undocumented, one-off proprietary formats — the exact formats no vendor ever bothered to write an extractor for — is now openable one archive at a time, for the cost of a prompt and an evening of compute.

The mess is the feature

There was a complication with the Notes files, and it turned out to be the most interesting part. The .nsf copies I recovered weren’t clean or complete. They were partial, differently dated — different backups from different years, some capturing only a short burst of replication before the machine was imaged. My instinct was to apologise for the pile: a messy sprawl of overlapping, half-intact duplicates. Dedup it down to one and move on.

That instinct was wrong, and the reason it’s wrong is a small piece of engineering the old software left lying around for me. Notes gives every document a Universal ID — a UNID — and, crucially, that identifier “is shared by all its replicas,” with each document also carrying its own creation and modification dates.⁸ The identity of a record survives across every copy. Which means merging the partial copies isn’t a fuzzy, AI-judgment-call, best-guess deduplication. It is a deterministic union keyed on the format’s own identity system: same UNID, same record; different UNID, different record; keep the freshest version of each by its own timestamps.

And here is the inversion. Because each backup sampled the mailbox at a different moment, the union across all of them can reconstruct a corpus more complete than any single copy that ever existed at once. A message deleted before backup B was taken still lives in backup A. A folder reorganised away by year three survives in the image from year one. The messy pile of partial replicas isn’t damage to be tidied — it is temporal redundancy doing archival work nobody intended. The preservation world has always known that lots of copies keep stuff safe;⁶ what the natural key adds is that lots of copies, unioned on a stable identity, keep stuff whole — more whole than the original.

So the practical rule that falls out, before AI touches anything: find the identity system the old software left behind. A UNID, a primary key in the exported table, a message-ID in the mail spool, a content hash. Every system left one, because every system needed one to function. That key is what turns a chaotic archive into a reconstructable one, and it’s deterministic — no model required for the part a model would only get wrong.

The archaeologist’s rule

None of this is safe by default, and the danger is precisely proportional to the enthusiasm. When you let a model loose on a backup server with scratch space and a goal, it will happily spin up ten parallel workers and go at the whole dig at once — which is wonderful, right up until one of those workers decides to “clean up” or “normalise in place.” A dig site has one rule above all others, and it transfers exactly:

The logic is simple and it’s the same logic that made deleting my mailbox a mistake. Storage is effectively free and has been for years — the cost per gigabyte has fallen by roughly half every eighteen months for decades.¹² Comprehension is now cheap too. Which leaves deletion as the only irreversible operation in the entire stack. Everything else — extract, parse, index, reorganise — you can redo tomorrow with a better tool, provided the territory still exists. The map can always be rebuilt. The territory cannot. Ten parallel threads of enthusiasm deserve a fence, and that is the fence.

What just got repriced

Step back from the mailbox and the backup drives, and see what the two cases actually did. They didn’t just recover some old files. They changed the price of a decision you and every organisation you know are making constantly — the quiet delete-or-keep call on the archive nobody can open. That decision has been made for decades under an assumption that has now flipped: that unreadable meant unreachable, and unreachable meant worthless.

This is the anti-container argument reaching its endpoint. I’ve written before that your data’s container is a vendor surface, not the data itself — that markdown will outlive NSF the way ASCII outlived every word processor, because the container is the mortal part and the information isn’t. What these two cases add is the last mile: even when the container has already died, the data behind it is no longer stranded, because the reader can be rebuilt. It’s the same capability that makes it possible to read and take over legacy systems with AI, pointed one layer deeper — at systems so legacy they don’t run anymore.

There is a companion argument to this one — about the economics of holding onto all that raw material, why you keep the bronze layer of everything and never throw the originals away. That’s a piece of its own, and I’ll leave it there. This one is narrower and, I think, more urgent, because it removes the last excuse the old economics gave you. You cannot tell yourself the archive is unreachable anymore. It isn’t. So the next time you’re standing over a dead-format mailbox, a stack of proprietary backup images, a database from a system that shut down in 2011 — don’t reach for delete. Go and look. The data was fine the whole time. What died was the reader, and the reader is something you can now build.

I deleted twenty years of my own history because I believed it was gone. It wasn’t — some of it survived in the Acronis images, and the rest is a lesson I’d rather you learn from than repeat. Before you delete another archive you can’t open: mount it read-only, and dig.