Back to Scenarios

Documents Deleted by Mistake?

Recover Deleted Records (Historical Candidates)

Scenario Description

An incorrect or missing deleteMany condition deleted documents. Unlike PostgreSQL WAL recovery, MongoDB requires surviving collection history, History Store or pre-images. PDU exports old-value candidates and evidence rather than treating every historical version as unique pre-incident data.

Possible Causes

  • A deleteMany condition was missing or too broad.
  • A batch job or application deleted documents by mistake.
  • No directly restorable backup matches the required point.

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

  • - Documents are missing, while a frozen copy may retain older versions.
  • - HS or pre-image evidence survives, with commit attribution requiring confirmation.
  • - Several physical old values may share an _id.

Why Traditional Methods Fail

  • - A current collection file does not guarantee that pre-delete documents survive.
  • - Historical candidate counts are not confirmed business-record counts.
  • - Missing commit states, base values or collection attribution affect interpretation.

PDU Solution

In history mode, PDU scans surviving historical files and records delete-type old values and their sources. Confirm the collection and candidate records before exporting the offline results. Pre-images linked to a known operation can be processed with their dedicated commands.

Recovery Principle

  1. Preserve Historical Evidence
  2. Scan Delete Old Values
  3. Confirm Candidate Evidence
  4. Export Offline Documents

PDU Core Capabilities

  • Distinguish delete and update recovery types.
  • Scan history for selected collections or databases.
  • Record old-value sources and physical versions.
  • Retain HS, collection history and pre-images separately.
  • Use proven oplog time evidence for operation ranges.
  • Export candidates without writing to the current collection automatically.

Recovery Steps

  1. 1

    Preserve the Data Files and Historical Sources

    Preserve copies of history store, pre-images and oplog that already exist at the incident. History-store values may have been reclaimed, and pre-images may have been disabled or expired. Old values that were not retained cannot be recreated.

  2. 2

    Configure pdu.ini

    Important Notice

    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.

  3. 3

    Start PDU and Execute Initialization

    Review collection bindings, historical sources and unresolved dependencies in catalog records. Create a new task for old catalog records rather than automatically upgrading source identity.

  4. 4

    Execute the Scan Command

    Use the corresponding command example below, replacing paths, objects and identity parameters with evidence from this run.

  5. 5

    Understanding the Scan Output

    Review sources, candidate versions and unresolved reasons in native records. Collection history, history store and pre-images retain separate records; their candidate counts are not a unique business-record count.

  6. 6

    Restore Data

    Use restore to export offline candidates for the target collection. The command does not connect to a running MongoDB server or automatically update a target collection.

    Important: Historical Versions Are Not a Business-Time Snapshot

    Historical files may contain several physical versions of a record. If a base value, modification chain, complete transaction or collection ownership cannot be confirmed, PDU saves the old values and records the cause. These candidates cannot be treated as complete pre-incident data.

  7. 7

    Filter by Operation Range

    When attributable pre-images and oplog remain available, limit the range by operation timestamp. operationfrom is inclusive and operationbefore is exclusive. Both use SECONDS:INCREMENT, not a business Date field or incident wall-clock time.

    Important: Operation Ranges Apply Only to the Pre-Image Path

    These parameters apply only to ds preimage. Reset both to none before ordinary scan, restore or other paths. Other paths reject active ranges rather than silently ignoring them. Retain candidates and reasons when transaction sources are incomplete or commit attribution is not unique.

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.

# Configure pdu.ini

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

# Start PDU and Execute Initialization

./pdu

param sourceversion 8.0.0;
param sourcekind copy;
param sourcefrozen true;
b;
ds catalog status;
\l;

# Execute the Scan Command

param resmode history;
param restype delete;
scan appdb.orders;

# Or scan the selected database:
scan db appdb;

# Understanding the Scan Output

ds catalog status;
ds batch status;
ds batch log;

# Restore Data

restore appdb.orders;

# Or export candidates for the selected database:
restore db appdb;

# Filter by Operation Range

param operationfrom 1700000000:1;
param operationbefore 1700000010:1;
ds preimage scan appdb.orders delete;
ds preimage unload appdb.orders delete;

# Filter by Operation Range

param operationfrom none;
param operationbefore none;

Export Results

Old-value Candidates

Keep complete values, physical versions and unresolved candidates separate without overwriting current collections.

Historical Evidence

Retain sources, collection relationships, transaction or operation times and candidate reasons.

Native Status

Record completed output, unfinished units, missing chains and checkpoints 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

  • Preserve the complete frozen dbPath and available WiredTigerHS.wt, pre-image and oplog sources.
  • Confirm collection, UUID and source relationships through matching directory metadata rather than guessing from filenames.
  • This procedure exports offline candidates. Confirm incident attribution and target writes 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

  • A deletion event alone cannot reconstruct a complete document without old-value evidence.
  • Historical physical versions are not a unique pre-incident snapshot; confirm commits and attribution.
  • After export, record native results without automatic deduplication, merging or trial import.
View Detailed Steps for This Recovery Method
MongoDB 场景案例