This is the exact restore flow we use internally when we bring up a new Cosmos-SDK node — it's also what we recommend to operators and institutional node runners pulling our public snapshots.
Pick the right snapshot type
- Pruned — smaller, faster to download, keeps only the last ~100 blocks of state. Right for validators, sentry nodes, and RPC endpoints that don't serve historical queries. Refreshed every 12 hours.
- Archive — full historical state. Right for explorers, indexers, and any workload that calls RPC methods with historical block heights. Refreshed weekly, every Saturday.
- Pick based on what your node will actually be asked to do — and on which refresh cadence you can tolerate.
Restore flow
- Stop the target daemon cleanly. Do not skip this — a running daemon on the data dir will conflict with the restore.
- Back up the existing priv_validator_state.json (if this is a validator). Everything else in the data dir can be wiped.
- Download the snapshot archive from our snapshots page for the target chain. Each archive is signed; the signature is published alongside the archive.
- Verify the signature before extracting. This takes seconds and eliminates a class of supply-chain risks.
- Remove the old data dir contents (except the saved priv_validator_state.json if restoring a validator).
- Extract the archive into the data dir. Restore priv_validator_state.json if applicable.
- Start the daemon. The node will catch up any blocks produced since the snapshot was taken; expect a few minutes for the gap.
Verifying you're in sync
Call the node's status endpoint (e.g. curl localhost:26657/status). The catching_up field should flip to false once the gap closes. The latest_block_height should match a public explorer within one or two blocks.
Common pitfalls
- Wrong snapshot type. A pruned snapshot cannot serve archive queries; starting with the wrong type forces a full re-sync later.
- Skipped signature verification. Always verify before extracting.
- Priv-validator state loss. Losing priv_validator_state.json before restore can trigger a double-sign if the node comes up and signs at a height it has already signed. Back it up first.
- Stale snapshot window. Pruned snapshots refresh every 12 hours and archive snapshots refresh weekly on Saturdays; extracting a snapshot taken just before a chain upgrade can produce a node that won't start. Cross-check against the chain's current release.
If you hit a case the steps above don't cover, reach out — we publish these because they're useful, and we'd rather you finish the restore than guess.
About NodeStake
NodeStake is an institutional-grade validator and infrastructure operator running 50+ networks with $420M+ in delegated stake. Founded in 2019 with a perfect no-slashing record, we operate the full stack — validators, IBC relayers, public RPC endpoints, snapshots, and custom chain infrastructure — for protocols, foundations and institutional delegators across the Cosmos, EVM and emerging L1 ecosystems.
Website: https://nodestake.org
X / Twitter: https://x.com/NodeStake_top