Moving house with the list written at the old place.
When you move, the removal company assures you: "truck sealed, seal intact, no problems". True, and it says nothing about your TV. They check their own truck, not your house.
To know whether the TV arrived, there is only one way: write the list at the old house, before leaving, and check item by item at the new one. And the list cannot travel inside the truck, or whoever lost the TV can also "fix" the list.
SHORE does exactly this with backups. Backup tools check whether the repository is consistent with itself. SHORE checks something else: whether what went in is what comes out.
One list at the source and two proofs.
The list: on every backup, SHORE records at the source the path, size and fingerprint of every file the contract says must be kept. The list lives outside the backup repository.
The full proof actually restores everything into a temporary folder and checks file by file. It is the gold proof, run weekly or monthly. The sampled proof picks a few files at random (any auditor can redo the draw from the date and the backup), restores and checks them in about a second. It is the daily proof.
Every proof becomes a line in a permanent journal, which can be sealed in GIRDER. The question almost no company can answer, "when did our backup last provably restore?", becomes a lookup.
For databases, the fingerprint is per table: the row count plus a fingerprint of the content in a fixed order. That way the proof climbs the ladder up to the business rules.
"No errors were found." 138 files were missing.
On 18 July 2026 we ran SHORE against a real repository of 322 files and 236 MB, using restic, a widely used backup tool. On the healthy backup, the full proof restored all 322 in 1.3 seconds (the sampled one, in 0.8 s).
Then we simulated the most common real-world accident: someone "optimises" the backup with an exclude rule ("that folder is just cache") and it swallows 138 files, including the evidence packages. The backup runs, the snapshot is saved, and the tool's check replies "no errors were found". It is right: the repository is perfect. It is just empty of what mattered. SHORE rejected it, naming every missing file.
Finally, we flipped one byte in 8 storage blocks (141 MB). The sampled proof rejected it on the first run.
| Situation | Tool check | SHORE proof | In practice |
|---|---|---|---|
| Healthy backup | ✓ no errors | ✓ 322/322 in 1.3 s | the proof costs seconds, so it can run every day |
| Wrong exclude rule | ✓ "no errors were found" | ✗ 184/322, 138 missing | the "successful" backup that did not keep the contract; only SHORE catches it |
| One bad byte in 8 blocks | not run (the full version would catch it) | ✗ 0/40 in the sample | rotten storage does not pass silently |
We also measured the first step for databases, on a test Postgres: a fingerprint per table, steps 1, 3 and 5 of the ladder, and two attacks (a deleted row and a renamed table) caught only by the fingerprint.
When continuity is an obligation.
A good fit
- Anyone obliged to stay up: banks, health, regulated sectors. The difference between "we think it restores" and "we proved it restores" is the product.
- Contracts with recovery targets: how much data you may lose and how fast you must be back are already in the contract; SHORE measures against them.
- Audit: the auditor does not need to trust the journal; they redo the draw and rerun the proof.
- With the family: every proof becomes a signed line in GIRDER, with time proven by PLUMB.
Not enough on its own
- Garbage in, garbage recorded: if ransomware damaged the source before the backup, the list records the damage.
- The sample may miss the problem: a small corruption in a block not drawn passes the sampled proof. That is why the periodic full proof exists.
- The list must live outside: if it sits inside the repository, whoever sabotages the backup also edits the list.
What must come back, recorded before the backup: path, size and fingerprint of every file.
The full one restores everything and checks; the sampled one checks a few random files, in seconds, every day.
How much data the company can afford to lose and how fast it must be back. Usually already in the contract.
Where this could be wrong.
One measured repository
The measurement was on one real repository of 322 files and one test database. It shows the mechanism; scale and variety of systems are not yet measured.
The sample is probabilistic
It catches corruption with a chance proportional to the share affected. Guaranteeing every file is proven every N runs is the next step.
The tool would also catch the byte
In the bad-byte case, restic's full check would also catch it. SHORE's edge is the wrong exclude rule and the continuous journal.
It does not protect the source
SHORE proves that what left comes back. If the source was already damaged, it proves the damage came back.
← Certified telemetry · stickybit.com.br
- Our own measurement, 18 Jul 2026: restic 0.19.1 on a real repository of 322 files (236 MB); three situations (healthy, exclude rule, 1 byte in 8 blocks).
- SHA-256 fingerprint per file; the sample draw is reproducible from the date and the backup.
- First database step measured on a test Postgres.