Backup, restore, exit and deletion
Recovery and deletion are one design problem: a successful restore must not resurrect records whose disposal was already approved.
Backup inventory
Section titled “Backup inventory”Record database PITR/WAL, snapshots, evidence objects, search indexes, queue/spool, configuration, secrets/key references and audit/WORM copies. For each: owner, region, encryption/key, schedule, retention, immutability, access, restore procedure, legal rule and deletion behavior.
Restore procedure
Section titled “Restore procedure”- approve restore scope/environment and incident/change;
- verify backup manifest, signature, encryption and tenant scope;
- isolate network and rotate potentially compromised credentials;
- restore database/objects/queues in documented order;
- verify schema/config/legal version compatibility;
- replay deletion/suppression tombstones created after backup point;
- rebuild search/cache from corrected sources;
- run tenant-isolation, audit-chain and sample workflow checks;
- compare counts/digests and RPO;
- authorise business access and delete test copies on schedule.
No production restore is released before tombstone reconciliation.
Tombstone record
Section titled “Tombstone record”tenant, subject/resource pseudonym, instruction ID/version, affected stores/categories,
approved time, destinations, verification query, hold exceptions, backup expiry and last replay.
Tombstones contain no unnecessary original content and are protected from ordinary deletion.
Customer exit
Section titled “Customer exit”Plan and owner → change freeze → export schema/version selection → scoped export + signed manifest → customer verification → connector/provider cutover → revoke service accounts/keys/support → delete active/control/search/cache → processor/subprocessor instructions → backup expiry → exception/hold schedule → final report.
Open formats: JSON/CSV for registers/cases/receipts, JSONL/CloudEvents for events, OpenAPI/schema, object archive with checksums, and human-readable PDF/HTML evidence. Encrypted package keys are transferred out of band.
Deletion certificate
Section titled “Deletion certificate”Contains tenant/entity, instruction, date/time/time zone, record categories, destinations, method,
verification, processor acknowledgements, backup expiry, exceptions/holds with source and signer.
It does not assert physical destruction beyond evidence received. If any destination is ambiguous,
failed or waiting for backup expiry, status is partial.
Key and crypto-erasure
Section titled “Key and crypto-erasure”Key destruction may render bounded encrypted data inaccessible, but only when key scope is known, all copies are covered and recovery/escrow is addressed. Record KMS destruction receipt and delay. Do not call shared-key rotation a tenant deletion.
- quarterly representative restore; annual full tier recovery;
- restore from a point before a known synthetic deletion and prove re-deletion;
- customer export independently imported into a clean tool;
- revoke connector/support access and prove calls fail;
- expire one backup generation and verify object/manifest lifecycle;
- simulate a hold that outlives tenant exit and later release/dispose it.
Failure handling
Section titled “Failure handling”Manifest mismatch quarantines backup. Missing key invokes recovery without bypass. Incomplete export does not trigger deletion. Customer non-confirmation follows contract/retention escalation. Subprocessor silence keeps partial status. Legal hold data moves to restricted archive with named owner and expiry review, not an orphan tenant.