QUANTARA • QUANTUM-RESISTANT L1
Backup & restore guide for Quantara Devnet-0
What to back up, how often, and how to restore a Quantara validator or RPC node from scratch — without losing keys or spending days recovering.
Docs • Ops
Backup & restore guide for Quantara Devnet-0
Use this guide to design a simple, repeatable backup and restore workflow for your Quantara nodes. Devnet-0 is where you practice losing a machine — and bringing it back cleanly.
On any long-running network, something will eventually fail: disks die, instances get deleted, configs drift. The goal of this guide is to ensure those events are a routine inconvenience — not a multi-day outage.
We focus on three things: what to back up, how to back it up, and how to restore from scratch using your scripts and notes. Use this alongside the Key Management & Backups, Security checklist and Incident response docs.
The end state you want is simple: with only your backups and this runbook, you can rebuild a healthy validator or RPC node in hours, not days.
If you have never done a full rebuild from backups, assume you are not yet ready for public testnet or mainnet. Use Devnet-0 to change that.
Devnet-0 uses the same chain properties you'll see later:
Last updated: 2025-11-23 22:00 UTC. Confirm live endpoints, snapshots, and any backup-related advisories on the Status page before wiring automation.
1 • Scope
Decide what actually needs to be backed up
Most of a node is disposable. Focus your backups on keys, configs, and anything that takes significant time to recreate.
1.1 — Must-back-up items
- □ Mnemonics for stash / controller accounts.
- □ Session keys or a clear path to regenerate them.
- □ Node configuration (flags, chain-spec, env files).
- □ Systemd unit files and service definitions.
1.2 — Nice-to-have items
- □ Firewall rules and security group definitions.
- □ Monitoring / alerting configs and dashboards.
- □ Log aggregation or SIEM configuration.
- □ Shell scripts / Ansible / Terraform used for setup.
1.3 — Things you can usually rebuild
- • Blockchain database (can resync from peers or snapshot).
- • OS image and base packages.
- • Temporary logs older than your incident window.
- • Ephemeral cache files and build artifacts.
For deeper coverage of keys and secrets, see Key Management & Backups and the Security checklist.
2 • Strategy
Design a simple, boring backup routine
Backups work best when they’re automated and predictable. Start small, and evolve toward more sophisticated tooling over time.
2.1 — Where to store backups
- □ Use at least two independent storage locations.
- □ Encrypt everything at rest and in transit.
- □ Avoid keeping primary and backup copies on one host.
- □ Periodically verify access to each location.
2.2 — How often to back up
- □ Keys: whenever you create or rotate them.
- □ Configs: after any significant change.
- □ Dashboards / alerts: at least monthly.
- □ Optional DB snapshots: aligned with Devnet-0 milestones.
2.3 — Automating the boring parts
- □ Use scripts or infra-as-code to export configs.
- □ Schedule periodic jobs to sync backups to storage.
- □ Tag backups with environment, date, and node role.
- □ Keep a small README in each backup folder explaining it.
3 • Restore path A
Rebuild a node from a clean OS image
This is the slowest but most reliable restore path: fresh instance, fresh install, and a full resync from the network.
3.1 — High-level flow
- 1) Provision a new VM or bare-metal host.
- 2) Apply OS hardening from the Security checklist.
- 3) Install the pinned Quantara node binary or container.
- 4) Restore configs, systemd units, and monitoring.
- 5) Restore or regenerate session keys as needed.
- 6) Start the node and allow it to fully resync.
3.2 — Checks before returning to validation
- □ Height matches reference RPC and explorer.
- □ Logs show healthy peers and no repeated errors.
- □ Monitoring and alerts are wired and green.
- □ You've run a short restart drill on the new node.
See the Validator runbook for additional day-one sanity checks before rejoining the active set.
4 • Restore path B
Restore from a database or snapshot
For some incidents and environments, starting from a known-good snapshot or DB copy can be faster than a full resync.
4.1 — When to consider snapshots
- • Long resync times in your region or environment.
- • Need to return a validator to service quickly.
- • Access to a trusted, documented snapshot source.
- • Controlled rollbacks coordinated via incident notes.
4.2 — Snapshot restore safety rules
- • Only use snapshots from trusted, documented sources.
- • Verify checksums and metadata before use.
- • Follow any specific instructions in Rollback & Recovery and incident notes.
- • After restore, re-run all standard sanity checks.
5 • Drills
Turn backups into rehearsed muscle memory
A backup you’ve never restored from is just a hypothesis. Devnet-0 is the place to test that hypothesis.
5.1 — Rebuild drills
- □ Once per quarter, rebuild a node from scratch.
- □ Use only your backups and this runbook.
- □ Measure time from "host provisioned" to healthy node.
- □ Capture blockers and update scripts accordingly.
5.2 — Documentation hygiene
- □ Keep a small README with your backup layout.
- □ Document which scripts to run and in what order.
- □ Note which secrets are required for each step.
- □ Store docs in a private repo with version control.
5.3 — Tying into incident process
- □ After any real incident, log what worked and what didn't.
- □ Update this backup plan based on that experience.
- □ Use the Postmortem template for larger events.
- □ Share useful patterns (no secrets) with the validator community.
Next steps
If you can restore in hours, you’re ready for what’s next
A strong backup & restore story is one of the biggest differences between casual operators and long-term partners.
Combine this guide with the Security checklist, Key Management & Backups, and Incident response docs. Together they form the core of Quantara's operational resilience story for Devnet-0 and beyond.
Operators who can lose a machine and calmly rebuild it from backups are exactly who we want to grow with as we move from Devnet-0 to public testnet and mainnet.