The database backup strategy decision record: why the backup verification model you chose determines your data loss ceiling and your recovery confidence surface

Published 2026-07-17 · WhyChose

Database backup decisions are made when the team first deploys a production database, when the initial infrastructure is set up and someone adds a scheduled backup job before the service goes live, or when a new engineer writes the first disaster recovery runbook and asks "how do we get the data back?" The AI session that configures backup is practically focused and reaches a working state quickly: it enables RDS automated backups or configures a pg_dump cron job, sets a retention period, points the output at an S3 bucket or a Barman repository, and verifies that the first backup completes successfully. The session ships a backup configuration that the team observes producing backup files on schedule with no errors in the job logs.

What the AI session does not produce is the second half of the backup strategy. The session answers "how do we take backups?" and delivers a working schedule. It does not ask: what is the backup verification model — is the backup actually tested to confirm that restoration produces a working database, what is the verification cadence, how is a silently failing backup job detected before a recovery event reveals it, and what constitutes a successful restore (schema correct, all tables present, row counts matching expected values, sequences at correct positions, application queries returning correct results)? What is the RPO specification per data class — how much data loss is acceptable for user account records versus payment transactions versus analytics event tables versus audit logs, whether the backup frequency matches each class's RPO, and how point-in-time recovery closes the gap between snapshot frequency and continuous durability? What is the backup storage isolation model — are backup copies stored in the same account, region, or provider as the primary database, can a credential compromise or ransomware event that affects the production environment simultaneously delete every backup snapshot using the same credentials, and what is the mechanism for shipping backups to a location not accessible from the production account? What is the restoration time analysis — how long does restoration actually take for the current database size from the current backup storage location over the current network path, whether that time is consistent with the disaster recovery RTO target, and what format portability constraints exist for the backup format in use when the restoration target is a different database version from the source? What is the point-in-time recovery model — whether WAL archiving or binary log archiving is enabled, what the archive shipping lag is, what the archive retention period is, and how PITR interacts with the snapshot-based backup in the actual recovery procedure? Each of these questions has an answer that is not derivable from "we run pg_dump nightly with 30-day retention to an S3 bucket and the job exits 0 every night" as the team describes the backup configuration. Each answer determines whether the team discovers a data loss event through a customer complaint about missing records or through a monitoring alert with an actionable backup to restore from, whether a ransomware attack that deletes production data also destroys the backup copies stored in the same account, whether a restoration attempted at 2 AM during an incident takes the estimated 45 minutes or the actual 11 hours for a database that has grown significantly since the estimate was made, and whether a schema migration that corrupts a production table can be recovered with point-in-time precision or only with a full snapshot restore to an earlier state. The answers exist in the AI sessions. They are the operational commitments behind the backup job. They are almost never written down.

Two ways backup decisions produce the wrong outcome in production

The silently failing backup job and the ransomware event

A B2B SaaS company with 95,000 user accounts deploys its production database on AWS RDS PostgreSQL. The setup session enables RDS automated backups with a 7-day retention period and creates an additional nightly pg_dump job that uploads a plain-format SQL dump to an S3 bucket in the same AWS account for "belt and suspenders" redundancy. The cron job runs nightly, logs "backup complete" when the upload succeeds, and sends no notification on failure. Three weeks after the setup, an S3 storage quota issue causes the bucket to reject further uploads silently — the S3 PutObject call returns an HTTP 200 because the upload began successfully, but the object is stored as zero bytes because the quota was checked against the bucket policy's size limit after the response was already returned. The pg_dump output is zero bytes for each subsequent nightly run. The cron job continues logging "backup complete" because it checks the exit code of pg_dump (which exits 0) and the exit code of the S3 upload command (which also exits 0 after receiving the HTTP 200 response). No alert is configured on backup output size. The team is unaware of the silent failure.

