Back to Scenarios

Need Documents at a Point Before the Incident?

Recover Data at an Incident Time

Scenario Description

A document set at a definite point before the incident is needed, including changed and unchanged records. Recovery requires matching checkpoint, HS, commit closure and collection relationships, then version selection using evidenced logical time or a unique commit boundary.

Possible Causes

  • A pre-incident state is needed rather than several old values.
  • Related checkpoint, history and oplog evidence survives.
  • Recreation or transaction state affects point selection.

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

  • - Several versions decode, but only some are visible at the target point.
  • - Stable/oldest ranges and commit evidence are required.
  • - Wall-clock selection must match a unique original commit boundary.

Why Traditional Methods Fail

  • - A business BSON Date cannot replace commit time for recovery.
  • - Arbitrary time interpolation cannot establish document visibility.
  • - prepare, abort and unknown states are not confirmed commits.

PDU Solution

PDU collects candidate versions and commit records. Select the target using recoveryat logical time or a wall-clock time that exactly matches one unique commit in the original oplog. Export snapshot candidates, including unchanged records that meet the rules. PDU records why other versions remain unresolved.

Recovery Principle

  1. Build Recovery Candidates
  2. Confirm Commit Boundary
  3. Select Target Point
  4. Export Snapshot Candidates

PDU Core Capabilities

  • Inspect candidates, sources and native state.
  • Support explicit logical-time selection.
  • Match an exact unique wall-clock commit boundary.
  • Check stable/oldest ranges and historical-chain dependencies.
  • Export changed old values separately from snapshots including unchanged records.
  • Keep unknown commit states unresolved.

Recovery Steps

  1. 1

    Initialization

    Retain checkpoint relationships, collection generations, time evidence and unresolved reasons. Do not generate guessed values when bases, complete modification chains or transaction-terminal evidence are missing.

  2. 2

    Set Recovery Time

    recoveryat uses source MongoDB logical time. recoverytime requires Z or an explicit time zone and must match exactly one original oplog commit boundary. The parameters are mutually exclusive. Replace example times with original evidence.

    Important: Time Boundaries

    Do not treat business BSON dates as commit time or interpolate wall-clock values. prepare and abort are not committed states. Missing terminal chains or durable evidence retain unknown status.

  3. 3

    Restore Data

    scan and restore select deletion or update candidates by RESTYPE. ds recovery unload exports complete time-snapshot candidates including unchanged records. Recovery generates offline files without writing to a target database.

  4. 4

    Handle Unrecoverable Content

    Retain explicit errors when the target is outside the evidenced oldest/stable interval, values were reclaimed, modify chains are incomplete or wall-clock boundaries are nonunique. Complete replica-set oplog business replay after a checkpoint is not performed, and candidate counts do not establish complete business state.

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;
param hssourceabi le64;
ds recovery idx;
ds recovery status;
ds recovery candidates;

# Set Recovery Time

param recoveryat 1700000000:1;

# Or use an exact recorded wall-clock commit boundary:
param recoveryat none;
param recoverytime 2026-10-04T10:00:00Z;

# Restore Data

param restype update;
scan appdb.orders;
restore appdb.orders;

# Export the complete selected snapshot, including unchanged records:
ds recovery unload appdb.orders;

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

  • 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.
  • Preserve matching catalog, UUID, checkpoint, History Store and original oplog. The target must lie within an evidenced historical interval.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • Do not interpolate arbitrary times lacking a matching unique commit boundary.
  • Complete business-oplog replay after a checkpoint is outside this path.
  • Missing relationships, historical chains or transaction closure prevent a complete business-snapshot claim.
View Detailed Steps for This Recovery Method
MongoDB 场景案例