The short answer
Yes, a verification toggle belongs in the restore wizard — but it should be opt-in, default off, and implemented as a post-restore pass that reuses Duplicity's existing duplicity verify machinery rather than inventing a new checksum pipeline. The passphrase problem is already solved by the GNOME keyring integration Deja Dup uses today, and a sampled verification scope is the right default for desktop users.
What's confirmed vs. what's design judgment
Confirmed behavior: Deja Dup's restore wizard completes without any integrity comparison, and Duplicity (the backend) already supports a verify operation that compares restored data against backup manifest hashes. You can do this manually today:
duplicity verify <backup-url> /path/to/restored/files
Everything else — the toggle, sampling, UI placement — is a design proposal, not existing functionality. Version behavior varies across Deja Dup releases, so check your installed version's --help output before scripting against it.
Handling encrypted backups
The wizard already decrypts during restore, so verification needs no second passphrase prompt if it runs in the same session. Two safe approaches:
- Keyring reuse: retrieve the passphrase from GNOME Keyring (where Deja Dup already stores it with user consent) and pass it to the verify subprocess via the
PASSPHRASE environment variable — never as a command-line argument, which would leak into ps output and shell history. - Single-session verification: run the verify pass immediately after restore within the same spawned process context, so the credential never persists beyond the operation.
If the keyring is locked or the passphrase isn't stored, the wizard should skip verification with a clear notice rather than blocking the restore on a second prompt.
Verification scope: full vs. sampled
A full file-by-file hash comparison roughly doubles restore I/O: every restored byte gets re-read and hashed. For a multi-hundred-gigabyte desktop backup on a spinning disk, that can turn a 30-minute restore into an hour-plus operation.
A random sample of 5–10% of restored files (weighted to include at least one file per backup volume and all files above a size threshold) gives high confidence of catching systematic corruption — disk errors and truncation bugs rarely corrupt exactly one file — while adding only a few percent to restore time. The honest trade-off: sampling can miss isolated single-file corruption, so the UI must say so explicitly, e.g., "Verified 8% of restored files" rather than an unqualified "Restore verified."
Wizard integration without breaking flow
- Add a collapsed "Advanced" section on the restore confirmation page with a "Verify restored files after completion" checkbox, default unchecked.
- Run verification as a background task after the wizard reports success, with results in a notification and a per-file log at
~/.cache/deja-dup/. - On mismatch, list affected files and offer "restore this file again" rather than a generic failure dialog.
What you can do today
Until such a feature exists, verify manually after a restore:
# Full verification against the backup manifest
duplicity verify <backup-url> /restore/target
# Or spot-check a sample against known-good originals
find /restore/target -type f | shuf -n 50 | xargs sha256sum > /tmp/restored.sums
One caveat worth flagging: duplicity verify compares against the backup's stored metadata, so it catches restore-side corruption but not corruption that was already in the backup archive itself. For that, periodically test-restore to a scratch directory — no checksum feature substitutes for a proven-restorable backup.
kdeneon