The snapshot service provides node operators and developers with different types of blockchain snapshots. These snapshots enable quick node synchronization without waiting days for a full sync from genesis. Each snapshot type serves specific operational needs, ensuring both validators and developers can deploy nodes efficiently.
The service offers multiple snapshot types tailored for different use cases:
Pruned snapshots contain recent blockchain data with older states removed to minimize storage requirements. These snapshots are ideal for validators and full nodes that need to participate in consensus but don't require complete historical data. They maintain sufficient recent history for normal operations while significantly reducing disk space usage compared to archive nodes.
Pruned-PebbleDB snapshots are specifically designed for nodes using PebbleDB as their database backend instead of the default GoLevelDB. PebbleDB is an alternative key-value store that offers improved performance characteristics and lower memory usage, particularly beneficial for high-throughput chains. These snapshots are only compatible with nodes configured to use PebbleDB (requires setting db_backend = "pebbledb" in config.toml).
Archive snapshots contain the complete blockchain history from genesis, preserving all historical states and transactions. These comprehensive snapshots are essential for block explorers, data indexers, and applications that need to query any past state of the blockchain. While archive nodes require substantially more storage space, they provide unrestricted access to the entire chain history.
Raw snapshots (when available) are designed specifically for developers creating network forks and testnets. Unlike pruned snapshots, raw snapshots provide actual network state data that can be used to create realistic test environments. These snapshots enable developers to fork the network at a specific height with real state data, making them invaluable for testing protocol upgrades, new features, or conducting network simulations.
For creating network forks and testnets, visit the Rehearsal repository at https://github.com/hadronlabs-org/rehearsal. This repository contains tools for creating test environments using real network data.
Before resetting the node you should stop it to avoid any potential data corruption.
$ sudo systemctl stop neutrond
Reset your node. Please be AWARE that resetting the node will result in the deletion of your node database. It is important to note that if you are currently running a validator, you should have previously backed up your "priv_validator_key.json" file before executing the reset command. Although the command itself does not erase the file, it is crucial to have a backup of it stored securely in a separate location.
As Neutron Network supports wasm and its "wasm" folder is located outside the data folder, our snapshot now includes the "wasm" folder. It's important to note that we have excluded the cache sub-folder from the snapshot to ensure compatibility with all CPUs. To ensure a clean start, please manually delete your "wasm" folder. Please be aware that using the "unsafe-reset-all" command does not reset the "wasm" folder, so manual deletion is necessary.
$ rm -r ~/.neutrond/wasm
To decompress the snapshot, you should extract its contents into your database location. Typically, the database location can be found at "~/.neutrond" or a similar path, depending on your specific node implementation. Please ensure that you decompress the snapshot into the appropriate database directory to successfully restore the snapshot's data.
Before proceeding with the restart, it is essential to double-check the contents of the "~/.neutrond/wasm" folder to ensure it is not empty. If you find that the folder is indeed empty, it indicates a potential bug in our snapshot script. We kindly request you to reach out to us via the Discord Server so that we can address the issue promptly.
However, if the folder contains files and directories as expected, you can proceed with restarting your node.
$ sudo systemctl start neutrond
Ensure that your node is currently operational.
$ sudo systemctl status neutrond
$ sudo journalctl -fu neutrond