Backups and recovery
Know what each store holds and how it is protected, and read the last backup and tested restore on Hosting. After any restore, prove that the evidence, the audit trail and the findings are unchanged.
On this page7
Foxborne runs on your infrastructure, so your own backup service takes the backups and runs the restores. Hosting shows when the last backup ran and when a restore was last tested. After a restore, three checks prove that the evidence, the audit trail and the findings are what they were.
What each store holds#
| Store | What it holds | How it is protected | In the example |
|---|---|---|---|
| Original files | Files exactly as they arrived, hashed with SHA-256 on arrival | Written once. Foxborne cannot modify or delete an original. Encrypted with your key. | Object Lock, compliance mode, 7 years |
| PostgreSQL 16 | Events, notes, reports and the audit log | Storage encrypted with your key | Multi-AZ |
| Reports and case files | Every excerpt quoted exactly, with the SHA-256 of its file | Encrypted with your key | Kept 10 years |
| Basemaps and elevation | Site elevation and imagery your team uploads | Encrypted with your key | Kept until replaced |
| Audit log | Every import, view, edit, export and administrative change | Append-only and hash-chained. Streamed to your SIEM over syslog with TLS. | Never deleted |
| Backups | Copies taken by your backup service | Encrypted with your key | AWS Backup vault, daily, kept 35 days |
Events are derived from the originals: the same file and parser version always give the same event IDs. Notes and report edits are written by people, so the database backups are what protect them.
The example's backups#
| Item | Example value |
|---|---|
| Vault | AWS Backup vault hfr-foxborne |
| Encryption | Customer key |
| Schedule and retention | Daily, kept 35 days |
| Nodes footer on Hosting | Last backup 7 h ago. Restore tested on 12 Sep 2026. |
| Audit log | A System entry, Backup completed, on Backup vault, with the detail Snapshot of 18.4 GB, verified |
Backups and restores run in your backup service, the AWS Backup vault in the example. Test a restore on your own schedule, and check its result with the steps below.
Backups need the key too
The example encrypts its backups with the same customer key as the originals. Disabling that key leaves the backups unreadable along with everything else it protects.
Before you start#
- You need the Admin role to open Hosting. The audit log is open to admins and auditors.
- You have a restored deployment or a restore test running on your schedule.
- You can read your SIEM's copy of the audit stream.
- You have one approved report and read access to the originals it cites.
Confirm integrity after a restore#
Check Hosting
Open Hosting. Confirm that Version carries Signature verified and that the Encryption key panel names your key. Each row under Nodes should read Healthy.
Verify the audit chain
Open Audit log and select Verify chain. Foxborne recomputes each hash from the entry and the hash before it, so a missing or altered entry breaks the chain.
When every entry matches, the note reads Chain intact with the count of entries verified and the time of the latest. The check itself is recorded, as Verified audit chain.
Compare with your SIEM
The restored audit log ends where the backup was taken. Your SIEM received the audit stream over syslog with TLS, so it also holds the entries written after that point.
Find the newest restored entry in the SIEM's copy. Anything after it happened after the backup, and the restored log does not hold it. An export taken before the restore serves too: Export includes each entry's hash and the hash before it, so it can be verified offline.
Check a report against its originals
Pick an approved report and check its excerpts against the original files, as in Verify a report against the originals. Each excerpt names its file and that file's SHA-256, so anyone holding the original can check each line.
The report's footer says the same: Every excerpt can be checked against its SHA-256.
Run the rules again
Open a run that has findings, such as R-0931 in the example dataset, and select Run rules again. Rules are deterministic and each finding names its rule version and threshold, so a rerun gives the same answer.
The message should read Rules ran again. Results are identical to the previous run. The audit log records Ran rules again on the run.
Check the result#
A clean restore shows all of these:
- Chain intact after Verify chain, with the entry count and the time of the latest entry.
- The newest restored entry present in your SIEM, with every later entry accounted for there.
- Every SHA-256 in the report matching the original it names.
- Rules ran again. Results are identical to the previous run. on each run you check.
Troubleshoot#
Last backup is older than your schedule. Hosting shows when the last backup completed. Check the backup job in your backup service, AWS Backup in the example.
Recent audit entries are missing. That is expected after a restore, because they were written after the backup was taken. Your SIEM holds them.
A SHA-256 does not match. The excerpt cannot be verified against that file. Confirm you hashed the file from the originals store, where each original is written once and never changed, before anyone relies on the report.
Next#
- Audit log explains the hash chain and the export.
- Verify a report against the originals walks through the hash check.
- Encryption and keys covers the customer key.
- Retention, holds and redaction covers retention policy and legal holds.
- Monitor a deployment covers the Hosting signals day to day.