Preservation
The day you have to restore for real
A drive no longer mounts. A folder of print files opens with grey bands. A file has changed although nobody touched it. You need to restore your photo archive, and this is often when people make things worse: in a hurry, they copy a backup over the remaining files and replace originals that were still sound with an older or damaged copy.
The article Testing Your Backups explains why you should test a restore in advance. This one is the manual for the real thing: the restore you run because something is actually gone.
One rule governs everything else: a restore adds, it doesn’t replace. You restore alongside, you verify, and only then do you decide what takes the place of what.
Prepare the restore
Before copying anything, take ten minutes.
- Stop writing to the affected medium. A failing drive gets worse with every write. Don’t run repairs or defragmentation, and don’t “clean up” the damaged folder.
- Define what is missing. The whole archive, one series, a handful of files? Write down the names or folders involved. A targeted restore is faster and easier to check.
- Gather your keys. If your archives are encrypted, the encryption key and its passphrase are essential. Without them, no restore is possible.
- Prepare an empty location. A new folder, on a healthy drive, with enough room for what you are restoring. Not in the damaged folder, not in a synced folder, not next to the backups themselves.
Choose the copy
If you have several copies, they are not equal. The right one is neither the nearest nor necessarily the newest: it is the newest one proven to be sound.
| Copy | Advantage | Watch out for |
|---|---|---|
| Local archive | Fast, at hand | May share the original drive’s failure |
| Archive drive kept apart | Independent of your workstation | Age of the medium, last verification |
| Offsite copy | Survives a local disaster | Download time, access keys |
| Synced folder | Always up to date | Also reproduces mistakes and deletions |
For each candidate copy, ask three questions:
- When was it last verified, and with what result? A copy that was never verified is an assumption.
- Does it contain what is missing? A copy made before the lost series is useless, and so is one made after a corruption.
- Do its fingerprints match the manifest? Verifying the copy before extracting anything keeps you from restoring a mistake.
If two copies disagree, don’t pick one at random: compare their fingerprints with the original ones. The method is covered in How to Verify a Photo Archive’s Integrity.
Restore alongside, never on top
Restore into the empty folder you prepared, under a name that says what it is (“Harbour series, restored 27 October”). Never pick a copy tool’s “replace” option: it overwrites without telling a sound file from a damaged one.
If an earlier restore stopped halfway, complete it without overwriting: add only the missing files, and note the ones that differ from the copy instead of replacing them. A file that differs is information, not an error to be fixed automatically.
Be wary of watched folders. Restoring into a folder that a cataloguing or sync tool is monitoring can trigger an import, a sync, or a duplicate you didn’t want.
Verify the result
A restore isn’t finished until it has been verified.
- Count. Does the number of restored files match the manifest?
- Compare fingerprints. Each restored file must have the fingerprint the manifest records. That is the only proof the bytes are right.
- Open a sample. A few RAW files, a TIFF, a file with its XMP: technical proof doesn’t replace a look.
- Check the companions. XMP files, derivatives, related documents: they must have come back with their originals.
Only once these checks pass should you move the files to their final place. Keep the damaged folder aside until everything is confirmed.
Record it
Write a note, even a short one: date, files involved, likely cause, copy used, number of files restored, discrepancies found. This record does three things: it tells you where each file came from, it reveals a medium that keeps failing, and it proves later that the archive was looked after.
Common traps
- Restoring before diagnosing. A file whose fingerprint has changed isn’t always corrupted: if you wrote metadata into it or edited it, the difference is expected. Restoring it would wipe out that work.
- Restoring a copy that is already contaminated. An automatic backup may have copied the damaged file the night after the failure. That is why you verify a copy before using it.
- Forgetting the chain. An incremental backup holds only what changed since the previous one. Restored on its own, it gives you an incomplete folder, and nothing tells you so.
- Deleting the fallback too soon. Keep the copy you restored from, and the damaged folder, until the restore has been verified and the copy has been replaced by a fresh one.
How Obscura Vault restores
Obscura Vault applies each of these rules.
Verification before extraction. Vault verifies the archive before extracting anything: its signature, and the content fingerprint announced by the manifest. An archive that fails verification is refused (“Restore refused: the archive failed verification”). The content of an encrypted archive is decrypted with the first known key that opens it; the Keys and security chapter explains how to bring your keys back on a new Mac.
Nothing is overwritten. Files are restored into a new subfolder named after the archive. If that folder already exists, Vault offers to restore into a new folder (the default) or to complete the existing one: only missing files are added, no file already there is overwritten, and those that differ from the archive are reported. The library’s Archives folder is refused as a destination, and Vault warns you before writing if the chosen folder belongs to a project: the restored files would be imported as new originals.
Checked against the manifest. After extraction, Vault reads back every restored file and compares its fingerprint with the manifest’s. The final banner says how many files were restored, how many were already present, and whether they all match (Archive restored) or not (with the list of files concerned).
Incremental revisions. An incremental revision is never restored on its own: Vault rebuilds the project from its whole chain, verifies every revision before writing anything, and refuses the restore if a revision is missing. In that case nothing is restored, not even partly.
Offsite copies. From the Offsite screen, Vault downloads the package into a temporary folder, then restores it exactly like a local archive: verification before extraction, a new subfolder, no existing file overwritten, every file compared with the manifest.
The starting point is often the Integrity screen: a file marked “Fingerprint Differs” that was not changed on purpose is corrupted, and is restored from a verified archive or an offsite copy. Recording happens automatically: the journal logs “Archive restored” and “Restored from offsite”, and it is written only by appending. An unencrypted archive also remains usable without Vault, with standard tools.
Going further
The Create, verify and restore an archive chapter of the Obscura Vault guide walks through every restore screen. To see how Vault fits with the other applications in the suite, visit the software page or the unified documentation.