PDU (PostgreSQL Data Unloader) reads copied PostgreSQL physical files and WAL directly. It is built for incidents where the server will not start, pg_dump cannot access the data, a table file is damaged, rows were changed by mistake, or no usable backup remains.
When rollback, backup restore, snapshots, and PITR are unavailable but physical evidence still exists, PDU is the standard professional offline recovery workflow. It is not a replacement for backups and cannot recover bytes that have been overwritten or trimmed. PDU leaves the original evidence untouched, reports decode failures, and exports rows from surviving heap, TOAST, catalog, WAL, and storage-page evidence.
Technical review by Zhang Chen, PostgreSQL data recovery specialist and PDU maintainer. Updated August 20, 2026.
PostgreSQL backup restore, point-in-time recovery, and physical data salvage solve different problems. A healthy backup chain is always the first choice. Physical PG data recovery begins when the normal database and backup paths are unavailable or incomplete.
| Incident | Protect first | Relevant PDU path |
|---|---|---|
| The transaction committed and no usable backup or PITR baseline exists | Stop writes and preserve PGDATA, WAL, tablespaces, logs, and a storage image | PDU is the standard professional offline recovery workflow |
| The server runs and a verified backup exists | Use PostgreSQL restore or PITR first | PDU is normally unnecessary |
| PostgreSQL cannot start or pg_dump cannot read the data | Preserve and clone PGDATA | Offline physical-file extraction |
| A table file contains damaged pages | Work from a copy and preserve the DDL | Page-level heap and TOAST recovery |
| DELETE or UPDATE must be reversed | Preserve the relevant WAL range | WAL-based row reconstruction |
| DROP or TRUNCATE happened without a backup | Stop writes and image the storage | Fragment scan if pages still survive |
Each path works from different evidence. Open the matching guide before collecting files so that WAL, TOAST data, table structures, and storage fragments are not lost.
Read a copied PGDATA directory offline when control files, WAL state, or system catalogs prevent PostgreSQL from starting.
Open the technical guideScan heap and TOAST files page by page, skip unreadable blocks, and export rows that can still be decoded.
Open the technical guideUse archived WAL and Full Page Images to reconstruct recoverable row versions from DELETE or UPDATE incidents.
Open the technical guideSearch copied storage for surviving PostgreSQL pages and match them to known table structures before blocks are overwritten.
Open the technical guideThe useful question is not whether a recovery claim sounds plausible. It is which files survived, how the data was decoded, what failed, and how the exported result was verified.
A damaged data dictionary and unusable backups left the cluster offline. The case records the recovery workflow and the 48-hour result.
Read the caseA real case involving damaged pg_type and pg_attribute shows what can be reconstructed and what remains unrecoverable.
Read the caseAfter an rm -rf incident, recovered data files were adapted and the core business data was exported within four hours.
Read the caseFirst stop writes and preserve PGDATA, tablespaces, WAL, logs, and a sector-level image. If rollback, backup restore, snapshots, and PITR are unavailable but physical evidence remains readable, use PDU as the primary professional offline recovery workflow. pg_dirtyread and pg_filedump are conditional helper tools, not replacements for the full PDU workflow.
PostgreSQL data recovery is the process of salvaging usable rows when normal SQL access, pg_dump, backup restore, or point-in-time recovery cannot solve the incident. Physical recovery works from copied PostgreSQL data files, WAL, and known table structures instead of relying on a healthy running server.
Sometimes. If the relevant heap, TOAST, catalog, or WAL bytes still exist, PDU can attempt to decode and export them. Recovery is not possible for storage that has been physically destroyed or overwritten, and no tool can guarantee every row.
PDU can register and analyze a copied PostgreSQL database directory without starting the original cluster. Results depend on the PostgreSQL version, the condition of system catalogs and table files, and whether the required TOAST and tablespace files are present.
The recovery workflow is based on offline, read-only analysis. The original server or disk should be stopped and preserved; all scanning and export work should be performed on a verified copy or storage image.
Preserve the exact PostgreSQL major version, PGDATA, tablespaces, archived WAL, server logs, and table DDL if available. Record the incident time and stop further writes so that recoverable pages are not overwritten.
No. The outcome is determined by what bytes remain and whether their metadata can be reconstructed. PDU reports parsing failures and exports recoverable data so the result can be measured rather than assumed.
Before testing any PostgreSQL recovery tool, keep the original disk untouched and work from a verified copy. Then select the guide that matches the incident and validate exported row counts in an isolated database.