Restore Operations
Pigsty provides three restore entry points. They share the same parameter semantics, but serve different scopes:
| Entry point | Use case | What it controls |
|---|---|---|
pgsql-pitr.yml |
Production cluster recovery | HA pause, multiple nodes, etcd cleanup, restore, and restart |
pig pitr |
A local database node | Single-instance orchestration without the admin node |
pig pb restore |
An instance not managed by Patroni | A direct pgBackRest restore wrapper |
For a hands-on sandbox drill, see Manual Recovery. To recover into another cluster without changing production, see Clone a PG Cluster.
pgsql-pitr.yml pauses HA, stops Patroni/PostgreSQL, overwrites the target data directory with pgbackrest --force restore,
then deletes the target cluster’s etcd prefix and rebuilds HA. It prints a plan but does not wait for confirmation.
Before any real restore, inspect the topology with pig pg list <target-cluster>, verify a recent usable backup and recovery window with pig pb info,
and have the operator state and confirm the exact target cluster and recovery point. Schedule a maintenance window and retain an independently verified backup for production recovery.
Quick Start
To roll pg-meta back to an earlier time, declare pg_pitr:
Run the same target through the safety gate before executing it:
You can pass the same object temporarily on the command line:
The -e value must be valid JSON: quote keys and string values, for example {"pg_pitr": {"time": "...", "archive": true}}.
Booleans are not quoted. Invalid quoting can fail parsing or silently produce the wrong value.
The playbook pauses Patroni HA, stops the cluster, performs a delta pgBackRest restore, starts PostgreSQL and waits for a consistent recovery state,
prints control data, removes old etcd metadata, and starts the cluster under Patroni again.
It prints the source, target, and restore command first, but has no interactive approval gate. A one-shot targeted recovery should therefore declare action: promote explicitly.
To inspect data at the target, use step-by-step execution with action: pause.
Recovery Targets
pg_pitr supports six recovery target forms. The four target values are mutually exclusive.
Recovery target types
With no target, recovery replays all archived WAL to the latest available state (Pigsty’s internal type is default).
immediate stops at the first consistent point, which is useful for obtaining a usable instance as quickly as possible or testing a backup.
Recover by Time
Use a valid PostgreSQL TIMESTAMP; an explicit time zone is strongly recommended:
Recover by Name
Create an unambiguous marker before a risky change with pg_create_restore_point:
Recover by Transaction ID
If the offending transaction ID is known from monitoring or CSVLOG’s TXID field, use exclusive to stop before that transaction:
Recover by LSN
An LSN identifies a position in the WAL stream. It is also visible in Pigsty’s PG LSN dashboard panel.
Set timeline when the desired position is on a particular timeline; the default is latest.
Targets are inclusive by default, so the target transaction is replayed. exclusive: true excludes the exact target.
It applies only to time, xid, and lsn, and maps to PostgreSQL’s recovery_target_inclusive.
Recovery Source
Recovery uses the target cluster’s own backup by default. Three fields can select another source:
cluster: the source stanza, including another cluster in a shared repositoryrepo: a temporary repository definition in the same format as apgbackrest_repoentryset: a specific backup label; otherwise pgBackRest selects a suitable set
For example, recover pg-meta2 from pg-meta:
Step-by-Step Execution
In an incident, use tags to retain an explicit human gate between stages. After confirming the backup, recovery point, and exact target, run the stages in order:
After down, confirm the processes are stopped. After pitr, inspect /pg/tmp/recovery.log and query the recovery state before checking narrowly authorized business data.
pg_controldata /pg/data reports checkpoint and timeline metadata; it does not by itself prove that a time, XID, or LSN target was reached.
With action: pause, promote only after validation, then run up. If the target is wrong, adjust pg_pitr and repeat pitr before up.
pause or shutdown creates a meaningful human gate only in this staged workflow; use action: promote explicitly for one-shot targeted recovery.
With backup: true, the playbook moves the current data directory to /pg/data-backup, but deletes any existing /pg/data-backup before doing so.
The staged workflow is supported; a restore using backup: true is not generally idempotent.
PITR Parameter Definition
Declare the target, action, and treatment of existing data explicitly:
See Parameter Mapping for the corresponding pgBackRest options.
Single Instance: pig pitr
pig pitr performs a local-node workflow without Ansible: validate the target, stanza, and backup; stop Patroni/PostgreSQL; restore; optionally start PostgreSQL; and print follow-up guidance.
Use -b/--set for a backup set, -T/--target-timeline for a timeline, --target-action for the post-target action,
and -D/--data with --no-restart for a side restore. The command normally attempts a fast stop and aborts if that fails;
only explicit --force-stop permits immediate shutdown and a kill fallback.
For managed PGDATA it leaves Patroni stopped. Validate the instance before pig pt start.
It does not remove etcd metadata, rebuild replicas, or rejoin the instance to an HA cluster.
Primitive: pig pb restore
For an instance not managed by Patroni (or one deliberately taken out of management), pig pb restore directly wraps pgbackrest restore.
It validates the environment, requires PostgreSQL to be stopped, displays the plan, and asks for confirmation.
It rejects a live Patroni-managed target because Patroni could restart a half-restored instance, and it rejects any running PostgreSQL target.
Arguments after --, such as --tablespace-map or --link-all, pass through to pgBackRest, but wrapped options such as target, stanza, and repository cannot be overridden there.
Post-Recovery
After restore:
-
Verify the recovery state and the smallest authorized set of application checks.
-
After a cross-cluster clone, complete stanza cleanup. Create a full backup on the new timeline as soon as practical:
-
If exploratory recovery used
archive: false, restore archiving. Becausearchive_modeis a postmaster setting, first confirm the maintenance window, current primary, and replication state, then obtain explicit approval for the restart: