Database Restoration Test Report

Personnel: Emilian Roman, Infrastructure Lead Test Date: March 17th, 2026

Purpose

• Validate recovery of production data from an RDS snapshot into a secure environment.
• Verify application behaviour after restore and migration.
• Exercise cross-VPC and cross-region data handling beyond baseline AWS RDS workflows.

Scope and Data Handling

• Source: production RDS snapshot restored to a temporary, isolated RDS instance; accessible only from a single authorised IP.
• Transfer path: pg_dump from the secure target environment, then, pg_restore into the target database.
• Target: ephemeral, air-gapped instance of the core stack with isolated networking and no external integrations enabled.
• Data protection: encryption at rest; temporary storage wiped after validation; no long-lived persistence outside approved locations.

Procedure

1. Restore the selected RDS snapshot to a temporary RDS instance in the source region.
2. Run pg_dump from the authorised, secure enclave, verify integrity on arrival.
3. Provision a fresh PostgreSQL instance inside the enclave and run pg_restore.
4. Boot the core stack in the air-gapped enclave pointing at the restored database.
5. Monitor database migrations via the standard migration logs to reach the current schema head.
6. Start application services and perform basic connectivity checks against the restored database.

Results

• pg_dump over-the-air transfer completed without errors; checksum and size verified end to end.
• pg_restore succeeded; database has run successfully with no data-related errors from PostgreSQL.
• Migrations applied cleanly; no pending or failed migration entries remained afterward.
• Core application services connected successfully to the restored database in the air-gapped environment.
• Temporary artifacts were deleted after validation; no residual data outside approved locations.

Evidence Collected

• Migration logs showing successful application through the latest migration ID.
• Application logs showing successful health checks on a continued basis.
• Application logs showing successful database operations on a continued basis.

Follow-ups

• Schedule a recurring (e.g., quarterly) restore-and-validate exercise to keep the runbook fresh.
• Automate checksum verification and row/object parity checks with a brief report artifact.
• Add synthetic user journeys to the validation phase to increase end-to-end confidence.