Keep raw PostgreSQL table files out of selective recovery plans

Use a database recovery path instead of replacing raw relation files to recover one PostgreSQL table.

Source facts

PostgreSQL 17 documentation explains why an individual table’s raw files cannot be restored as a standalone database backup. Their interpretation depends on transaction commit-status files in pg_xact. Restoring a table together with only selected commit-status data is not a solution, because that would invalidate the other tables in the cluster. Filesystem-level backup and restoration therefore operate on the complete cluster. An ordinary file-copy backup also requires the server to be stopped; blocking new connections alone is insufficient.

Source: PostgreSQL 17 — File System Level Backup.

Applicability

This applies to PostgreSQL 17 filesystem-level recovery boundaries. It addresses the temptation to replace raw relation files, rather than selection and dependency handling within a logical pg_restore archive.

DSE recommendation

DSE recommends routing a request for one missing table through the database recovery owner before any filesystem replacement is attempted. Preserve the original cluster and its recovery artifacts, and identify whether a suitable logical archive or isolated complete-cluster recovery can supply the required records. Keep raw storage filenames out of instructions for a general helpdesk file restore. Require an application-level transfer plan for approved recovered data, with ownership and consistency checks suited to the request.

Verification

Rehearse the chosen recovery method on an isolated complete cluster or supported logical archive. Confirm the requested table and its relationships before exporting approved data. Retain the recovery point, transfer method, and application acceptance evidence; do not experiment by replacing relation or commit-status files in a live cluster.

Official reference

PostgreSQL 17 — File System Level Backup. Reviewed October 15, 2026.