The archive and its history

The archive started as years of digital life distributed across drives and backups. Photos sat beside source code, old websites, documents, installers, caches, and exports from services that no longer existed. Folder names provided some clues, but copies accumulated each time a machine or drive was backed up.

A filesystem search could locate a familiar filename. It could not explain how many copies existed, which content was unique, which projects belonged together, or whether a file could still be opened. Before reorganizing anything, I needed a durable record of what was there.

First, make the archive visible

The original system separated discovery from interpretation. A Go scanner walked the filesystem, recorded paths and sizes, computed xxHash64 content fingerprints, and extracted available EXIF metadata. PostgreSQL held the results. Rails added directory browsing, specialized media records, and duplicate inspection.

That separation was useful because the inventory and the decisions had different lifetimes. A path described where something was found. A backup decision or project note described what I learned about it. The application could develop those decisions without rewriting raw observations.

The documented July 2026 inventory counted millions of scanner records and over a million unique contents. The original guide described roughly half of the byte volume as duplicate overhead. Its rounded totals captured the scale of the problem; the dated evidence table keeps exact row counts and upload outcomes separate.

Then, preserve content independently of the drive

Deduplication made it possible to preserve one original per content identity while retaining links to the historical occurrences. The cloud upload campaign moved canonical originals into content-addressed Backblaze B2 objects. Wasabi served application images and converted media, while a separate B2 bucket held database transfer packages.

The preserved original became more than an offsite copy. The application could fetch it to prepare a viewable image, convert an old video, inspect a bounded sample of an unknown file, or recover a source tree when the original drive was unavailable. Cloud preservation explains what is checked and what each storage role protects.

From inventory to interpretation

The newer features add meaning without pretending that inference is certainty.

File analysis uses path rules and bounded samples to recognize formats and recommend keep/skip decisions. Life eras add overlapping biographical context rather than requiring every item to fit one folder. Photo analysis detects faces locally, then lets the owner name people, add missed faces, and review experimental match candidates.

These workflows retain the evidence/decision distinction. A model’s confidence is not measured accuracy. An era’s date range does not assign files automatically. A face similarity score is not a confirmed identity.

Recovery is the payoff

The archive also contains the ingredients of earlier websites and tools. Recovered writing and database exports became the restored flombaum.com. Archival social data became Tweefle’s reconstructed Twitter wall. Sawbaum recovered the shape of a Vine montage interface while acknowledging the original media that did not survive.

These restorations show why retaining provenance matters. A restored page is a combination of surviving artifacts, representation changes, and modern code. Explaining those boundaries makes the result more useful as history.

The guide now follows that larger journey: discovery, identity, preservation, interpretation, curation, and reconstruction. Continue with how it works for the technical boundaries connecting those stages.