Please confirm before starting
Check with the Web3Signer developers whether this page is needed, and in what form, before writing it. The scope below is a proposal, not a settled requirement, and some of it may turn out to be better placed on the existing slashing protection pages.
Summary
There is no guidance anywhere in the documentation on backing up, restoring, or recovering the slashing protection database. Add it, either as a dedicated page or as new sections on the existing slashing protection how-to.
Current state
how-to/configure-slashing-protection.md covers installing PostgreSQL, loading the schema, starting Web3Signer, importing and exporting interchange data, pruning, and the health check.
It does not cover backup, restore, retention, or what to do after data loss. Searching the documentation for backup or restore guidance returns nothing relevant.
Why this is needed
The slashing protection database is the one piece of state whose loss can lead directly to a slashing penalty. If it is lost, or restored to an earlier point in time, Web3Signer no longer knows what has already been signed.
An operator cannot reasonably work out a safe recovery procedure from PostgreSQL documentation alone, because the hard part is not the database restore. It is knowing what is safe to do afterwards, and how long to wait before signing again. That question is specific to validator behaviour, and this is the only place it can be answered authoritatively.
Suggested scope
- Backup approach
- Restore procedure, and how to verify the restored database is consistent before use.
- What to do after data loss or a restore to an earlier state, including any period an operator must wait before resuming signing.
- Retention, and how it interacts with pruning.
- How to test the recovery procedure without risk.
Verifying technical claims
This page carries real financial risk if it is wrong, so please do not infer the procedure.
The recovery sequence, and especially any waiting period before resuming signing, must be confirmed with a maintainer before publishing. If a detail cannot be confirmed, raise it in the pull request rather than filling the gap.
Please confirm before starting
Check with the Web3Signer developers whether this page is needed, and in what form, before writing it. The scope below is a proposal, not a settled requirement, and some of it may turn out to be better placed on the existing slashing protection pages.
Summary
There is no guidance anywhere in the documentation on backing up, restoring, or recovering the slashing protection database. Add it, either as a dedicated page or as new sections on the existing slashing protection how-to.
Current state
how-to/configure-slashing-protection.mdcovers installing PostgreSQL, loading the schema, starting Web3Signer, importing and exporting interchange data, pruning, and the health check.It does not cover backup, restore, retention, or what to do after data loss. Searching the documentation for backup or restore guidance returns nothing relevant.
Why this is needed
The slashing protection database is the one piece of state whose loss can lead directly to a slashing penalty. If it is lost, or restored to an earlier point in time, Web3Signer no longer knows what has already been signed.
An operator cannot reasonably work out a safe recovery procedure from PostgreSQL documentation alone, because the hard part is not the database restore. It is knowing what is safe to do afterwards, and how long to wait before signing again. That question is specific to validator behaviour, and this is the only place it can be answered authoritatively.
Suggested scope
Verifying technical claims
This page carries real financial risk if it is wrong, so please do not infer the procedure.
The recovery sequence, and especially any waiting period before resuming signing, must be confirmed with a maintainer before publishing. If a detail cannot be confirmed, raise it in the pull request rather than filling the gap.