Vault only says “verified” when it has proven that the bytes are the right ones. Not having been able to look is never good news, nor bad news: it is a third answer, which Vault keeps separate. This chapter explains each answer and what to do about it.
The four states of a file
Each file in the library is in one of these four states, according to its latest check:
| State | What Vault observed | What it proves | What to do |
|---|---|---|---|
| Verified | The file was read in full; its SHA-256 fingerprint is the one from the import. | The file is intact as of the date of the check. | Nothing. |
| Altered | The file was read in full; its fingerprint has changed. | The file is no longer the one imported: it was modified or corrupted. | Restore from a healthy copy, or treat it as a new original if it was modified on purpose. |
| Unverifiable | The file cannot be found (disk disconnected, file moved or deleted) or cannot be read (permissions, read error, interrupted read). | Nothing, neither good nor bad. | Make the file accessible and rerun the audit. |
| Never checked | No check recorded for this file. | Nothing yet. | Run an audit. |
The four numbers always add up to the total number of files: a file is never counted as “verified” because nobody looked at it.
In Files to Examine, the exact result of the latest check is shown: Fingerprint Differs, Missing or Unreadable.
Why “not verifiable” is not “verified”: a disconnected disk does not prove that the files it holds are intact. Counting it as good would hide exactly the situation in which files are lost without anyone knowing.
Why “not verifiable” is not “altered”: a file that cannot be found is not necessarily damaged. Counting it as corrupted would lead to restoring files that are fine and would drown the real alterations.
The verdicts of an archive
Verifying an archive (in Archives, or when sending offsite) gives one of these three verdicts:
| Verdict | Label in Archives | What it means |
|---|---|---|
| Verified | “Verified …”, Archive verified banner | The signature matches the manifest and the content’s fingerprint is the one announced. |
| Failed | “Failed (…)”, Archive failed verification banner | The archive was read and something is wrong (details below). Do not rely on it. |
| Unverifiable | “Unverifiable (…)”, Archive could not be verified banner | The archive’s folder cannot be found (moved, or on a disconnected disk), or the archive is signed by a key Vault does not know. Nothing is proven, either way. |
| — | Never verified | No verification recorded. |
The detail of a failure says what was found:
- “The manifest is missing.”
- “The signature is missing.”
- “The signature does not match the manifest: the archive may have been modified.”
- “The manifest is signed but unreadable.”
- “The archive’s content file is missing.”
- “The content’s fingerprint does not match: the archive is altered.”
- “The inventory annex (inventory.json) does not match this archive: the archive is altered.” (see The inventory annex)
An archive signed by a key Vault does not know (an Obscura Flow archive before its key is imported, or one from another Mac) is unverifiable (not verifiable), not a failure: “This archive was signed by a key Vault does not know: it could not be verified, which does not mean it is damaged.” Import the signing key of the installation that created it, then verify it again. See Keys and security.
Each verdict is recorded with its date: the Integrity screen shows each archive’s latest verdict, the Dashboard counts them.
Verifying an incremental revision verifies that package alone, like any archive: its verdict says nothing about the revision it builds on.
“Not restorable”
An incremental revision is restored only with its whole chain. It is therefore restorable at a place (the archives folder, a medium, an offsite destination) only if every revision of its chain has “verified” as its latest verdict there. If its own package is intact but a revision it depends on is not, or was never verified at that place, it is marked Not restorable: in the Archives list, on the Integrity screen and on the Dashboard. Hover over the badge to see which revision of the chain prevents it.
Such a revision does not count as a copy: not among the dashboard’s verified archives, not in a medium’s copies (chapter 6), not among offsite copies, where its whole chain must be sent to the same destination.
When verification finds a revision altered, its verdict names the revisions that depend on it: “The revisions built on it are no longer restorable from this place: 2, 3.” The journal records it too. Put back a sound copy of the altered revision (from another medium or offsite), then verify it again.
A revision not found (its folder deleted in the Finder, or moved) no longer counts as intact at that place, even if its latest verification was: Vault records “Archive not found” (unverifiable, not altered), against its own revision, as soon as it reads the Archives list again or verifies it, on a medium as in the archives folder. Its verdict also names the revisions that depend on it, which become Not restorable at that place, and only there: an offsite destination or a medium that keeps the whole chain still restores it. Put the revision back, then verify it again. If the archives folder itself is missing (a disk unplugged), Vault records nothing: it says so at the top of the screen.
Removing a revision others depend on
For the same reason, Vault refuses to remove a revision from a place (the archives folder, a medium, an offsite destination) while an incremental revision kept at that same place depends on it. The message names those revisions, for example: “Revision 1 cannot be removed from the destination “NAS”: revisions 2, 3, at that destination, depend on it.” To lift the refusal:
- first remove those revisions from that place, newest first;
- or keep a newer full revision at that place: made in the archives folder, verified on the medium, or sent to the destination. Once the revision is removed, those that depended on it become Not restorable at that place, and only there.
A revision kept elsewhere does not count: the chain must be whole at each place. Vault never removes a revision on its own. Today, only the Offsite screen removes a copy, with Delete Copy… (chapter 7), and that is where this refusal shows. If you delete a package by hand in the Finder, Vault cannot stop you, but it notices (see above): do not delete a revision others depend on.
Verifying an archive checks the fingerprint of its content as a whole. The file-by-file check happens at restore: each restored file is read back and compared with the manifest.
The verdicts of an offsite copy
Verifying an offsite copy (chapter 7) downloads its content and compares it with the manifest. The copy is verified, or damaged: missing, manifest missing, content missing or different fingerprint.
The verdicts of a certificate
Verifying a PDF certificate (chapter 9) gives a verdict on its signature, a revocation status and a timestamp state. Only Valid signature, known key is a full success; Intact, but signed by an unknown key means the document has not been modified but its origin is not verified.