# Can encrypted audit backup verification prove recovery? A backup that cannot be restored onto a clean machine and checked without vault secrets is not ready for an incident. It may still be a copy of some files, but nobody has demonstrated that it will preserve the evidence you need when the original Mac, user account, or application state is gone. Encrypted audit records change the recovery drill in a useful way. You should be able to verify their continuity while they remain ciphertext. If the procedure needs an unlocked vault, a familiar workstation, or a developer who remembers which folder to copy, the procedure has hidden dependencies. Hidden dependencies are what turn a routine recovery into an argument during an outage. ## A passing restore and a valid audit chain answer different questions A restored directory answers a storage question: can this machine read the bytes that were saved? A verified hash chain answers an evidence question: do those bytes still describe one continuous, untampered sequence of audit records? You need both answers, and neither substitutes for the other. Teams often blur three checks into one reassuring word, "restore." Keep them distinct in the drill record. - **Transport integrity** asks whether the recovery copy matches the backup artifact you intended to transfer. A detached SHA-256 manifest can answer this. - **Chain integrity** asks whether every retained audit record connects correctly to its predecessor under the log format's verification rules. - **Recovery completeness** asks whether the restored set covers the period, sessions, and call records your retention plan says it should cover. A file checksum cannot expose a backup job that consistently omitted yesterday's audit segment. It will faithfully confirm that you received the incomplete set. Chain verification cannot tell you whether the job ran late or whether a retention rule removed records you were required to preserve. It confirms the internal history of the material presented to it. That distinction matters when someone asks, "Can we trust this?" The honest response should name the claim: "We confirmed that this copy transferred unchanged, the encrypted records verify as a continuous chain, and it reaches this timestamp." That is much stronger than saying that a backup restored successfully. NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, treats recovery testing and exercises as part of maintaining a workable contingency capability, not as paperwork completed when backups are configured. The useful lesson for a small engineering team is plain: a backup run proves a job ran; an exercise proves people and tools can recover a stated outcome. An encrypted audit trail gives you an outcome that can be checked without first opening the secrets store. ## The clean machine must lack your usual conveniences A clean recovery machine is one that has no prior relationship with the environment being tested. Create a new local account, install only the verifier and its documented prerequisites, and use a fresh working directory. Do not sign into cloud sync, copy a home directory, restore a package cache, or attach an old application data folder. Those details sound fussy until they hide the exact dependency that fails later. A synced configuration can supply a path that the procedure forgot to document. A remembered credential can let a tool fetch something it was supposed to find in the backup. A copied application directory can make the test depend on local state rather than on the recovery artifact. Keep vault recovery out of this drill. Do not import an encrypted vault, unlock it, or approve any action in an effort to make audit verification work. The verifier should inspect ciphertext and the cryptographic chain, not replay external actions. If someone says they need secrets to see whether the audit copy is intact, stop and identify which component has been confused with the audit verifier. Prepare the machine with a narrow purpose: 1. Install the documented release of the command-line verifier or the same release family used to produce the backup. 2. Create an empty drill directory on local storage with enough room for the ciphertext copy and a small evidence record. 3. Transfer the backup and its inventory or checksum manifest by the documented recovery path. 4. Keep the source medium and restored copy read-only during verification where the operating system and media allow it. The words "same release family" deserve attention. Audit formats can change. A drill should record the application version and verifier version used, then keep the installer or release artifact available under your software retention practice. Do not solve a format mismatch by installing whatever happens to be newest on an internet-connected laptop. That may repair compatibility for the moment while leaving your actual recovery procedure undefined. ## Check the copy before you ask the chain to speak Run a file-level check before chain verification. This separates a bad transfer from a structurally bad audit history and saves time when a damaged cable, partial download, or mistaken directory is the whole problem. On a Mac or another system with `shasum`, an inventory generated at backup time can look like this: ``` shasum -a 256 audit-export/* | sort > audit-export.sha256 ``` At the recovery site, copy both the ciphertext export and `audit-export.sha256` into the drill directory, then run: ``` shasum -a 256 -c audit-export.sha256 ``` Each listed file should report `OK`. A missing file, a filename that does not match, or a checksum mismatch is a transport or inventory failure. Record it as such before running the audit verifier. Do not regenerate the manifest from the recovered files, because that merely gives altered bytes a new receipt. This small artifact prevents a surprisingly common bad habit: an operator sees a verifier failure, copies the files again, and reports success on the second attempt without preserving what failed. The second copy might be the correct one. It might also conceal a failing backup destination, an intermittent transfer path, or an operator selecting the wrong snapshot. Retain the original failed copy, the manifest, and the command output in a restricted incident location. If your backup system already offers immutable object versions or its own checksums, use them as an extra transport control. They do not replace a manifest that travels with the recovery artifact, because the drill must still show what this restored copy contained at the moment it arrived. ## Verify ciphertext without unlocking the vault Once the file-level check passes, run the audit chain verifier against the copied audit data. The relevant property is that verification works over ciphertext and does not need a vault secret. With the Sallyport command-line tool, the verification command is: ``` sp audit verify ``` Run it from the documented recovery context for the copied audit data, not from the production account. The command checks the encrypted, hash-chained audit log offline. It should not trigger an approval card, request Touch ID, call an API, open an SSH connection, or require you to unlock the vault. Any of those events means the drill has crossed into a different system boundary. Do not reduce the result to a screenshot saying "passed." Capture the command itself, the verifier version, the audit export identifier or backup timestamp, the local path used for the copy, the date of the drill, and the operator's name. This record lets another responder distinguish a clean verification from a command run against the wrong directory weeks later. A useful pass criterion has three parts: the checksum manifest passes, the chain verifier reports success, and the restored material reaches the expected latest record boundary for that backup run. Phrase the third part with a real timestamp or sequence boundary from your own inventory. "Recent enough" is an opinion; "covers through the scheduled backup at 18:00 UTC" is a testable statement. Sallyport keeps the encrypted source log write-blind and projects both a Sessions journal and an Activity journal from it. That design makes offline chain verification the evidence check; the human-readable journals are useful operational views, but they are not a reason to unlock the vault during recovery. ## A broken chain needs preservation before repair A chain failure is not a cue to improvise. First preserve the exact copy that produced the failure, including its file metadata where your recovery process can retain it, the checksum manifest, verifier version, and complete command output. Then make a separate working copy if you need to compare sources. Several causes can produce the same failure symptom. A backup job may have captured a log segment while omitting its predecessor. Retention may have removed an older segment without retaining the boundary data that allows verification to continue. An operator may have combined two exports from different points in time. Storage damage and deliberate modification are also possible. The verifier can tell you that continuity does not hold; your recovery investigation determines why. Walk through a mundane failure before you meet it under pressure. A nightly job copies the newest encrypted log file to a backup volume. It skips a small companion record because the job uses a filename pattern maintained months ago. The next morning, a simple file count looks plausible and the newest record appears present. During the drill, the SHA-256 manifest passes because it was generated from that already incomplete export. The chain verifier fails because the newest record cannot connect to the omitted predecessor. That failure is good news in a drill. It found a backup definition error while the original data and the person who configured the job are still available. The fix is not to suppress the check or to redefine success around the files that happened to copy. Fix the export selection, preserve enough continuity data, make a new backup, and rerun the clean-machine exercise. Do not "repair" a failed backup in the evidence directory. You may need to retrieve an earlier retained copy or a second destination to restore service, but label it as a different source. For an investigation, people need to know which artifact failed and which artifact later verified. ## Restore scope must be written before the drill starts Decide what the audit backup is supposed to recover before you touch the recovery machine. The answer usually includes a time range, the records generated by the relevant agent sessions and external calls, and enough provenance to identify the producing release. It may also include supporting backup inventory and the detached checksum manifest. It does not automatically include every file associated with the application. The vault holds credentials and the audit trail records the gateway's account of agent runs and individual actions. Those are separate recovery objectives with different access rules. Pulling the vault into an audit drill expands the exposure of secrets without improving the chain result. Write a small scope statement that an operator can test. For example: ``` Recovery target: encrypted audit data for the scheduled backup dated [organization timestamp] Expected boundary: latest recorded audit entry is at or after [organization timestamp] Required checks: transfer manifest passes; offline chain verification passes Excluded from this drill: vault import, vault unlock, live API calls, SSH actions Evidence retained: source identifier, verifier version, command output, operator record ``` The bracketed fields are deliberate. Fill them from your backup inventory before the drill. Do not make the exercise pass by choosing a boundary after you inspect what arrived. This is also where retention policy meets reality. If a team promises that it can reconstruct a particular incident window, its scope statement must cover that window after ordinary deletions, failed jobs, and storage rotation. A verified copy from last week does not satisfy a requirement to investigate an event from yesterday. ## The approval model should be absent from verification Action approval and audit verification have opposite jobs. Approval controls whether a live agent process may use a credential to cause an outside effect. Verification asks whether stored audit ciphertext still carries an intact history. A recovery drill should not need to exercise the first job to perform the second. That separation catches a subtle but serious design mistake. Some teams build a recovery script that obtains a token, starts the normal application stack, then queries an online service to decide whether the backup is good. The script may work in the office and fail during a network outage. Worse, it can create new activity while investigators try to establish what happened before the outage. Keep the verification environment disconnected from live credentials and external systems. If your process requires a package download, obtain it before the formal exercise and record the exact version. If the verifier attempts network access, treat that as a procedure defect. An audit artifact should remain inspectable when DNS, identity providers, and the original machine are all unavailable. The same principle applies to people. The operator who can run the verifier need not be the person permitted to recover vault secrets. Separating those duties reduces unnecessary secret access and lets an incident team establish the condition of its evidence early. ## A drill record should make the next operator boringly effective A disaster recovery drill earns its keep when a different engineer can repeat it without guessing. Store a concise run record next to the procedure, but keep the restored ciphertext and command output under the access controls appropriate for audit data. Capture these facts in plain language: - Which backup source and timestamp the operator selected. - Which manifest, tool version, and clean-machine account were used. - Whether the checksum check, chain verification, and expected record boundary passed. - Any dependency that appeared, including an undocumented path, network request, missing installer, or permission prompt. - What changed after the drill and who owns the retest. Avoid scoring a drill as successful because the team found a workaround. A workaround may be necessary to restore evidence during an actual incident, but it identifies a gap in the documented process. Mark the original test failed until the ordinary procedure works on a fresh machine. Run this exercise after meaningful changes to backup scripts, audit storage, retention, or the app release used to produce records. Run it on a schedule that matches how quickly you would need trustworthy evidence after an incident. The exact interval depends on your obligations and backup cadence, so write it down instead of borrowing a number from another team. The first recovery drill should end with a preserved ciphertext copy, a verified chain, a stated coverage boundary, and a list of defects you can actually fix. If it ends with an unlocked vault and a relieved shrug, run it again.