Six weeks after the storage quota issue begins, an attacker compromises a developer's laptop through a spearphishing attack and obtains the developer's AWS IAM credentials from the AWS credentials file in the home directory. The credentials have been provisioned with administrative permissions that include S3 full access and RDS full access. The attacker first enumerates the S3 bucket contents and discovers both the most recent successful RDS automated backup snapshot IDs and the S3 backup bucket. The attacker uses the RDS API to delete all seven automated backup snapshots (seven calls to rds:DeleteDBSnapshot, each succeeding because the IAM credentials have rds:* permissions). The attacker then issues a rds:ModifyDBInstance call setting BackupRetentionPeriod to 0, which disables automated backups and causes RDS to begin deleting backup snapshots as they age out of the now-zero retention window. Finally the attacker runs a DELETE query against every table in the production database using the database credentials found in the application environment variables on the same compromised laptop. The data deletion takes eleven minutes.

The team discovers the incident forty minutes after the DELETE queries complete when customer support begins receiving reports that accounts are missing. The team attempts to restore from RDS automated backups and discovers they have been deleted. The team then attempts to restore from the S3 pg_dump files and discovers that every file from the past six weeks is zero bytes — the three most recent files with valid content are from before the storage quota issue, with the most recent valid dump being 25 days old. The RPO the backup configuration was intended to achieve was 24 hours. The actual achievable RPO at the time of the incident was 25 days, not because the retention policy failed but because the backup verification model was absent: no procedure existed to confirm that the S3 backups contained valid data, and no alert existed on backup file size that would have detected the silent failure. The incident cost 25 days of user account changes, payment events, and subscription state changes.

The untested restoration procedure and the compliance audit recovery test

A fintech company running a payment processing API stores all transaction records in a self-managed PostgreSQL instance on a dedicated server. The founding database session configures a nightly pg_dump using the custom compressed format (pg_dump -Fc) to a mounted NFS backup volume. The backup is scripted, exits 0 nightly, and the script has been running without modification for 18 months. The disaster recovery runbook — written during the initial infrastructure setup — says "to restore the database, run pg_restore from the latest backup file on the NFS volume." The runbook was written by the engineer who configured the backup job and has never been executed in a recovery scenario.

During a scheduled compliance audit, the auditor requires a demonstrated restoration test: the team must restore the database to a test environment from backup and confirm that the restored database is consistent and complete. The restoration test reveals four problems. First, the most recent backup file is 1.8TB and the restoration target environment has a 1Gbps network link to the NFS volume; the restore takes 4 hours to transfer the file and an additional 7 hours for pg_restore to decompress and replay the SQL statements, for a total of 11 hours. The founding estimate in the DR runbook said "restoration takes approximately 45 minutes" — the estimate was based on a development database of 8GB tested at the time the runbook was written, and the production database has grown 225x since the estimate was made. The disaster recovery RTO target stated in the company's compliance documentation is 4 hours. The restoration time is nearly 3x the RTO target. Second, the PostgreSQL version on the restoration target environment is 15.3, while the backup was taken from a PostgreSQL 13.8 instance. The custom compressed format produced by pg_dump 13.8 is not fully portable to pg_restore 15.3: specific catalog format differences cause pg_restore to fail on several stored procedure definitions, leaving those procedures absent from the restored database. Third, the backup procedure uses pg_dump without the --no-owner flag; the restoration target environment does not have the same database roles as the production environment; pg_restore fails on ownership assignment statements and must be rerun with --no-owner, a flag not documented in the DR runbook. Fourth, the backup does not include a sequences dump (pg_dump does not dump sequences separately from the tables in plain format, but the custom format may not capture the current sequence values accurately if the database was under write load during the dump window); the restored sequences start at values lower than the maximum existing primary key values in several tables, causing the first batch of new inserts after restoration to fail with duplicate key violations on the primary key constraint. Each of these problems was discoverable only by executing a restoration — the backup job running cleanly for 18 months gave the team no information about whether the backup was actually restorable into a working database.

Three structural properties that backup decisions determine

