Define the data and the recovery objective
Give the database service an owner and agree with the business on how much data loss and downtime the service can tolerate. Inventory primary databases, replicas, exports, object storage, development copies and backup systems. Record sensitive fields, retention needs, encryption ownership and the identities that can read, export or delete each copy. A backup is a separate data asset, not a lower-risk version of production.
Separate application access from schema migration, administration and backup access. Limit exposure at the network and identity layers, and avoid using a production administrator credential in ordinary application requests. For debugging, provide a minimized or synthetic dataset where possible. Track every temporary export with an owner and deletion deadline so an emergency support action does not create an unmanaged permanent copy.
Choose a recoverable and independently protected backup
PostgreSQL documents logical dumps, filesystem-level backups and continuous archiving as distinct approaches with different assumptions. Select a method that can satisfy the required recovery point and restore time, then include associated configuration, keys and external dependencies in the plan. A database file without the required recovery log, encryption key or compatible restore procedure may not be usable when it matters.
Use separate permissions and, where appropriate, separate administrative boundaries for backup deletion and production operation. AWS Backup Vault Lock illustrates a retention control whose modes and irreversible behavior require careful planning. Test retention and cost behavior on a safe vault before committing production retention. Immutability protects against some deletion paths; it does not establish that the stored data is clean, confidential or restorable.
Recover into isolation before restoring service
Perform scheduled restoration into a restricted environment with outbound email, payments, webhooks and background jobs disabled. Check the recovery timestamp, schema, row counts or application invariants, permissions and representative user flows. Measure the whole process from authorized request to usable service. A successful backup job is an input to this test, not its result.
For ransomware or destructive changes, establish the likely compromise window before selecting a recovery point. Preserve evidence and restore from approved sources with fresh credentials where needed. Investigate whether stolen identities can still read the restored database or delete its backups. Do not reconnect a repaired database to an application environment that remains under attacker control.
Exercise data theft as well as deletion
Use a designated test identity to perform a harmless export of synthetic data. Confirm that the event is attributable and that unusual extraction can reach a responder. Test denied export and deletion paths, including through backup administration tools. Record how an investigator can determine what data a suspect identity read, while recognizing the limits of the logging actually enabled.
Review restores after schema, key-management and infrastructure changes. Remove abandoned snapshots and exports according to the retention process, and preserve material subject to an active investigation through a restricted exception. Completion evidence should include the tested recovery point, measured restore duration, verification results, backup access review and proof that a production-only identity cannot erase every recovery option.
Controls to take away
- A successful backup is not proof of a successful restore.
- Backup confidentiality and deletion resilience require separate controls.
- Restore into isolation before reconnecting external side effects.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.