1Let the node sync from peers
The safe way is the plain one: start the node and let it download every block from other nodes. It checks each block as it goes, so you trust nobody's copy. These are the times we measured:
| Node | Chain | Time from nothing |
|---|---|---|
Original node, divid 3.0.0 | Mainnet, 6.5 GB | 3 hours 37 minutes |
Original node, divid 3.0.0 | Testnet | About 20 minutes |
| IronDivi 0.2.6 | Testnet | 74 minutes, with a second node syncing on the same machine |
| Original node over Tor | Testnet | 51 minutes |
Each figure is one run on a fast Linux server, so yours will differ. If a few hours is fine, stop here: follow Install the Divi node or Install IronDivi and wait.
2The public snapshot
A snapshot is a packed copy of another node's chain folders. You unpack it, start your node, and it only has to fetch the last few blocks.
A mainnet snapshot is offered at snapshots.diviproject.org. On 22 October 2026 it was a 4.9 GB file, and the page says it is updated every 24 hours. There is no testnet snapshot.
The site publishes no checksum for the file, so you cannot check that what you downloaded is what was meant to be there. Your node trusts the blocks in a snapshot without checking each one again. Only use a snapshot whose maker you can name and whose checksum you can compare. The safest such maker is you.
3Make a snapshot of your own node
This works when you already run a synced node and want a second one, for example on a new computer. The steps are for the original node on Linux. The data folder is ~/.divi, and testnet keeps its chain in ~/.divi/testnet3.
First stop the node cleanly. A copy of a running node is likely to be damaged.
divi-cli stop
Divi server stopping
pgrep divid || echo stopped
Pack only the chain folders: blocks, chainstate and sporks. Leave out wallet.dat, which holds your keys, and divi.conf, which holds your password.
cd ~/.divi/testnet3
tar -czf ~/divi-testnet-snapshot.tar.gz blocks chainstate sporks
cd ~ && sha256sum divi-testnet-snapshot.tar.gz > divi-testnet-snapshot.tar.gz.sha256
cat divi-testnet-snapshot.tar.gz.sha256
05a920c43205f47a20cc18f58654fcfde216e8614f5a958d4a70178cd4c951bc divi-testnet-snapshot.tar.gz
On our testnet node the folders held 460 MB. Packing took 26 seconds and gave a 309 MB file. A mainnet copy is much larger. Start the old node again as soon as the file is written.
4Copy it and check it
Copy both files to the new computer, for example with scp, and check the file there:
scp divi-testnet-snapshot.tar.gz* newmachine:
ssh newmachine
sha256sum -c divi-testnet-snapshot.tar.gz.sha256
divi-testnet-snapshot.tar.gz: OK
Anything other than OK means the copy is damaged. Copy it again.
5Start the new node from the snapshot
Unpack into an empty data folder, then write a new divi.conf with its own password. The node's settings files explains each line.
mkdir -p ~/.divi/testnet3 tar -xzf divi-testnet-snapshot.tar.gz -C ~/.divi/testnet3 nano ~/.divi/divi.conf divid -daemon
Unpacking took 4 seconds. The first start is slow, because the node checks the newest blocks before it answers. Ours answered after 170 seconds, already at height 360,911, and its log said:
LoadBlockIndexState: Last shutdown was prepared: true Verifying last 100 blocks at level 4
Our copy was about 30 blocks behind. The new node found no peers for its first 6 minutes, then connected to two and fetched the missing blocks within a minute. Check it the usual way, with verifychain for a final check:
divi-cli getblockcount
divi-cli verifychain 3 1000
true
The node makes a new, empty wallet. Load your own with Back up your wallet, or send coins to a new address.
6The same for IronDivi
IronDivi keeps its chain in two folders inside its data folder: chainstate and txindex. The wallet is in wallet and the settings in irondivi.conf; leave both out. On testnet the data folder is ~/.irondivi/testnet.
Stop the node first. On IronDivi 0.2.6, irondivi-cli --testnet stop does it. (On 0.2.5 that command answers but the node keeps running; use kill $(pgrep irondivid) there.)
irondivi-cli --testnet stop pgrep irondivid || echo stopped cd ~/.irondivi/testnet tar -czf ~/irondivi-testnet-snapshot.tar.gz chainstate txindex cd ~ && sha256sum irondivi-testnet-snapshot.tar.gz > irondivi-testnet-snapshot.tar.gz.sha256
Our node was gone 2.5 seconds after stop. Packing took 42 seconds and gave a 467 MB file. Copy and check it as in step 4, then unpack it on the new computer and write a new irondivi.conf:
mkdir -p ~/.irondivi/testnet tar -xzf irondivi-testnet-snapshot.tar.gz -C ~/.irondivi/testnet nano ~/.irondivi/testnet/irondivi.conf irondivid --testnet
Our copy answered 35 seconds after the start, already one block past the height it was packed at. We had put an addnode line for a second testnet node, 157.90.16.105:51474, in its settings, because the public testnet nodes sometimes reset new connections, as described in Install the Divi node. The node makes a new, empty wallet and says so in its log: new wallet created; retrieve the seed with the dumphdinfo RPC.
IronDivi 0.2.6 can make a thin snapshot itself
Version 0.2.6 added its own snapshot commands. Run them with the node stopped. The export writes only the coin database and the newest few thousand blocks, plus a MANIFEST.json listing every file with its SHA-256, and prints one root hash that stands for all of it:
irondivid --testnet --export-snapshot ~/irondivi-snap
snapshot written to "/home/you/irondivi-snap"
network testnet tip 361661 9f1ab055c703d7c264be33bf26424f3bcfe02c2d5e349e98f72bffe1f4d153c9
root_hash 1f4fb45795b97635f65ac3771bb8a5333286daee0d609cb94476766d29680201
Ours took 28 seconds and the folder was 197 MB, against 1 GB for the full chain folders. Copy the folder to the new computer, and send the root hash separately, the way you would send a checksum. There, with an empty data folder and its irondivi.conf, install it and give the hash you expect. A wrong hash is refused before anything is written:
irondivid --testnet --import-snapshot ~/irondivi-snap \
--snapshot-root 1f4fb45795b97635f65ac3771bb8a5333286daee0d609cb94476766d29680201
snapshot installed at "/home/you/.irondivi/testnet/chainstate"
network testnet tip 361661 9f1ab055c703d7c264be33bf26424f3bcfe02c2d5e349e98f72bffe1f4d153c9
root_hash 1f4fb45795b97635f65ac3771bb8a5333286daee0d609cb94476766d29680201
start the node with --expire so it stays thin; blocks after the tip are fully validated
irondivid --testnet --expire 30d --daemon
The import took 2 seconds, and the node answered 10 seconds after the start, already past the snapshot's tip. getblockchaininfo then says "pruned": true: it holds only recent blocks, and fetched an old one (block 100,000) from a full node when we asked for it. That is enough to follow the chain and stake, but it is not a full copy of the chain. With a wrong --snapshot-root the import stopped with snapshot: root hash … does not match the expected … and left the data folder untouched. Trust a root hash only from someone you can name, just as with the files above.
If something goes wrong
| What you see | What to do |
|---|---|
sha256sum -c says FAILED | The copy is damaged. Copy the file again and check again before you unpack it. |
Failed to open file … netfulfilled.dat or … peers.dat in debug.log | Normal on the first start. The node writes those files itself. |
getconnectioncount stays at 0 | Give it a few minutes. If it stays at 0, add addnode= lines for nodes you know, such as your old node. |
Last shutdown was prepared: false | The old node was still running when you packed it. Stop it cleanly and make the snapshot again, or see Recover a chain. |
| The node starts again from height 0 | The folders went to the wrong place. On testnet they belong in testnet3, inside the data folder. |
| The balance is 0 | Expected: the snapshot has no wallet. Restore your own wallet. |
Next: run your node as a service, or keep it current with Upgrade a node.