The backup verification model and the recovery confidence surface

The backup verification model determines whether the team has actual confidence that a backup can be restored when needed, or whether the team has the appearance of confidence based on a backup job that exits 0 without having confirmed that the output is restorable. The distinction matters because the scenarios in which backups are needed — ransomware events, accidental data deletion, corrupted migrations, storage hardware failures — are also scenarios of high stress, time pressure, and system instability. A restoration procedure that works correctly in a calm environment with expert operators has no bearing on a restoration that must be performed at 3 AM by an on-call engineer who has never executed the procedure, on a database that has grown significantly since the procedure was last tested, against a restoration target that may have a different PostgreSQL version from the backup source. The only mechanism for producing real confidence is to execute the restoration before it is needed under conditions that approximate the actual recovery scenario.

The backup verification model must specify four properties: the verification cadence (how frequently a restoration test is performed — monthly is a common minimum; quarterly is the minimum for databases whose size changes slowly; nightly is appropriate for high-criticality databases where the backup format or storage path changes more often), the restoration target (a separate environment isolated from production, sized to be a realistic analog of the production database, ideally at the same PostgreSQL or MySQL version as the production database), the verification procedure (what the test operator must confirm before the test is considered successful — schema correct, table list complete, row counts for key tables matching expected values, sequence values above the maximum existing primary key values, a set of application-level read queries that exercise the most critical join paths returning correct results), and the failure response (what happens when a restoration test fails — how the team is alerted, what the escalation path is, and what the procedure is for investigating whether the failure is a backup format issue, a storage issue, a procedure issue, or a database version incompatibility). Separately, the backup monitoring model must specify the signals that detect a silently failing backup job before a recovery event reveals it: backup job exit codes are necessary but not sufficient; backup output size compared against the previous backup and against the current database size is required; backup file readability verification (reading the first and last blocks of the backup file to confirm it is not zero bytes or truncated) runs after every backup job; backup object metadata (S3 object size, last-modified timestamp, ETag for integrity) is collected and compared against expected values in a separate monitoring system from the backup job itself. The database decision record specifies which database engine, version, and configuration the backup strategy must support; version changes in the database engine are a verification trigger because format portability between versions must be re-tested whenever either the backup source or the restoration target changes major version.

The RPO specification per data class and the data loss ceiling

The Recovery Point Objective is not a single number for the database — it is a per-data-class specification that reflects the business cost of losing a specific category of data over a specific time window. Different data in the same database has a different acceptable loss window: losing 24 hours of user account changes (password resets, profile updates, subscription tier changes) is recoverable through customer support interactions; losing 24 hours of payment transaction records violates financial record-keeping requirements and potentially triggers regulatory notification obligations; losing 24 hours of analytics event ingestion is recoverable because those events can be re-processed from the event source or reconstructed from CDN logs; losing 24 hours of audit log entries may violate compliance requirements for which audit log completeness is a certification condition. The RPO specification must enumerate each data class, state the maximum acceptable loss window for each, and state the mechanism by which that RPO is achieved.

For a nightly snapshot-based backup, the achievable RPO is bounded by the time since the last successful snapshot — up to 24 hours for data written after the snapshot completed. For write-ahead log (WAL) archiving in PostgreSQL or binary log archiving in MySQL, the achievable RPO approaches the archive shipping lag, typically under 60 seconds for continuous archiving to durable storage. The RPO specification must state which data classes require continuous-archive precision and which can tolerate snapshot-frequency precision, because the infrastructure cost and complexity of WAL archiving is higher than snapshot-only backup, and applying the same precision to analytics event tables as to payment transaction records overbuilds the recovery model for data that does not require it. The RPO specification must also address the gap scenario: when a snapshot backup is taken at 02:00 and an incident occurs at 01:55 the next morning, the maximum data loss from a snapshot-only backup is 23 hours and 55 minutes for data written during that window; for a PITR-enabled backup, the maximum data loss is the archive shipping lag at the time of the incident, regardless of when the last snapshot was taken. The disaster recovery decision record is the downstream document that specifies the RTO (how quickly the service must be restored) and the operational runbook for recovery; the backup strategy decision record is the upstream document that specifies the RPO (how much data the recovery will return) and the backup infrastructure that makes the recovery possible — the DR runbook cannot specify the recovery procedure for a scenario whose data loss window is not bounded by a documented RPO. The database read replica decision record specifies the replication lag and the replica promotion procedure; read replicas are not backups — a DROP TABLE on the primary propagates to replicas within the replication lag, a corrupted schema migration applies to replicas as it applies to the primary, and a ransomware event that deletes data on the primary propagates the deletions to replicas before the team can halt replication. Replicas provide high availability; backups provide point-in-time recovery from data modification events.

