OPERATORS / 03
Understand
what you retain.
Sync mode, state placement, and history retention solve different problems. Choose them against the data your workload needs.
Historical source snapshot. Source links point to commit 5af188d; text was reviewed 14 November 2026 and may differ from newer client builds.
State and history are different
State supports execution at a point in the chain. Headers, bodies, receipts, and transaction indexes support historical queries and recovery. Reducing one does not automatically remove the other.
| Decision | What to consider |
|---|---|
| Full / snap sync | How the node obtains and verifies its starting state and history. |
| Disk-backed state | The Rust --state.disk mode keeps head state on disk rather than in memory. |
| Minimal retention | The Rust --minimal mode retains what consensus reads; evaluate historical-query needs first. |
| Archive | The reviewed Rust README says --gcmode archive is refused. |
Snapshots are a separate workflow
The Rust source documents snapshot export and import. Use the matching format and network, validate the source, and follow the current guide rather than treating a snapshot as a portable copy of any client’s data directory.
Measure actual disk and memory
Capacity planning needs a defined network, block range, sync mode, retention profile, hardware, and build. Repository experiments are useful evidence, but they do not establish a universal disk-saving percentage or hardware minimum.
Choose a mode from its contract
The Rust documentation describes full sync as the default and snap/fast as the same mode using xOne snap/1 and xpre/1 peers. Read the sync-mode guide for compatibility and limits before changing an existing node.
Reviewed 14 November 2026. Repository guides hold the current implementation details.
KEEP THE CURIOSITY GOING
Another way in.
Edit this page on GitHub opens the data definition (data/site-pages.js). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.