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). This build cannot re-verify a tape copy the desktop wrote: the copy is stored in part files, and both the Verification report's re-verify and a connected assistant's verify_copy look for a single archive file and, with any cartridge in the drive, do not find it and mark the intact copy Missing. For an archive with a tape copy, untick "Re-verify every copy before reporting" so the report reads the records and changes no status. If a tape copy was already marked Missing this way, open the archive and use Write to tape on that copy: it writes the copy again from a written disk or NAS copy of the archive and marks it Verified once it reads back. Until then the tape copy is not offered as a restore source.
Which one to run
Full verify is the one that counts. It re-reads the copy 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: an unreadable cartridge or a drive with nothing loaded never changes a copy's status. A verify that cannot load the cartridge stops and says so, and a restore says the cartridge is offline so you can load it and retry. For a tape copy adopted from an existing cartridge, a verify reads whichever cartridge is mounted, so load the copy's own cartridge first: if the archive is not on the mounted cartridge, the copy is marked Missing.
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 three 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. Both start at 0, which is off; set a number of days to turn that pass on. 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); cloud copies are verified when you ask, and tape copies as they are written. Background passes are marked as scheduled in Activity.
- 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, 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. A second caveat: do not use verify_copy on a tape copy the desktop wrote; it looks for a single archive file, does not find the part files, and marks the intact copy Missing (see "Where the verify actions live" above). See Connect an AI assistant.