The backup storage isolation model and the ransomware blast radius

The backup storage isolation model determines whether a single failure event — a credential compromise, a ransomware attack, or an administrative error — can simultaneously destroy both the production database and every restorable backup copy. Storage isolation is not about redundancy (having multiple copies in the same storage layer) but about administrative independence: backup copies are stored in a location whose access credentials are not accessible from the production environment, so that compromising the production environment does not grant the ability to destroy the backup copies.

Three isolation architectures exist with different blast radius profiles. The first is same-account isolation: backups are stored in a separate S3 bucket or storage path from the production database, but in the same cloud account. A compromised IAM credential with account-level S3 permissions can delete the backup bucket. An AWS account with an organization-level backup policy that prevents deletion of backup resources provides stronger isolation within the same account, but the protection depends on the organization-level policy being correctly configured and maintained. This is the minimum isolation model and is appropriate only for scenarios where the threat model does not include a credential compromise with account-level access. The second is cross-account isolation: backups are written to a dedicated backup account with a separate set of IAM credentials, and the production account's IAM policies do not include permissions to assume a role in the backup account or to write to resources in the backup account; the backup transfer mechanism writes to the backup account using a dedicated backup IAM role whose credentials are not stored in the production account. A compromised production account credential cannot access the backup account. Cross-account isolation is the standard minimum for production databases in organizations with a threat model that includes credential compromise. The third is cross-provider isolation: backup copies are stored at a different cloud provider from the primary database (primary on AWS, backup on Backblaze B2 or Cloudflare R2 or Google Cloud Storage with a separate billing account), or on tape or cold storage with an offline transport step. Cross-provider isolation eliminates the blast radius entirely for account-level compromises but introduces additional complexity in the backup transfer mechanism (authentication to a different provider's API, network transfer costs across providers, and a more complex restoration procedure when the primary provider is unavailable). The storage isolation model must also specify the backup transfer credentials: how the production backup job authenticates to the isolated storage location, how those credentials are managed, rotated, and revoked, and how the credentials are stored in the production environment in a way that allows the backup job to use them without exposing them to the same blast radius as the database credentials. The secrets management decision record is the upstream document specifying how backup storage credentials are provisioned, rotated, and scoped; backup storage credentials that are stored in the same secrets management system as database credentials with the same access scope do not provide the isolation the model requires.

Three AI session types that embed backup decisions without documenting them

The initial infrastructure setup session is where the backup configuration is established for the first time. The session is triggered by a concrete operational requirement — the database is being moved to production, and production systems need backups. The session is focused on enabling backups before the service goes live: it picks the backup mechanism most readily available (RDS automated backups because it is a checkbox in the console, a pg_dump cron job because the engineer knows pg_dump, Barman because a blog post recommended it), sets a retention period that sounds reasonable (7 days, 30 days), configures the storage location (an S3 bucket in the same account because the team already has S3 access), and verifies that the first backup completes. The test scenario is: the backup job runs and exits 0. The adversarial test scenario — does the backup produce a file that can be restored to a working database? — is not part of the session goal, because the goal is "have backups" not "have verified restorable backups." The storage isolation question — should the backup bucket be in the same account as the database? — is not raised because account-level isolation is overhead when the immediate problem is getting backups enabled before the launch deadline. The RPO question — how much data loss is acceptable for each category of data? — is not raised because the session is about enabling backups, not about specifying what the backups are intended to achieve in a recovery scenario.

