Only a Page Image Survives, with the Data Directory Lost?

Recover Data from a Page Image

Scenario Description

The original PGDATA and disk are unavailable; only a PDU page image and database DDL remain. The image cannot be started as a data directory or restored with pg_restore. Generate recovery resources from the definitions and extract data directly from the image.

Possible Causes

  • The failed media is unavailable, but a PDU page image was preserved.
  • The original directory is lost, but CREATE TABLE SQL survives.
  • Main-table and TOAST pages are mixed in one recovery image.

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

  • - Only source.pgiso, its sibling idx and schema evidence remain.
  • - The image cannot serve as a runnable PostgreSQL data directory.
  • - Some pages may use historical layouts or reference missing external values.

Why Traditional Methods Fail

  • - pg_restore handles supported logical backups rather than physical page images.
  • - Decoding with one definition may misattribute pages from other tables with the same layout.
  • - TOAST indexing and external-value backfill require separate status records.

PDU Solution

PDUPlan converts DDL into a recovery dictionary, which RecoverISO uses to parse the PDU page image. You can select the tables to recover, while matching still considers the full dictionary to avoid assigning another table's data to a selected table. Recovery also handles TOAST and records missing dependencies.

Recovery Principle

  1. Preserve Image and DDL
  2. Create PDUPlan
  3. Parse Pages and TOAST
  4. Save Recovery Results

PDU Core Capabilities

  • No original PGDATA or PostgreSQL process is required.
  • Parse DDL natively and preserve dictionary identity.
  • Select tables by complete identifiers.
  • Retain competition and ambiguity between matching layouts.
  • Handle and rescan TOAST within native recovery.
  • Save data, candidates and unresolved dependencies separately.

Recovery Steps

  1. 1

    Initialization

    Preserve the image, idx and original DDL, and prepare the matching PDU program in a separate working directory. There is no need to run b; against the original data directory or start PostgreSQL.

  2. 2

    Create PDUPlan from DDL

    PDU parses DDL natively and creates a binary recovery dictionary with version and identity information. Existing Plan and inspect output are not overwritten; use new filenames.

  3. 3

    Select Tables to Recover (Optional)

    Use a UTF-8 list without BOM, with one complete schema-qualified table name per line and the correct letter case. Even when a Plan selects one table, PDU checks for other matches in the full dictionary rather than assigning pages to the selected table automatically.

  4. 4

    Parse the Page Image

    Use the complete Plan when selection is unnecessary. Recovery mode is fixed in the Plan. Specify relaxed mode at creation rather than changing it during an existing task resume.

    Important: Mode and Definition Must Match

    Both strict and relaxed match tuples by their actual column count. relaxed can retain continuous historical prefixes allowed by current rules, but missing fields and historical layouts still need confirmation and are not complete current records.

  5. 5

    Restore TOAST Data

    RecoverISO handles TOAST and performs targeted rescanning in its native recovery process. Missing external values retain unresolved records. To supplement TOAST in an existing workspace, use the same image with the following command.

    Main-table identification, TOAST indexing and value backfill are separate stages. Record their native states separately rather than treating the completion of one as completion of the whole recovery.

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.

# Create PDUPlan from DDL

ds plan create /recovery-input/schema.sql /recovery-work/full.pduplan --mode=strict;
ds plan inspect /recovery-work/full.pduplan --format=tsv --output=/recovery-work/full.tsv;
ds plan check /recovery-work/full.pduplan;

# Select Tables to Recover (Optional)

ds plan select /recovery-work/full.pduplan /recovery-work/selected.pduplan --include-file=/recovery-input/tables.txt;
ds plan check /recovery-work/selected.pduplan;

# Parse the Page Image

ds recoveriso /recovery-input/source.pgiso /recovery-work/selected.pduplan;

# Restore TOAST Data

ds recoverisotoast /recovery-input/source.pgiso;

Export Results

Recovery Resources

.pduplan and inspect inventories, with original DDL and version identity retained.

Recovered Data

Exported CSV and recovery status are saved at the paths reported by PDU.

Unresolved Evidence

Missing fields, TOAST dependencies and attribution candidates are retained separately.

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

  • The image was produced by the PDU ds idx/isomode workflow, with logical page size matching the program. ISO here means a PDU page image.
  • Preserve complete DDL or a trusted .pduplan produced by a matching program. Also retain the sibling idx.
  • Use a separate working directory and valid license matching database type, major version and logical page size.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • ISO here means a PDU page image; a CD ISO or arbitrary image is not interchangeable.
  • Both strict and relaxed depend on actual layouts; a historical prefix is not a complete current record.
  • Finishing main-table identification or a TOAST rescan does not complete the entire recovery.
PostgreSQL 场景案例