Most backup tools tell you a copy was written. Hiberden goes one step further: it proves each copy still matches the original by reading the copy back and checking it, not by trusting that the write succeeded.
A fingerprint for every archive
When Hiberden seals an archive, it computes a fingerprint of the whole thing: a SHA-256 checksum, a short code derived from the data. Its useful property is that the code changes if any part of the data changes, even a single bit. A fingerprint mismatch is hard proof that a copy has changed; a match means the copy holds the same data for all practical purposes (the note at the end of this article explains that qualifier).
Hiberden records that fingerprint in two places: in its catalog, and in a sealed note written beside the archive itself. The fingerprint in that note is signed with a key generated by your installation and held in the operating system's keychain, so the note can be checked without contacting anything. Between them, those two records are the reference every copy is later measured against.
Hiberden also records a second fingerprint, BLAKE3, alongside the first. It exists to make re-checking fast, and the next section but one explains it. SHA-256 remains the fingerprint that decides whether a copy counts.
Reading back, not trusting the write
A successful write is not proof. Disks develop bad sectors, tapes can shed bits over the years (a slow decay often called bit rot), and an upload can be cut short without raising an error. So after Hiberden writes each copy, it reads that copy back off the actual medium and recomputes the fingerprint:
- Disk, NAS, and cloud copies are read straight from the storage.
- Tape copies are read back through LTFS, the tape's own filesystem.
If the fingerprint of what it read matches the one on record, the copy is proven intact and marked Verified. If it does not match, the copy is marked Failed. If the copy has gone missing, it is marked Missing. Verified is never assumed from a successful write; it is earned, every time, by a real read-back.
The same check is not limited to writes. Open an archive's details (double-click it in the workspace) and every stored copy carries its own verify actions. Running a verification walks through it.
Two checks, and only one of them promotes
A stored copy offers two actions, and the difference between them is worth understanding once.
Full verify re-reads the copy and checks everything on record: the SHA-256 fingerprint, the BLAKE3 one, and the signature on the sealed note when the archive has one. It is the only pass that can move a copy into Verified, and it is the one to run when you need an answer you can quote. A copy with no signature recorded still passes; a copy whose signature is present but does not validate fails, and says so distinctly, because that is a different problem from ordinary corruption.
Quick verify re-reads the copy and checks the BLAKE3 fingerprint only. BLAKE3 is dramatically faster to compute than SHA-256, so a quick verify is limited by how fast the drive or network can hand over the bytes rather than by the check itself. It can confirm an already-Verified copy still matches, refreshing its date, and it can catch a copy that has gone bad. What it can never do is promote a copy to Verified. If an archive has no BLAKE3 fingerprint on record, quick verify runs a full pass instead and tells you that is what it did.
Two things follow from that split, and they are deliberate:
- Use quick verify to sweep a lot of data often. Use full verify when the answer matters.
- BLAKE3 is a speed and defence-in-depth addition on top of SHA-256, not a replacement for it. SHA-256 is the name on the box, and it is the only fingerprint that earns Verified.
Each copy shows when it last passed each kind of check, so "verified" is never an undated claim.
What the states mean
- Verified: read back and the fingerprint matched the one on record.
- Failed: read back, but the fingerprint did not match, so the data on that medium has changed. Re-write that copy from a good one.
- Missing: the copy was not where the catalog expected it.
- Listed: a copy adopted from an existing tape, or one Hiberden found but has not proven. The catalog knows it should be there, but a read-back has not yet proven it. Listed is known-should-be-here; Verified is proven.
Because each copy is checked on its own, an archive shows Covered 3/3 only when all three copies have passed independently. That is the difference between hoping you have three good copies and knowing you did, as of each copy's most recent check. The badge reflects the last verification on record; run a verification again when you want a fresh answer.
Re-checking on a schedule
Verification does not depend on you remembering. Under Settings > Verification you can set two intervals: a quick re-check every so many days, and a full verify every so many days. Set either to 0 to turn it off. Hiberden then works through your copies in the background, oldest check first, and an overdue full verify takes priority over an overdue quick one.
The schedule covers disk and NAS copies. Tape and cloud are deliberately left out, and both exclusions are about not doing damage on your behalf:
- Tape, because a scheduled check cannot choose which cartridge is in the drive. Reaching for an archive whose cartridge is elsewhere would look like data loss when nothing is wrong.
- Cloud, because reading an archive back out of a bucket costs egress. Whether to spend that is your decision, not a default.
Both remain verifiable whenever you ask, and tape copies are still re-checked when their cartridge is mounted.
Scheduled passes are ordinary verifications: same checks, same rules, same records. Activity marks them so you can tell a background pass from one you ran.
Why it matters
Silent corruption is the quiet failure mode of long-term storage: a file decays on the shelf and nobody notices until the day it is needed, years later. Verification turns that silent failure into a loud one you can act on, while a good copy still exists to re-write from. The same check is also why restoring is safe: Hiberden re-checks the fingerprint on the way out, so every restore is itself a verification.
For the curious: the fingerprint is a cryptographic checksum computed over the whole archive, the same idea used to verify software downloads and secure connections. It is strong enough that two different sets of data will not realistically share one.
Where to go next
- Running a verification shows how to re-check any copy on demand.
- Verification failures covers what to do when a copy comes back Failed or Missing.
- Reading coverage status explains the badge that rolls these states into one answer.
- Verified 3-2-1 Archiving covers how many copies to keep, and where.
- What a verification report proves covers the artifact you hand to someone who asks for evidence.