The database-in-production session is the moment when the data model grows enough that backup adequacy should be re-examined, but rarely is. The team adds a payments table, a financial transaction table, or an audit log that makes data loss windows meaningful in a new way — losing 24 hours of payment records is qualitatively different from losing 24 hours of beta user session data. The session adds the table, migrates the schema, and verifies that the application writes correctly to the new table. The backup job already runs nightly and the team is aware of it. The question "does our backup strategy meet the RPO appropriate for financial transaction data?" is not raised because the backup job is running correctly, the retention period has not changed, and the session is about the schema migration not the backup strategy. The RPO specification that would make clear that nightly snapshots are insufficient for payment transaction records without WAL archiving remains unstated. The open-source extractor surfaces these database setup sessions and schema migration sessions from AI chat history, recovering the backup configuration choices and the data class decisions made before the team needed to understand what the actual achievable RPO was for each data category in the database.

The disaster recovery planning session is where the backup strategy's gaps are most likely to surface — but only if the session includes an actual restoration test rather than a restoration procedure walkthrough. A DR planning session that produces a runbook saying "restore from the latest backup using pg_restore" without executing that procedure against the current database size from the current backup location to the current restoration target environment produces a runbook whose accuracy is unknown. The session closes with the team having written a procedure they believe is correct, based on the restore working when tested against the 8GB development database or not having been tested at all. The incident response playbook decision record is the companion document specifying what happens in the moments before the restore is executed — the detection procedure, the escalation procedure, the communication procedure — and it is only useful if the restore procedure it references has been verified to work under realistic conditions. A DR plan that references an unverified backup is a document that describes a procedure, not a document that describes a tested capability.

The five sections of a database backup strategy decision record

The first section documents the backup frequency model and the RPO specification per data class. For each category of data in the database — user account data, financial transaction records, analytics event ingestion, audit logs, session state, configuration data — the specification must state the maximum acceptable data loss window (the RPO), the mechanism by which that RPO is achieved (snapshot backup at a specified interval, continuous WAL/binlog archiving with a specified archive shipping lag, or a combination of both), and the residual data loss window given the chosen mechanism (for snapshot-only: up to interval length; for PITR: up to archive shipping lag; for critical data classes, the shipping lag must be documented as a bounded number not a theoretical approximation). The justification must state why each data class received its RPO specification: "payment transaction records have a zero-additional-data-loss RPO because losing any transaction record creates a reconciliation gap that requires manual reconstruction; WAL archiving is enabled with archives shipped every 60 seconds to cross-account S3; the maximum data loss for payment records is the 60-second archive lag. Analytics event tables have a 24-hour RPO because events can be re-ingested from the Kafka topic retention window if the database data is lost; snapshot backup at 02:00 UTC is sufficient for analytics event tables." The snapshot backup schedule must specify the window (02:00 UTC to minimize overlap with peak write load), the expected duration at current database size, and the re-examination trigger (re-evaluate when database size grows to the point where the backup window overlaps the high-traffic window). The database migration decision record is the companion document specifying the schema migration procedure; the backup strategy must address the pre-migration backup requirement — a snapshot taken immediately before a schema migration that modifies data types or drops columns provides the restoration point if the migration produces data corruption, and the PITR archive enables recovery to a specific second before the migration transaction committed if WAL archiving is enabled.

