Backup, Restore, and Recovery
Logical versus physical
Logical backups (pg_dump, pg_dumpall, COPY) are portable across versions and architectures but slow, and they cannot perform point-in-time recovery. Physical backups copy data files (pg_basebackup, filesystem snapshots) and, combined with archived WAL, deliver full PITR.
The pg_dump family
pg_dump dumps one database consistently from a single transaction snapshot; it does not include roles or tablespace definitions - pg_dumpall --globals-only covers those. Formats: plain SQL (-Fp, restore with psql), custom (-Fc, restore with pg_restore, supports -j parallelism and selective -t), directory (-Fd, parallel dump), and tar. --create emits CREATE DATABASE; --clean emits drops first.
PITR
Set wal_level=replica, archive_mode=on and an archive_command, take a base backup, then restore that backup plus archived WAL into PGDATA, create an empty recovery.signal file, and set restore_command with a target: recovery_target_time, recovery_target_xid, recovery_target_lsn, or recovery_target_name (a named restore point). Default recovery_target_action is pause. Since v12 recovery.conf no longer exists - parameters live in postgresql.conf and recovery.signal / standby.signal select the mode.
Traps
A pg_dump cannot recover to a moment in time. You cannot recover to a target earlier than the base backup start point. pg_restore without -d only prints the archive contents.
Rule of thumb
Back up globals separately from databases, and rehearse the restore - an untested backup is a hope, not a backup.