-
Notifications
You must be signed in to change notification settings - Fork 2
FAQ
Ethernity backups/recovery artifacts follow the baseline contract in the format docs and are expected to remain backward compatible across future stable releases.
In plain terms: backups you create now should keep working across future stable updates.
Not always. The primary recovery path is through CLI decode/recover using scan or fallback inputs. The browser recovery kit is an optional helper, especially useful in constrained environments.
Rescue mode is an explicit bypass path for recovery when normal trust checks cannot be satisfied. Use it only with strong operator controls and clear incident context.
If you do not know whether you need it, you probably do not.
Each artifact serves a different purpose:
-
qr_document.pdf: primary QR scan source -
recovery_document.pdf: fallback text and metadata path - optional
sharddocs: threshold-based passphrase recovery - optional
signing-key-sharddocs: threshold-based signing key recovery
At minimum:
- once after each workflow/policy change
- periodically on a fixed schedule (for example quarterly)
- after major software upgrades before switching production workflows
If your data is very important, drill more often.
Yes. Use --fallback-file (or stdin fallback input) and provide shard/auth inputs when required by
the selected backup mode.
It means cryptographic checks passed for the provided artifact set. For high-assurance environments, pair verification with external trust controls and documented custody workflows.
Simple version: "verified" means the set is internally consistent. It does not automatically mean your external trust policy is satisfied.
Canonical design names are:
archiveforgeledgermaritimesentinel
Flags evolve over time. Always check the command-specific help on your installed version:
ethernity recover --helpUse Sigstore bundle verification with the .sigstore.json sidecar from the same release tag.
See Release Artifacts for the full workflow.