Table Files Are Lost, but Data Remains on Disk?
Recover Data from Disk Fragments
Scenario Description
Table files or directories were deleted, and ordinary file recovery did not restore complete files. PostgreSQL pages may still remain on disk. New writes can overwrite them. Protect the media first, preserve a page image, then analyze layouts, historical versions and attribution.
Possible Causes
- Data files were deleted and filesystem directory relationships are lost.
- Some old pages remain after DROP or TRUNCATE.
- The recovery image contains historical layouts or tables sharing a layout.
Challenges
Conventional recovery often requires complete files, a running instance or a usable backup. In these situations, choose a method based on the evidence that survives.
Common Errors and Symptoms
- - File paths no longer exist, but scans still find page candidates.
- - Pages lack reliable table attribution or retain only some fields.
- - External values, page chains or historical definitions are incomplete.
Why Traditional Methods Fail
- - Tools relying on filenames may miss surviving pages.
- - Parsing only with current DDL can miss historical layouts.
- - A decodable page establishes neither attribution nor record completeness.
PDU Solution
PDU saves pages in the specified range, then uses Probe or RecoverISO according to the files and table definitions available. Unresolved pages can be inspected and processed in a second recovery pass. Table ownership requires rules backed by source evidence. Ambiguity between tables with the same layout and missing content are still recorded.
Recovery Principle
- Protect Failed Media
- Preserve Page Image
- Parse by Schema
- Handle Unresolved Pages
PDU Core Capabilities
- Preserve pages within a declared scan range.
- Choose file identification and image recovery separately.
- Inspect selected pages, tuples and candidate layouts.
- Deepen unresolved-page recovery in a separate task.
- Use explicit attribution rules and retain their evidence.
- Distinguish complete records, historical prefixes and unresolved evidence.
Recovery Steps
- 1
Preserve the Disk Image Immediately
Use Probe when stable relation files are available. To preserve surviving pages from media, configure DISK_PATH, PGDATA_EXCLUDE and scan ranges as described in Protect the Recovery Scene, then run ds idx;. Image saving is enabled by default.
restore/.dsiso/pgiso stores the page image, and the sibling idx retains original disk offsets and continuous-page relationships. Preserve both. Scan completion means the selected range was processed, not that business data has been recovered.
- 2
Choose the Recovery Method
- Relation files survive with unknown mappings: use Probe/ProbeBatch.
- With existing configuration and indexes: use traditional DropScan ds iso, ds toast and ds copy paths.
- With only a page image and DDL: create PDUPlan and run RecoverISO.
- 3
Inspect Page and Tuple Evidence
When first-pass recovery has retained evidence, inspect pages, tuples and layout interpretations read-only. Replace example numbers with actual IDs from the current report, specifying tuple and plan together.
This command reads existing evidence without opening the image or exported CSV. Successful layout decoding does not establish table attribution.
- 4
Continue Historical Layout Analysis
Second-pass analysis uses a new workspace, reusing existing interpretations, then saved pages, and targeted image reads when needed. Continuous historical prefixes and multiple interpretations remain subject to confirmation without fabricated missing fields.
- 5
Resolve Attribution from Explicit Evidence
Prepare a rules file and execute --attribute only after attribution evidence has been explicitly reviewed. Rule format and source locations must match the current workspace. Identical table names, fields or similar counts do not replace business evidence.
The command reuses saved interpretations by location, retaining evidence and unknown states without automatic database import. Unattributed fragments and unresolved TOAST dependencies remain retained.
Quick Command Examples
Preserve frozen sources and launch PDU outside them. Write configuration snippets to pdu.ini and execute PDU commands after startup. Replace example paths, versions, times and task identities with actual evidence.
# Preserve the Disk Image Immediately
param isomode on;
ds idx;# Inspect Page and Tuple Evidence
ds recoveriso --inspect /recovery-work/first-pass --page=123;
ds recoveriso --inspect /recovery-work/first-pass --page=123 --tuple=1 --plan=2;# Continue Historical Layout Analysis
ds recoveriso --deepen /recovery-work/first-pass /recovery-work/second-pass --mode=relaxed;# Resolve Attribution from Explicit Evidence
ds recoveriso --attribute /recovery-work/first-pass /recovery-input/accepted-rules.tsv /recovery-work/attribution;Export Results
Page Evidence
Image, idx, source ranges and native scan records.
Recovered Data
Data recovered under confirmed definitions and native results.
Attribution and Missing Content
Candidates, historical layouts, attribution rules and unresolved dependencies.
After export, record PDU’s native success and failure counts and original errors, retaining checkpoints. Resume uses native records and file metadata without rereading exported data or automatic trial import.
Prerequisites
- Stop writes to affected media and store task state and recovered output in a safe location.
- Prepare matching definitions, version and page size. Overwritten or missing bytes cannot be recreated.
- Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.
Important Notes
- Overwritten bytes cannot be restored by scanning.
- A sample match or arbitrary page-size setting is not source-layout evidence.
- Deliver field fragments, historical prefixes and complete business records separately.