When a verification does not come back clean, one of three things happens: the copy is marked Failed, the copy is marked Missing, or, when the check could not actually run (a transport error, an offline cartridge), the status is left untouched so you can retry. Unproven is not condemned. This article explains what each state means, what Hiberden will and will not do about it, and how you get back to protected.
What Failed means
Failed means the copy could not be proven intact by reading it back: either Hiberden re-read the copy from its medium and the re-hash did not match what was recorded when the archive was created, or the copy could not be read all the way through.
A copy can also earn this mark at restore time: if the copy you are restoring from fails its read-back on the way out, it is marked Failed at that moment and the app says it plainly: "X is corrupt: it failed its read-back hash and was marked Failed."
The three ways a check can fail, and why they are worded differently
A full verify checks three things, and it tells you which one gave way, because the fixes are not the same.
The bytes no longer match their fingerprint. The ordinary case, and the one decay produces. The medium holds something other than what you archived. Re-write that copy from a good one.
The bytes match, but the signature does not validate. The archive's fingerprint is signed by the installation that wrote it. If the bytes match their recorded fingerprint while the signature over that fingerprint fails to check out, that is not decay: something has altered the record rather than the data. Hiberden reports it as its own failure, in those terms. An archive with no signature recorded is not a failure; only a signature that is present and invalid is.
The bytes match SHA-256 but not the recorded BLAKE3. Both fingerprints are written when the archive is sealed. If one matches and the other does not, the sealed note has diverged from the archive it describes. This is reported distinctly too.
A quick verify checks only the BLAKE3 fingerprint, so it produces the first kind of failure and not the other two. A quick verify that fails still marks the copy Failed: a mismatch is a mismatch. What a quick verify cannot do is the reverse: a clean quick pass never promotes a copy to Verified. See Running a verification.
What Missing means
Missing means the copy is not where the catalog expected it. The file is gone from the folder or share, the object is gone from the bucket, or, for tape, the copy's own cartridge is mounted and the archive is not on it. During a restore the prompt for this case reads: "X is gone: it was marked Missing."
Missing is the word for an absent file everywhere it appears: the copy's own state, and the archive's coverage badge, which reads Files missing rather than the generic "Unprotected" when the copies say that is the real problem. A coverage badge reading Check failed means something different again: a check ran and did not pass.
Hiberden informs, it never repairs
On any failure, Hiberden tells you and stops there. It never rewrites, repairs, or deletes a copy on its own. An archive tool must not silently change what you treat as immutable, so it reports the truth and leaves the decision to you.
The practical consequences are visible, not hidden: a Failed or Missing copy is no longer offered as a restore source (only Verified copies are), and the archive's coverage badge drops to match.
How to restore protection
The fix is always the same shape: re-write that copy from a good one.
- Confirm you still have a good source. Run a full verify on the archive's other copies so you know at least one is genuinely intact. A quick verify sustains a copy but does not establish one. See Running a verification.
- Fix the underlying cause. A failing disk, a moved or renamed file, a bucket lifecycle rule that deleted objects. Re-writing onto a broken medium just fails again.
- Write that copy again from a good source. Open the archive's details and use Add copy here on the destination that is short. If several destinations are empty at once, Fill missing copies writes them one after another from a copy you already have. If the original folder is gone, restore the archive from a Verified copy first; that gives you healthy bytes, re-hashed on the way out.
One shortcut worth trying first: if a disk or NAS copy shows Missing and the drive or share was simply disconnected, reconnect it and run the verification again. Verification reads the actual medium, so a clean read-back is what settles the question.
Tape: what can and cannot prove Missing
Tape gets a stricter rule, because a cartridge that is not in the drive proves nothing. A tape copy is marked Missing only when its own cartridge, matched by the LTFS volume label, is mounted and the archive is not on it. Anything less leaves the status untouched:
- The cartridge is not loaded: status unchanged. During a restore the app prompts "X is offline: the cartridge isn't loaded. Its status was left unchanged." and offers "Retry this copy".
- The wrong cartridge is in the drive, or the cartridge cannot be read: status unchanged.
- A mount drops partway through a restore: status unchanged.
An offline tape is unknown, not gone: a tape copy is never condemned unless its own cartridge was actually checked. (Disk and NAS play by the simpler rule above: an unreachable path shows as Missing until the medium is back and a re-run verification proves otherwise.)
There is a related case that reads like a failure and is not. An archive imported from a legacy tape library may not have its exact location on the cartridge recorded. Hiberden says so in those terms rather than condemning it: an unlocatable import is not a lost archive.
When you are stuck
If a copy keeps failing and you cannot see why, or a status does not match what you can see on the medium, export a support bundle (Settings > General > Support bundle) and email it to support@hiberden.app. It is a single zip that you review and send yourself; nothing is uploaded automatically. See Export a support bundle.