RECOVERY
Back up configuration and identity deliberately.
Chain history can be synchronized again from compatible peers, but local configuration, node identity and authorization material determine how the machine participates and should be handled as operator data.
What to preserve
| Item | Reason |
|---|---|
| Active configuration | Contains deployment, network and database settings; may contain secrets. |
| Node identity key material | Preserves the node identity used in signed peer hello messages. |
| Producer key material | Needed if you intend to preserve an already-authorized producer identity. |
| Standalone SQLite database | Fast local recovery for a standalone node; still validate chain identity after restore. |
| MySQL/MariaDB backup | Operational recovery for hosted deployments. Use database-native consistent backup tooling. |
Operator wallet
The non-custodial wallet private key is not supposed to live in the node filesystem. Back up the wallet using the wallet's own encrypted backup/export process, not by inventing a server-side plaintext copy.
Treat backups as secretsBackups can contain database credentials, webhook secrets, node keys or producer keys. Do not place them in public source archives, web roots, support bundles or downloadable node packages.
After restore
Start the node, verify mainnet chain identity and genesis, check peer synchronization, then separately confirm operator binding and production authorization before enabling any locally sensitive function.