Why is PDU Designed
Hardware failures, accidental operations and software faults can leave PostgreSQL unable to start, with no usable backup. PDU reads the files and logs that remain to look for recoverable data.
The Reality of PostgreSQL Disasters
The following incidents require different recovery methods:
Scenario 1: Complete Database Corruption
The database integrity is completely corrupted. PostgreSQL cannot start. Error logs show checksum failures, missing files, or corrupted system catalogs.
Scenario 2: Accidental Data Modification
A developer runs an UPDATE or DELETE without a proper WHERE clause. Millions of records are modified or deleted in production.
Scenario 3: Data File Loss
Storage failure, accidental file deletion, or filesystem corruption causes data files to become inaccessible or damaged.
Scenario 4: DROP TABLE Without Backup
A critical table has been dropped, and no recent backup is available. Recovery now depends on whether usable data pages remain on disk.
Limitations of Traditional Recovery Methods
PITR (Point-in-Time Recovery)
Requires Complete Backup Chain
- • PITR requires a base backup plus all WAL files from that point forward
- • If any WAL file is missing, recovery stops at that point
- • Recovery time can take hours for large databases
- • Cannot recover if base backup is corrupted
Existing Recovery Tools
Fragmented Toolset
| Tool | Purpose | Limitation |
|---|---|---|
| pg_filedump | Dump data file contents | Requires table structure knowledge |
| pg_dirtyread | Read dead tuples | Database must be running |
| pg_resetwal | Reset WAL state | May cause data loss |
| pg_waldump | Inspect WAL contents | Read-only, no recovery |
The Expertise Barrier
Deep Kernel Knowledge Required
- • Understanding PostgreSQL's internal data page format
- • Knowledge of system catalog structure and relationships
- • WAL record format and transaction processing internals
- • TOAST storage mechanism and chunk reconstruction
- • Different behaviors across PostgreSQL major versions
The DROP TABLE Problem
The 'Impossible' Recovery Scenario
When a table is dropped in PostgreSQL:
- The data files are immediately unlinked from the filesystem
- The table's metadata is removed from system catalogs
- The space is marked as available for reuse
- Traditional tools have no way to access or reconstruct the data
This was considered an unrecoverable scenario—until PDU.
PDU: The Solution
PDU provides file extraction, WAL parsing and fragment scanning for these incidents. Choose a method based on the files, logs and table structures you still have.
Continue to the Core Mission page to see exactly what PDU can do for your PostgreSQL disaster recovery needs.