Section 2 of 3 · 7 minutes

Prepare the complete recovery chain

Your goal

What you will be able to do

Confirm the base backup, required WAL, recovery settings, capacity, and credentials before starting replay.

Why this matters at work

The practical reason

Recovery can stop short when one WAL segment, key, extension, or storage dependency is missing.

Learn

The idea in plain English

Select a base backup old enough to precede the target. Confirm every WAL segment from that backup to the target is available and readable.

Prepare recovery configuration, restore command, encryption keys, PostgreSQL version, extensions, disk space, and the rule that stops replay. Record how to abandon the attempt without affecting the source.

Remember these points

The base backup must begin before the target.
Every required WAL segment must be readable in order.
Version, extensions, keys, and storage are part of the recovery chain.

See it in SQL

Read recovery state

Check whether the current server is in recovery and how far replay has reached.

SELECT
  pg_is_in_recovery() AS is_in_recovery,
  pg_last_wal_replay_lsn() AS last_replayed_wal_position,
  pg_last_xact_replay_timestamp() AS last_replayed_transaction_time;

On a primary that is not in recovery, replay fields may be null. On a restoring or standby server, they show replay progress.

Compare replay time and WAL position with the written target before promotion.

What you should see

Recovery state plus the latest replayed WAL position and transaction timestamp when available.

Useful words

Important terms

WAL replay: Applying recorded WAL changes to rebuild database state during recovery or replication.

Quick check · Not graded

Check your understanding

What happens if one required WAL segment is missing?

Choose one answerPostgreSQL invents the missing changes from table names.Recovery cannot continue through that gap to the later target.The gap affects only client formatting.

Your progress is saved to your signed-in account.