Back to Scenarios

Metadata Damaged and Collection Mappings Lost?

Recover Metadata Relationships and Log Prefixes

Scenario Description

Collection files survive, but damaged metadata prevents complete namespace, UUID and ident mapping. WT journal may also survive after a checkpoint. Relationship salvage and log replay are separate paths requiring retained sources and rejection reasons.

Possible Causes

  • Catalog or independent metadata relationships are partially damaged.
  • Collection recreation, rename or ident conflicts occurred.
  • Journal survives after a checkpoint, but log continuity needs confirmation.

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

  • - Files exist, but business collection attribution is incomplete.
  • - namespace/UUID/ident have multiple candidates.
  • - Log chains, file IDs or checkpoint LSNs may be missing.

Why Traditional Methods Fail

  • - Names or _id values cannot establish relationships across generations.
  • - Independent relationships do not replace a readable turtle root.
  • - Damaged logs cannot be handled by partially applying a commit.

PDU Solution

PDU records confirmed metadata relationships and conflicts, then uses catalog salvage to export qualifying candidates. Journal replay uses the original file IDs, checkpoint LSNs and continuous prev-LSN prefixes to build a read-only overlay. If a commit is damaged, none of that commit is applied.

Recovery Principle

  1. Preserve Metadata and Logs
  2. Confirm Relationships or Continuous Chain
  3. Build Read-only View
  4. Export Confirmed Candidates

PDU Core Capabilities

  • Save metadata candidates and conflicts separately.
  • Do not merge recreation and rename evidence automatically.
  • Read WT log-v5 with the declared compressor.
  • Bind log targets by original file ID.
  • Build a read-only overlay from a continuous prev-LSN prefix.
  • Reject damaged commits and unknown-range operations.

Recovery Steps

  1. 1

    Initialization

    Use a new launch directory for metadata salvage, retaining original sources and existing tasks.

  2. 2

    Read Independent Metadata Relationships

    Matching ns/ident/UUID and a unique WT file definition can establish independent_relation. Missing WT metadata or catalog still permits independent physical-document candidates with unknown attribution. Relationship evidence is not Turtle-root reconstruction or proof of complete incident-time business state.

  3. 3

    Process Original WT Logs

    Clear target time first and match the codec to the original logs. Use original metadata file IDs, object generations, checkpoint LSN and continuous prev-LSN chains to select a complete commit prefix and build a read-only overlay. This procedure does not start mongod, run repair, modify sources or import into a target database.

  4. 4

    Handle Missing Dependencies

    Do not apply damaged commits, and stop when sequence continuity cannot be proved. row_modify requires a complete original base and explicit ABI. Retain limits for range truncate, encrypted logs, missing dictionaries and unknown operations. Record same-name/different-UUID, same-UUID/multiple-name and generation conflicts separately without filename-based guesses.

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.

# Initialization

MONGODBDATA=/recovery-input/mongodb/source/dbpath

# Initialization

param sourceversion 8.0.0;
param sourcekind copy;
param sourcefrozen true;

# Read Independent Metadata Relationships

param catalogsalvage true;
ds recovery idx;
ds recovery candidates;
ds recovery unload appdb.orders;

# Process Original WT Logs

param recoveryat none;
param recoverytime none;
param journalcompressor snappy;
ds journal idx;
ds journal status;
ds journal replay appdb.orders;

Export Results

Recovered Documents

BSON or the selected data format at paths reported by the program.

Sources and Attribution

Retain namespace/UUID, source positions and candidate states; unresolved attribution stays unknown.

Tasks and Dependencies

The launch directory retains native tasks, checkpoints and original reasons for missing pages or overflow.

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

  • This documentation applies to Linux and source versions MongoDB 6.0.0, 7.0.0 and 8.0.0. Freeze source copies and launch PDU from a directory outside the sources. State and output use the launch directory without separate path settings. Confirm other versions and special layouts separately.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • Independent relationship salvage does not reconstruct a WiredTiger.turtle root.
  • row_modify needs matching base records and ABI; unknown-range truncate is not performed.
  • Missing dictionaries, keys, continuity or bindings prevent a complete-replay claim.
View Detailed Steps for This Recovery Method
MongoDB 场景案例