ADR-0026: Backup and retention posture¶
- Status: Accepted
- Date: 2026-08-17
- Deciders: El, Lachlan
- Supersedes: ADR-0014 §8
Context¶
ADR-0014 §8 backed up the registry and every tenant database daily on a uniform two-month retention. That treats all data as equally precious, which inverts the actual risk.
ABOS is orchestration-first (ADR-0001). Almost everything in a tenant's database originates in the client's own systems — AroFlo, Xero — and they retain it there. Backing all of it up inflates cost, widens the residency surface, and enlarges what a breach would expose, in exchange for protecting data the client already holds.
But "we don't create data" is not quite true, and the exceptions matter more than the bulk:
- Approval records exist nowhere else. They are the evidence behind "no review, no go" and the only proof of what was approved, by whom, and against which payload.
- Config, taxonomy and threshold rows exist nowhere else. Reconstructible only by redoing paid mapping work.
- Backfilled source data is recoverable but slowly. Re-pulling a year of AroFlo jobs against a 2,000 calls/day cap is days of calendar time — a recovery-time problem, not a data-loss one.
The correct axis is therefore not importance. It is recoverability.
Decision¶
- Data minimisation is the default. We do not store or back up client data we can afford not to. Where the client's own system is the system of record, that is where the data lives.
- Tiers, by recoverability:
| Data | Origin | Backup |
|---|---|---|
| Approval records and audit chain | Us — exists nowhere else | Daily. Retention floor applies. |
| Config, taxonomy, thresholds | Us | Daily. Small and cheap. |
| n8n workflows and credentials | Us | Daily. |
| Control-plane registry | Us | Daily, separately from tenants — it is the map. |
| Landing layer | Client's system | Weekly — not for data loss, to bound recovery time against the API cap. |
| Modelled / serving layers | Derived | Not backed up. Rebuilt from landing. |
The landing layer is still kept permanently on the box so metric redefinitions rebuild locally rather than re-pulling from source. Keeping it and backing it up heavily are different questions.
3. Mechanics: pg_dump per database — never a filesystem snapshot of a running Postgres. Per-tenant dumps to per-tenant paths, which is what makes client exit (ADR-0012) close to handing over a directory rather than extracting one client from a combined archive. Off-box, AU-resident (ADR-0008), encrypted at rest.
4. Retention: 30 daily, 12 monthly. Retention is not only recovery — it is how far back we can prove what the system did.
5. Per-client customisation, with a floor. Schedule and retention are per-tenant config rows and Ansible variables (ADR-0003), so a client with their own compliance obligation is accommodated without a code change. The approval log has a floor a client cannot request below. Longer on request; never shorter. Shortening it means discarding our own defence, and the client is not the party it primarily protects — so a request to reduce it is a conversation, not a config change.
6. The restore test is the deliverable, not the dump. A scheduled restore into a scratch container with a row-count diff against source, at least six-monthly, and the first restore proven before the first paying client goes live.
Consequences¶
Storage cost and breach surface stay proportionate to what only we hold. Client exit is straightforward because dumps are already per-tenant. Clients with genuine retention obligations are accommodated by configuration.
The floor on approval records means we may hold a small amount of client-adjacent data longer than a client would prefer. That is deliberate and must be disclosed in the service agreement, not discovered later.
Not backing up modelled and serving layers means a full host loss costs rebuild time — accepted, because they are deterministic from landing, and landing is backed up weekly precisely to bound that.
A monthly audit report offered to clients would be a product built on the approval log; offering it converts retention from internal policy into a contractual commitment, and must be priced accordingly.
Alternatives considered¶
- Uniform backup of everything (ADR-0014 §8) — superseded: pays storage and residency exposure to protect data the client already holds.
- Backing up nothing derived from client sources — rejected: correct on data loss, wrong on recovery time given the API cap.
- A single combined backup archive — rejected: cheaper to operate, but makes client exit an extraction exercise and couples tenants in the one place isolation matters most.