Why content-addressed storage changed how I think about backups

Content-addressed storage changes something about how you think about backup integrity. Here's the shift.

The old mental model

In a traditional backup — rsync, Time Machine, most cloud sync tools — files are the unit of truth. A file either exists or it doesn't, and its identity is its path. Corruption means a file at a known path has wrong content. The integrity check is: "does the content at this path match what I expect?"

The content-addressed model

In a content-addressed store, chunks are the unit of truth, and their identity is their hash. A chunk either exists with the content that hashes to its name, or it doesn't exist at all. There's no such thing as a chunk at the "right address" with the wrong content — that would be a different chunk.

This changes verification. In a traditional backup, you maintain a manifest and check every file against it. In a content-addressed store, the hash tree is the manifest. A partial or corrupted chunk is simply absent — the restore process discovers it when it needs it and the chunk isn't there.

What this means in practice

Frostmere's verify command walks the chunk tree and confirms every referenced hash exists. It doesn't need a separate manifest file. The chunks themselves are the manifest. This made the verification implementation straightforward and made corruption detection more reliable than any manifest-based approach I'd tried before.