The second section documents the backup storage isolation model. The specification must state the isolation tier in use (same-account, cross-account, cross-provider, or offline tape), the storage location for each backup type (RDS automated snapshots in account A; pg_dump output in a dedicated backup S3 bucket in account B with no cross-account role trust from account A), and the backup transfer credentials mechanism (the production environment uses an IAM role in account B with write-only permission to the backup bucket, scoped by condition to the specific bucket ARN; the IAM role is assumed via an STS AssumeRole call using a role whose ARN is stored in the secrets management system rather than using long-lived access keys). The specification must state the blast radius of the isolation model: "a compromised production account IAM credential cannot access backup account A because the production account has no roles with cross-account trust to account A; the backup IAM role in account B has write permission but not delete permission to the backup bucket; a compromised backup IAM role can write incorrect data to the backup bucket but cannot delete existing backup objects." The backup bucket must be configured with object lock in governance or compliance mode to prevent deletion of objects within the retention period, even by the bucket owner, as an additional protection layer. The specification must also address the restoration credentials: "restoration from account B's backup bucket requires credentials from account B; these credentials are stored in a break-glass envelope accessible to senior engineers; the restoration procedure is documented in the DR runbook with the credential retrieval step explicitly included, because a recovery scenario is also a potential credential compromise scenario and the break-glass procedure must be followed even under time pressure." The security scanning decision record specifies the configuration scanning schedule; backup storage bucket policies, encryption configuration, and object lock settings are scanned targets, and a misconfigured backup bucket (public access enabled, encryption disabled, object lock not configured) is a high-severity compliance finding.

The third section documents the backup verification model. The specification must state the verification cadence (monthly for standard production databases; weekly for databases with financial data or compliance requirements; nightly for high-criticality databases with frequent format or schema changes), the restoration target (account, environment, PostgreSQL or MySQL version, network path to backup storage), the verification procedure steps (transfer backup to target environment, execute restoration, confirm schema completeness against a reference schema list, confirm row counts for key tables against expected-range values, confirm sequence values are above the maximum primary key values in key tables, execute a set of application-level read queries that cover the most critical join paths and return to expected results, confirm that the restoration target application can start and process a test transaction end to end), the success criteria for each step, and the failure response procedure. The verification monitoring must specify the signals checked outside the restoration test cadence: daily backup output size comparison against the previous backup (delta should be positive and within expected bounds; a backup smaller than the previous backup by more than 10% triggers an alert unless a large deletion event is known to have occurred), backup file integrity check (read the first and last block of each backup file and confirm neither is zero bytes), and backup job duration tracking (a backup job that completes in 2 minutes when it usually takes 45 minutes is a signal of a silent failure worth investigating). The verification record must be stored outside the production environment (in the backup account or in a separate log store) so that a production account compromise does not allow falsification of verification records. The fourth section documents the point-in-time recovery model. The specification must state whether WAL archiving (PostgreSQL) or binary log archiving (MySQL/MariaDB) is enabled, where archives are shipped (storage location, isolation tier), the archive shipping interval and the maximum archive lag under nominal load, the archive retention period (how far back in time PITR can recover — this is independent of the snapshot retention period and must be at least as long as the longest RPO requirement in the data class specification), and the PITR invocation procedure (for PostgreSQL: the recovery.conf or recovery parameters, the WAL source location, the target timestamp specification; for MySQL: the binlog position or GTID specification, the binlog source location, the mysqlbinlog invocation). The PITR model must address the interaction with the snapshot backup: a full snapshot is the base restore point that PITR builds forward from; if the snapshot is 12 hours old and the incident is 11 hours after the snapshot, the recovery applies the snapshot and then replays 11 hours of WAL or binlog to reach the pre-incident state; the total restoration time is the snapshot restoration time plus the WAL replay time, which must fit within the RTO target.

