How to back up a PostgreSQL database on Linux (pg_dump + restic)

There are two broad ways to back up PostgreSQL. A logical backup exports database objects as SQL or an archive. It is portable across architectures, supports selective restore in archive formats, and is generally suited to moving forward to a newer PostgreSQL version. The exact source-to-target version and installed extensions still need testing.

A physical backup copies the PostgreSQL cluster in a database-consistent way and is the basis for point-in-time recovery when combined with continuous write-ahead log archiving. For many small single-server applications, scheduled logical dumps are a manageable starting point; tighter recovery-point targets may require the physical route.

pg_dump creates a consistent export even while normal readers and writers continue to use the database. A custom-format archive is compressed by default and supports flexible, selective recovery through pg_restore.

Credential handling, client-server version compatibility, timeouts, and partial-output cleanup belong to the backup job. A command that works once in an interactive shell is not yet safe automation.

One pg_dump covers one database, not cluster-wide roles and tablespaces. Inventory those dependencies and decide whether to export them with PostgreSQL tooling or recreate them from controlled configuration. Extensions need the right package and compatible version on the recovery target before their objects can be restored.

Ownership and privileges are part of application behavior. A restore that contains every table can still fail at runtime when the service account no longer owns a sequence or lacks permission on a schema. Add authentication and representative application queries to the acceptance check.

A dump left on the same server as the database does not help if the disk fails, the host is compromised, or someone drops the wrong table. Copy it to storage you control, encrypted, and keep previous versions. restic encrypts on the client, deduplicates, and retains each snapshot.

A complete scheduled job creates a consistent dump, publishes it only after success, encrypts it off-host, applies retention without overlapping other repository work, and reports both failure and absence.

Retention should reflect how long deletion or corruption can go unnoticed. Monitoring must live outside the database host so a failed machine cannot silence the same signal intended to report it.

A backup that has never been restored is not proven. Periodically restore into a scratch database and check that the data is intact, and note how long it takes so your recovery estimate reflects a real run.

Validate schema, extensions, ownership expectations, representative row counts, and application behavior. Production replacement should be a separate reviewed step after the rehearsal passes.

Use a PostgreSQL target at the intended recovery version and retain the restore logs. Warnings about missing roles, ownership, extensions, or unsupported settings are evidence to resolve, not cosmetic noise. Repeat the test after major database or extension upgrades.

Rested coordinates database-aware runs, protected user-owned storage, retention, multi-server visibility, failure history, and guided recovery without requiring teams to maintain per-host scheduler glue. Docker and network PostgreSQL sources are supported.