Back to Scenarios

Current Documents Are Gone, but Older Versions Survive in History Store?

Recover Old Versions from History Store

Scenario Description

Old values have disappeared from the current collection, but a frozen copy retains WiredTigerHS.wt. History Store may contain older versions or MODIFY chains. Assess recoverable scope using catalogs, source ABI, base values and commit evidence.

Possible Causes

  • Target documents were deleted or updated.
  • The copy retains HS history records.
  • Historical blocks, base values or modification chains are partially missing.

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

  • - The HS file is readable but cannot be queried as a normal collection.
  • - Records contain complete old values or MODIFY deltas.
  • - Sources report PARTIAL or UNRESOLVED states.

Why Traditional Methods Fail

  • - HS physical records need original collection bindings.
  • - MODIFY depends on a correct base and complete chain.
  • - Record counts cannot determine missing-document counts in damaged sources.

PDU Solution

PDU's HS commands scan old values and modification chains, record their file sources and export candidates by collection or database. Complete values and unresolved content are saved separately. File damage is recorded and is not counted as a successful recovery.

Recovery Principle

  1. Preserve HS and Catalog
  2. Confirm Source ABI
  3. Scan Historical Chains
  4. Export Old-value Candidates

PDU Core Capabilities

  • Dedicated ds hs scan and unload commands.
  • Select collection or database scopes.
  • Retain complete old values and MODIFY dependencies.
  • Declare source ABI from actual evidence.
  • Save PARTIAL/UNRESOLVED reasons.
  • Decide how to handle unfinished output units before continuing.

Recovery Steps

  1. 1

    Initialization

    Create new tasks for old-schema cases rather than rereading sources to upgrade indexes during resume.

  2. 2

    Scan History Store

    Complete STANDARD old values can be extracted directly. MODIFY requires a newer base for the same record and a complete modification chain. Reverse modification requires an explicit source ABI declaration.

    Important: Base Values and Modification Chains Must Be Complete

    Retain unresolved reasons for unknown ABI, missing bases or missing intermediate MODIFY versions without guessed values. Establish le64 from source evidence rather than assuming it from the example.

  3. 3

    Export Old Versions

    delete/update filtering depends on operation evidence established by the selected path. Historical documents can survive missing collection sources while operation classification remains unproven. Physical-version counts are not unique business-record counts.

  4. 4

    Handle Partial Page Loss

    Independent branches confirmed by valid parent references can continue recovery. Versions missing bases or intermediate chains remain UNRESOLVED, and version counts inside missing pages remain unknown. HS_SOURCE_PARTIAL means partial sources, not complete success.

  5. 5

    Continue the Recovery Task

    Keep the original case and repeat the original command. Use discard-active only after deciding to abandon an unfinished output unit. Keep the namespace and filter type unchanged.

    Retain native success, failure, unresolved dependencies, original errors and checkpoints. Completed-run resume reads native records and file metadata without checking exported content for counts, JSON, UTF-8, hashes, redecoding or trial import.

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 resmode history;

# Initialization

b;
ds catalog status;
use appdb;

# Scan History Store

ds hs scan appdb.orders;

# Or select a database:
ds hs scan db appdb;

# Scan History Store

param hssourceabi le64;

# Export Old Versions

ds hs unload appdb.orders;
ds hs unload db appdb update;

# Continue the Recovery Task

ds hs discard-active appdb.orders update;

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, collection identity, WiredTigerHS.wt and available base values without merging same-named files from other instances.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • The example le64 is not a default ABI for every source; actual evidence is required.
  • MODIFY without a base or chain does not produce a complete value.
  • History Store candidates do not automatically establish a committed pre-incident state.
View Detailed Steps for This Recovery Method
MongoDB 场景案例