Use this page to restore data from one Ethernity backup set at a time.

For most restores:

1. Use --scan against the generated backup directory or clean scan exports.
2. Add shard or auth inputs only from the same backup set.
3. Write recovered output to disk.
4. Compare it with a trusted reference if you have one.

If scan quality is poor, switch to --fallback-file. If you already have exported payload lines, use --payloads-file.

Use one backup set only for each run.

If the root has been extended:

• plain recover --scan ./backup-root ... restores the latest validated logical state
• --extension-index 0 stops at the root only
• --extension-index N restores through a specific extension generation
• --extension-doc-hash <hex> restores through the generation with that authenticated hash

Only use those selectors when you have a reason to target an older state. For normal recovery, use the latest state and validate the result.

If you are looking for the write-side lifecycle, use Extension Workflow.

Recover from a backup directory:

ethernity recover \
  --scan ./backup-demo \
  --passphrase "example passphrase" \
  --output ./restored.bin

Recover from fallback text:

ethernity recover \
  --fallback-file ./recovery_fallback.txt \
  --passphrase "example passphrase" \
  --output ./restored.bin

Recover with shard inputs:

ethernity recover \
  --scan ./backup-demo \
  --shard-scan ./shard-01.pdf \
  --shard-scan ./shard-02.pdf \
  --output ./restored.bin

--rescue-mode is an explicit bypass for cases where normal authentication verification cannot be satisfied.

Use it only when all of the following are true:

• normal recovery is blocked by trust verification
• the incident context is documented
• operator approval is explicit
• recovered output will be validated independently

If you do not have a documented reason to use rescue mode, stop and resolve the trust problem first.

• Extension Workflow
• Recovery Incident Runbook
• Recovery Kit
• Troubleshooting
• Security and Trust Model