The fifth section documents the restoration time analysis and the RTO consistency check. The specification must state the current database size, the measured restoration time from the current backup to a restoration target environment using the current network path and storage retrieval mechanism, and the calculation that shows whether the restoration time is within the disaster recovery RTO target. The measurement must be taken against the actual production database size, not against a development or staging database — restoration time scales with data volume, and a development database that restores in 5 minutes provides no useful information about whether a 2TB production database restores within a 4-hour RTO. The restoration time analysis must address each bottleneck independently: network transfer time from backup storage to the restoration target (determined by the backup file size and the network bandwidth between backup storage and the restoration environment); decompression and SQL replay time for pg_restore or mysqlbinlog (determined by CPU throughput and the number of indexes being rebuilt during restoration); index rebuild time after restoration (PostgreSQL and MySQL rebuild indexes during restoration; for large tables with many indexes, index rebuilding can exceed the data transfer time); and constraint validation time (foreign key constraints validated during restoration on large tables add significant duration). The re-evaluation trigger must be specified: the restoration time analysis must be re-run whenever the database size crosses a threshold that risks putting the restoration time outside the RTO target (for a 4-hour RTO with current restoration taking 2.5 hours, re-run the analysis when the database size grows by 50%). The new CTO onboarding problem is what happens when none of these properties are documented: the incoming technical leader finds a backup job that has been running for 18 months, a DR runbook that says "restore from the latest backup file," no record of when the restoration procedure was last tested, no specification of what RPO the backup frequency achieves, backup storage in the same account as the production database with the same IAM credentials, and an estimated restoration time that was accurate for the 40GB database at initial deployment but has not been re-measured since the database grew to 1.6TB. Each of these properties can be recovered from the AI sessions that configured the backup system, documented the DR runbook, and discussed the RPO requirements at the time those conversations happened. The decisions are in the sessions: "let's just put the backups in the same account, we can move them later," "the estimate is about 45 minutes based on what I saw in development," "a nightly backup should be sufficient for now." WhyChose's open-source extractor surfaces these founding infrastructure sessions, database provisioning sessions, and DR planning sessions as structured decision records before a ransomware event reveals that backup copies are stored in the same account as the database credentials used to authenticate the attack, an incident at 2 AM reveals that the restoration procedure has never been tested against the current database size, or a compliance audit reveals that the RPO specified in the compliance documentation cannot be achieved by a nightly backup schedule for financial transaction data.

The infrastructure setup session that enabled RDS automated backups with a 7-day retention period in the same account as the production database because cross-account storage "is something we can set up later"; the database provisioning session that added a payments table to the schema without re-examining whether nightly snapshots provided an adequate RPO for financial transaction records; and the DR planning session that wrote "restore from the latest backup" in the runbook without executing the procedure against the current 1.8TB production database from the current backup storage location each produced backup strategy decisions whose long-term recovery cost — a ransomware event that destroys both the production database and every backup snapshot using the same compromised IAM credentials, a 25-day data loss window caused by a silent backup failure that was never detected because no verification model existed, a compliance restoration test that fails because the restoration takes 11 hours against a 4-hour RTO target and the pg_dump format is not cross-version portable to the restoration target's PostgreSQL version — exceeds what a backup verification cadence with monthly restoration tests, a cross-account storage isolation model with object lock, and an RPO specification per data class matched to the actual backup frequency and PITR archive lag would have cost to specify at the time the founding decisions were made. The decisions are in the AI sessions: the backup configuration that "uses the same account because it is simpler," the retention period that "sounds like enough," the DR runbook that "describes the procedure without executing it." WhyChose's open-source extractor surfaces these founding infrastructure sessions, database provisioning sessions, and DR planning sessions as structured decision records before a silent backup failure goes undetected for weeks until a recovery event reveals that the most recent restorable backup is 25 days old, a ransomware event uses the same compromised credentials to delete both the database and the backup snapshots stored in the same account, or a compliance audit reveals that the restoration time for the current database size is nearly three times the RTO target documented in the compliance certification. The decisions never written down in a database backup deployment are the backup verification model with a tested restoration cadence, the RPO specification per data class matched to the backup frequency, the backup storage isolation model with its blast radius analysis, and the restoration time measurement taken against the actual database size — the four properties that together determine whether the backup infrastructure provides actual recovery capability or the appearance of recovery capability that will not survive its first real test.

Further reading