Running a Verification
Updated July 17, 2026
Running a Verification
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.
Verify a copy on demand
Every written disk, NAS, and cloud copy has its own Verify action. Running it does one honest thing: Hiberden goes back to that copy's medium (a disk path, a NAS share, or a cloud object), re-reads the stored bytes, and re-hashes them against the SHA-256 recorded when the archive was created. A copy already marked Failed or Missing does not offer the action; 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.
Whichever path runs the verification, there are three possible outcomes:
- The hashes match. The copy stays Verified and its last-verified timestamp is refreshed, so you can always see how fresh a copy's proof is.
- The hashes 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.
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 after routine operations. In this build, re-verification runs automatically:
- 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.
- 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.
An honest note on schedules
A policy records a verify cadence as an ISO-8601 period (P90D is quarterly; the form defaults to P180D). In the current build that cadence is recorded but not executed: no background job runs verifications on a schedule yet. Treat the cadence as your documented intent, and run the Verify action yourself (or ask your assistant to, below) when a copy's last-verified date gets older than you want.
Verifying from an AI assistant
If you have connected an assistant through the MCP connector, the verify_copy tool is one of the 14 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. 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.