<p>My setup is an old (~2012) laptop + small SSD and a NAS with HDDs. I noticed that trying to sync Bitcoin Core (v0.18) on the NAS was slow, but on SSD was very fast. (Everything is connected via ethernet cables of ~3ft length, so can't be a network problem, can it?)</p>

<p>So I thought about syncing a pruned node, with manual pruning, and periodically backing up the data from <code>/blocks</code> and <code>/chainstate</code> of my <code>datadir</code> to the NAS, before executing the prune. My idea was to set up a node with the full chain once the sync was done.</p>

<p>The problem is it doesn't work. So if I run the node with <code>datadir</code> on the NAS, Bitcoin Core will just shut down. But if I remove the <code>/blocks</code> and <code>/chainstate</code> directories from the NAS, the IBD starts with no problems. (Aside from slow, that is.)</p>

<p>So my question is, can this trick be used? If so, how?</p>

<p>&nbsp;</p>

<p>If it helps, my <code>bitcoin.conf</code> for the pruned node is</p>

<pre><code>### bicoin.conf of pruned node
debug=0
daemon=1
server=1

prune=1

dbcache=4096
</code></pre>

<p>and the one for the full archivial node on NAS is</p>

<pre><code>### bitcoin.conf of archivial node on NAS
debug=0
daemon=1
server=1

dbcache=4096
par=-1
listen=0
</code></pre>

<p>&nbsp;</p>

<p>Edit: debug.log from last time I tried running the node on NAS (removed timestamps)</p>

<pre><code>Bitcoin Core version v0.18.1.0-3b0422118 (release build)
InitParameterInteraction: parameter interaction: -listen=0 -&gt; setting -upnp=0
InitParameterInteraction: parameter interaction: -listen=0 -&gt; setting -discover=0
InitParameterInteraction: parameter interaction: -listen=0 -&gt; setting -listenonion=0
Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
Using the 'sse4(1way),sse41(4way)' SHA256 implementation
Default data directory /home/bitcoin/.bitcoin
Using data directory /home/bitcoin/.bitcoin
Config file: /home/bitcoin/.bitcoin/bitcoin.conf
Using at most 125 automatic connections (1024 file descriptors available)
Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
Using 3 threads for script verification
scheduler thread start
HTTP: creating work queue of depth 16
No rpcpassword set - using random cookie authentication.
Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie
Using rpcauth authentication.
HTTP: starting 4 worker threads
Using wallet directory /home/bitcoin/.bitcoin
init message: Verifying wallet(s)...
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Using wallet /home/bitcoin/.bitcoin
BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
init message: Loading banlist...
Cache configuration:
* Using 2.0 MiB for block index database
* Using 8.0 MiB for chain state database
* Using 4086.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
init message: Loading block index...
Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
Opened LevelDB successfully
Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
LoadBlockIndexDB: last block file = 1818
LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=119, size=96043707, heights=598015...598157, time=2019-10-05...2019-10-06)
Checking all blk files are present...
LoadBlockIndexDB(): Block files have previously been pruned
Shutdown requested. Exiting.
Shutdown: In progress...
scheduler thread interrupt
Shutdown: done
</code></pre>

CC BY-SA 4.0
2019-12-15T01:26:17.283Z
What do you see in the debug.log file on the NAS when you start bitcoind after copying to it.
Pieter Wuille
CC BY-SA 4.0
2019-12-15T03:14:41.070Z
Added debug.log details.
leilerg
CC BY-SA 4.0
2019-12-15T03:23:10.867Z
It seems you've made your copy after some pruning already happened.
Pieter Wuille
CC BY-SA 4.0
2019-12-15T04:01:25.640Z
This is odd... in my ```blocks``` dir I have blk00000.dat onwards and the corresponding revXXXXX.dat files. And in ```chainstate``` the files get pruned automatically, don't they? How can I tell? Or differently, what do I need to make it work?
leilerg
CC BY-SA 4.0
2019-12-16T01:28:26.500Z
Hmm, that's surprising.
Pieter Wuille
<bitcoin-core><full-node><pruning>
How can I use backup up chain data from pruned node to set up (archivial) node without IBD?
leilerg
# How can I use backup up chain data from pruned node to set up (archivial) node without IBD?

(Asked by: username_0 on 2019-12-15)

My setup is an old (~2012) laptop + small SSD and a NAS with HDDs. I noticed that trying to sync Bitcoin Core (v0.18) on the NAS was slow, but on SSD was very fast. (Everything is connected via ethernet cables of ~3ft length, so can't be a network problem, can it?)

So I thought about syncing a pruned node, with manual pruning, and periodically backing up the data from `/blocks` and `/chainstate` of my `datadir` to the NAS, before executing the prune. My idea was to set up a node with the full chain once the sync was done.

The problem is it doesn't work. So if I run the node with `datadir` on the NAS, Bitcoin Core will just shut down. But if I remove the `/blocks` and `/chainstate` directories from the NAS, the IBD starts with no problems. (Aside from slow, that is.)

So my question is, can this trick be used? If so, how?

If it helps, my `bitcoin.conf` for the pruned node is

```
### bicoin.conf of pruned node
debug=0
daemon=1
server=1

prune=1

dbcache=4096

```

and the one for the full archivial node on NAS is

```
### bitcoin.conf of archivial node on NAS
debug=0
daemon=1
server=1

dbcache=4096
par=-1
listen=0

```

Edit: debug.log from last time I tried running the node on NAS (removed timestamps)

```
Bitcoin Core version v0.18.1.0-3b0422118 (release build)
InitParameterInteraction: parameter interaction: -listen=0 -> setting -upnp=0
InitParameterInteraction: parameter interaction: -listen=0 -> setting -discover=0
InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
Using the 'sse4(1way),sse41(4way)' SHA256 implementation
Default data directory /home/bitcoin/.bitcoin
Using data directory /home/bitcoin/.bitcoin
Config file: /home/bitcoin/.bitcoin/bitcoin.conf
Using at most 125 automatic connections (1024 file descriptors available)
Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
Using 3 threads for script verification
scheduler thread start
HTTP: creating work queue of depth 16
No rpcpassword set - using random cookie authentication.
Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie
Using rpcauth authentication.
HTTP: starting 4 worker threads
Using wallet directory /home/bitcoin/.bitcoin
init message: Verifying wallet(s)...
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Using wallet /home/bitcoin/.bitcoin
BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
init message: Loading banlist...
Cache configuration:
* Using 2.0 MiB for block index database
* Using 8.0 MiB for chain state database
* Using 4086.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
init message: Loading block index...
Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
Opened LevelDB successfully
Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
LoadBlockIndexDB: last block file = 1818
LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=119, size=96043707, heights=598015...598157, time=2019-10-05...2019-10-06)
Checking all blk files are present...
LoadBlockIndexDB(): Block files have previously been pruned
Shutdown requested. Exiting.
Shutdown: In progress...
scheduler thread interrupt
Shutdown: done

```

**Tags:** bitcoin-core, full-node, pruning

> **Comments:**
> **username_1**: What do you see in the debug.log file on the NAS when you start bitcoind after copying to it.  
> **username_0**: Added debug.log details.  
> **username_1**: It seems you've made your copy after some pruning already happened.  
> **username_0**: This is odd... in my ```blocks``` dir I have blk00000.dat onwards and the corresponding revXXXXX.dat files. And in ```chainstate``` the files get pruned automatically, don't they? How can I tell? Or differently, what do I need to make it work?  
> **username_1**: Hmm, that's surprising.  

---

## 0 answers

