A restored PostgreSQL database opens successfully; what should we validate before cutover?

0 reputation · 10 Jan 2020, 13:39 UTC

139.9K views2

An example team restores a database containing user accounts, posts and a reputation ledger. Basic SQL queries work. They are about to switch the application but have only compared table counts. What additional checks would make the recovery decision more meaningful?

Environment

Editorial worked example. See the question for the scenario and assumptions.

1,672 following

Keep exploring this topic

Does Azure PostgreSQL point-in-time restore replace the original server?

In this fictional recovery exercise, an operator selects a point before an accidental data change. The team expects existing application connections to switch automatically when restore completes. The database is Azure PostgreSQL Flexible Server. What should the recovery runbook include?

The only Entra administrator cannot complete MFA; can a new account recover the tenant?

This original scenario reflects a general problem seen on Microsoft Q&A: the sole authorized tenant administrator loses access to the configured authentication method, and no other administrator can help. An employee suggests creating a new Microsoft account with a similar email address. Would that provide tenant authority?

S3 object downloads work, but listing the bucket returns AccessDenied

An example service can retrieve a known object key but cannot enumerate the same bucket. The role policy was written specifically for object reads, and the application recently added a directory-style browser. Does successful GetObject access imply that the list request should also work?

A rotated Key Vault secret is correct, but App Service still uses the previous value

A fictional application uses a Key Vault reference without a version in its URI. A new secret version has been created and is enabled. Requests from an authorized diagnostic client use the new value successfully, but the application behaves as if it has the old credential. Is this necessarily a permissions failure, and how should refresh behavior be checked?

Use the incident and application invariants to choose validation. Compare representative relationships, the records around the recovery timestamp and cached balances against the underlying ledger. Equal table counts can coexist with an incorrect restore point or inconsistent business state.

Exercise a representative read through the application against the isolated destination. Control test writes and disable side-effecting jobs. Confirm the intended runtime role can connect and perform allowed operations while retaining its permission limits. Define explicit evidence for cutover and a rollback decision before moving live traffic.

A restored PostgreSQL database opens successfully; what should we validate before cutover?

2 answers

Your perspective belongs here.

0 question comments

Good answers start here.