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 archive is not on the cartridge that is mounted. 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 its own rules, because a cartridge that is not in the drive proves nothing. These leave 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 cartridge cannot be read: status unchanged.
- A restore finds the wrong cartridge in the drive: status unchanged. A restore matches the cartridge by its LTFS volume label.
- A mount drops partway through a restore: status unchanged.
A verify is different. 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. For a tape copy adopted from an existing cartridge, a verify reads whichever cartridge is mounted: load the copy's own cartridge first, because if the archive is not on the mounted cartridge, the copy is marked Missing.
An offline tape is unknown, not gone. (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.