In Hiberden, Verified is a status the software earns by re-reading your data, never a flag it sets once and trusts forever. This article shows you how to run a verification yourself and how to read the result. For the reasoning behind the model, see How verification works.
Verification always works, with or without a license.
Where the verify actions live
Verification is per copy, and it lives inside an archive's details. Double-click an archive in the workspace to open it. Each destination the archive is stored on gets its own row, and a written disk, NAS, or cloud copy shows two buttons:
- Quick verify: a fast BLAKE3 re-read.
- Full verify: the SHA-256, BLAKE3, and signature pass.
A copy already marked Failed or Missing does not offer them; there is nothing left to prove, and the fix is to re-write that copy from a good one.
Tape copies work differently: there is no per-copy verify button for tape in the desktop app. A tape copy is verified when it is written (the read-back gate below), re-checked when its cartridge is mounted (a setting, on by default), and can be verified on demand through a connected assistant's verify_copy tool.
Which one to run
Full verify is the one that counts. It re-reads the copy off its medium and checks the SHA-256 recorded when the archive was created, the recorded BLAKE3, and the signature on the archive's sealed note when one is present. It is the only pass that can put a copy into Verified, and the only one to run when you need an answer you would repeat to someone else.
Quick verify re-reads the same bytes but checks the BLAKE3 fingerprint only. Because BLAKE3 is far cheaper to compute than SHA-256, the check is rarely the slow part; the drive or the network is. Use it to re-check a lot of data often. It can:
- confirm an already-Verified copy still matches, and refresh its date, or
- catch a copy that no longer matches.
It cannot promote a copy to Verified. A copy that has never had a full pass stays where it is, and the app says so rather than implying otherwise. If the archive has no BLAKE3 fingerprint on record, quick verify runs a full pass instead and tells you it fell back. Cloud copies are always read back in full, so quick verify does not apply to them.
Reading the result
Whichever pass runs, there are three possible outcomes:
- The fingerprints match. A full verify marks the copy Verified (or keeps it there) and stamps the date. A quick verify refreshes an already-Verified copy, or reports a match on a copy it cannot promote.
- The fingerprints do not match. The copy is marked Failed. The bytes on the medium are no longer the bytes you archived; the fix is to re-write that copy from a good one. Hiberden informs you and stops there: it never auto-repairs, rewrites, or deletes anything on its own.
- The copy is not where the catalog expected it. The copy is marked Missing.
A full verify has one more distinct outcome. If the bytes match their recorded fingerprint but the archive's signature does not validate, the verify fails and says specifically that: a hash match with a bad signature is a different situation from ordinary decay, and it should not be reported as if it were the same thing. An archive with no signature recorded is not a failure.
Each copy carries the date of its last full pass and its last quick pass, so you can always see how fresh a copy's proof is and which kind of proof it was.
One tape-specific rule worth knowing: a tape copy is only marked Missing when its own cartridge (matched by volume label) is mounted and the archive is not on it. A wrong cartridge, an unreadable cartridge, or a drive with nothing loaded never changes a copy's status; you get an offline prompt instead.
If you hit a Failed result and want help deciding what to do next, see Verification failures.
When verification runs on its own
You do not have to remember to verify. Re-verification runs automatically in four places:
- After every write. The verify-after-write gate (on by default) reads each new copy back from its medium and re-hashes it before that copy counts as Verified at all.
- On a schedule. Settings > Verification takes two intervals: a quick re-check every so many days and a full verify every so many days, either of which can be set to 0 to turn it off. Hiberden works through disk and NAS copies in the background, stalest first, preferring an overdue full pass over an overdue quick one. Tape and cloud are excluded on purpose (see How verification works); they are verified when you ask. Background passes are marked as scheduled in Activity.
- After a tape mount. A setting (on by default) re-checks tape copies when their cartridge is mounted.
- During every restore. Restoring is itself a verification: every restored byte is re-hashed against the catalog on the way out.
The schedule is set once for the application, in Settings. It is not part of a policy: a policy decides how many copies an archive needs and where they go, not how often they are re-read.
Verifying from an AI assistant
If you have connected an assistant through the MCP connector, the verify_copy tool is one of the always-available read-and-verify tools. It performs the same real re-read and re-hash off the actual medium, so the answer is ground truth, not a stored flag, and the assistant cannot invent a Verified result.
It takes the same choice you get in the app: a mode of full (the default) or fast, with the same rule that only a full pass can promote a copy to Verified. The result names the algorithm that actually ran, and every completed verify is written to the local audit log. One caveat: cloud read-back verification runs inside the desktop app, not the connector, so for a cloud copy the connector answers that verification was not attempted there, which is not a failure. See Connect an AI assistant.