Section 3 of 3 · 7 minutes

Validate the restored service before cutover

Your goal

What you will be able to do

Prove the damaging change is absent and required good work, access, and application behaviour are present.

Why this matters at work

The practical reason

A technically completed replay can still stop at the wrong point or produce an unusable service.

Learn

The idea in plain English

Check the specific damaged rows first, then broader business totals, constraints, roles, extensions, and application queries. Record the exact replay stop point.

Plan cutover, DNS or connection changes, lost-write handling, and a rollback route separately. Do not promote the restored service merely because PostgreSQL started.

Remember these points

Prove the unwanted change is absent.
Prove required earlier data and application access still work.
Treat cutover as a separate controlled change.

See it in SQL

Check the seeded recovery boundary

Confirm the unwanted audit event is absent while the last approved event remains.

SELECT
  max(event_id) FILTER (WHERE event_status = 'approved') AS latest_approved_event,
  count(*) FILTER (WHERE event_status = 'accidental_delete') AS damaging_event_count
FROM training_recovery_events;

The damaging count should be zero at the chosen target. The approved event identifier should match the written recovery expectation.

Add application-level checks before cutover; one table cannot prove the whole service is ready.

What you should see

The expected latest approved event and zero replayed damaging events.

Useful words

Important terms

Cutover: The controlled change that directs users or applications to the restored service.

Quick check · Not graded

Check your understanding

What is required before promoting a restored service?

Choose one answerOnly a successful PostgreSQL process start.Only confirmation that the backup file exists.Data, application, access, recovery-target, and cutover checks must all pass.

Your progress is saved to your signed-in account.