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.5 | Testnet | 62 minutes |
| 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 with kill, not irondivi-cli stop: in IronDivi 0.2.5 stop answers but the node keeps running.
kill $(pgrep irondivid) 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 stopped 6 seconds after kill. Packing took 39 seconds and gave a 485 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 54 seconds after the start, at the height it was packed at. The public testnet nodes reset its connections, as described in Install the Divi node, so we added an addnode line for our other node. It then stayed 2 blocks behind for about two minutes, its log saying Chain is up to date, and caught up after that. The node makes a new, empty wallet and says so in its log: new wallet created; retrieve the seed with the dumphdinfo RPC.
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.