Protect your data — back up a database with pg_dump, restore it with pg_restore or psql, capture roles and all databases with pg_dumpall, and understand when to reach for a physical base backup.
Why: pg_dump is the standard tool to snapshot a single database to a file while it stays online. Note: the custom format (-Fc) is compressed and lets you restore selectively, so it is the format to prefer for real backups.
Run from your terminal (not inside psql):
pg_dump -U postgres -Fc shop > shop.dumpWhy: pg_restore reads a custom-format dump back into a database. You usually create an empty database first, then restore into it. -j runs several jobs in parallel to restore large dumps faster.
Create a fresh database, then restore into it:
createdb -U postgres shop_restoredpg_restore -U postgres -d shop_restored -j 4 shop.dumpWhy: without -Fc, pg_dump writes a plain .sql file full of CREATE and INSERT statements — readable and portable. You restore it by feeding it back through psql like any other SQL script.
Dump to plain SQL, then restore by running the file:
pg_dump -U postgres shop > shop.sqlpsql -U postgres -d shop_restored -f shop.sqlWhy: pg_dump covers one database but not server-wide things like roles and passwords. pg_dumpall captures the whole cluster — all databases plus the global roles — which you need for a full server rebuild.
Dump everything, or just the global roles:
pg_dumpall -U postgres > full-cluster.sqlpg_dumpall -U postgres --globals-only > roles.sqlWhy: pg_dump backups are logical (they re-run SQL to rebuild data), which is slow to restore for very large databases. A physical base backup with pg_basebackup copies the actual data files, and is the foundation for point-in-time recovery and replica servers. Note: schedule whichever backup you choose, and test a restore regularly — an untested backup is not a backup.
Take a physical base backup of the whole cluster:
pg_basebackup -U postgres -D /backups/base -Ft -z -P