Deployment, backup and recovery: what operators would plan for
Development status: Planned — Once node software is implemented, enabled and publicly released, operators are expected to deploy, back up, recover and upgrade nodes using procedures that accompany that release; no such procedures are specified or published today. An experimental local multi-node test setup exists for internal development, and an experimental implementation saves node state and restores it on restart, with crash safety not established. Nothing on this page is an instruction, and nothing is publicly available for live use.
Before you read: Operating a node: intended roles and what exists today.
What would operators need to plan for deployment, backup, recovery and upgrades, and what is specified today? This page previews a future operator experience. It states what exists today, lists the operational concerns a supported release would be expected to address — each marked as not yet specified — explains what the experimental local multi-node test setup is and is not, and closes with what a supported release would add. It contains no runbooks, commands, thresholds or recovery steps.
Planned experience, not instructions
This page describes a future operator experience. It is not a set of instructions.
- Exact installation commands and released tooling are not yet available.
- Every concern below is marked not yet specified until a supported release documents it.
- No hardware, capacity, retention or recovery-time figures are published, and none should be inferred from this page.
What is specified today
- Experimental implementation exists: an experimental local multi-node test setup exists for internal development. It is described further down this page.
- Experimental implementation exists: an experimental implementation saves node state to disk and restores it when the node restarts. Its crash safety has not been established. See State persistence, snapshots and recovery.
- Not yet specified: production deployment, backup and recovery procedures are not specified or published.
- Not yet specified: no operator upgrade procedure is published.
Deployment
Not yet specified. Deployment means installing and running node software in an environment. Once node software is released, its supported documentation would be expected to cover:
- Preparing an environment — what a node would need from the machines and network it runs on. Requirements and supported platforms are not published.
- Obtaining supported software — a released version with a version identity. No node software has been released.
- Configuring a node — the settings an operator would choose. Configuration is not published.
- Joining a network — connecting a node to a network it is permitted to join. No public network exists; see Networks and environments.
- Creating and protecting operator keys — the keys a node and its operator would act with. The planned design would allow keys to be created, rotated and revoked under policy; this is not yet implemented. See Key lifecycle: creation, rotation and revocation.
Backup and recovery
Not yet specified.
- What to back up, how often and where. Operators would need to decide what to back up — such as node state, configuration and keys — how often, and where the copies are kept. In this documentation a backup is not the same thing as a snapshot; see the glossary entries for both.
- Restoring is not recovering. Restoring a node’s own saved state after a restart differs from recovering after loss or damage. The first exists experimentally, with crash safety not established. The second has no published procedure.
- Expectations. Supported expectations for how much recent data could be lost in a failure, and how long recovery could take, are not published.
- Confirming recovery. An operator would confirm that a node has recovered by watching its health and status; see Node monitoring and observability.
Recovering a node is also different from regaining the ability to act for an identity after a key is lost. That concept, a recovery path, is described on Participant identity.
Upgrades and incidents
Not yet specified.
- Applying new versions safely. Operators would need to move their nodes to new software versions without disrupting the network. How protocol changes would be staged, and delayed so that they can be reviewed, is being explored; see Time-delayed execution and staged upgrades.
- Compatibility between versions. Once releases exist, compatibility between versions would be described on Versioning, compatibility and deprecation. No compatibility commitments are published.
- Incidents. During an incident, emergency controls would be expected to operate only within their intended limits. The design is exploring scoped, time-limited emergency controls; see Emergency controls and protocol safeguards.
The local multi-node test setup
Experimental implementation exists — internal only.
- It is an internal aid for running several nodes together during development and testing.
- It is not a deployment procedure, not a template for production use and not a public network. It cannot be joined.
- Its layout, configuration and commands are not published.
How to plan now
- Use the concerns on this page to frame internal planning questions — for example, who in your organisation would own backups, key protection and upgrades — rather than to build procedures.
- Do not base procedures on experimental artefacts, or on instructions that do not come from this documentation.
- Follow Networks and environments, Tools, SDKs and wallet availability and the Documentation change log for any change in availability.
What a supported release would add
When a supported release and operator environment become available, its documentation would be expected to include:
- supported deployment guides, requirements and configuration reference, each with a version identity;
- backup and recovery procedures, with their stated expectations and limits;
- upgrade procedures and compatibility notes;
- operational guidance for monitoring and for handling incidents.
Supported versions and exact procedures would accompany that release.
Assumptions, trust and limitations
- The concern list is indicative, not complete. A release would define the supported scope.
- Experimental artefacts are internal and are not evidence of production readiness.
- Statements on this page describe the state of development as of the page’s date.
Not yet available, and how this page will grow
Exact installation commands and released tooling are not yet available. When a supported release exists, this preview would be replaced at the same address by supported operator documentation, and the change would be recorded in the Documentation change log. Further technical reference is not yet available.
What this page does not claim
This page does not claim:
- any runbook, command, threshold, recovery step or hardware requirement;
- any figure for data loss, recovery time, retention or capacity;
- crash safety, durability or disaster recovery for any experimental software.
Anything not stated here as available should be treated as unavailable.
Related pages
- State persistence, snapshots and recovery — what the experimental implementation does on restart.
- Node monitoring and observability — how operators would watch nodes and confirm recovery.
- Emergency controls and protocol safeguards — intended limits on action during incidents.
- Time-delayed execution and staged upgrades — how changes would be staged.
- Operating a node: intended roles and what exists today — the operator overview.
- Key lifecycle: creation, rotation and revocation — the planned lifecycle for keys, including operators’ keys.
- Versioning, compatibility and deprecation — future version and compatibility policy.
Glossary
References
No approved public references yet.
