<blockquote>
<p>How exactly could I copy (using standard tools like sftp or rsync) only the data I absolutely need from the archiving node to this new pruned node that will store, say, 2 GiB worth of blocks (prune=2048)?</p>
</blockquote>
<p>I'm pretty sure that is not possible using those tools. The data isn't arranged in a way that makes this approach possible.</p>
<blockquote>
<p>Is it possible to, say, copy just the last 2 GiB worth of blocks from the blocks/blk*.dat and/or blocks/rev*.dat files to get the pruned node up and running?</p>
</blockquote>
<p>It is very likely that there are indexes elsewhere that point into block data, if those indexes are missing or point to files that don't exist, I imagine Bitcoin core will regard this as a fatal error during startup.</p>
<hr />
<p>See also</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/101044/13866">Pruning Blockchain, what does it remove?</a></li>
</ul>

CC BY-SA 4.0
2023-01-21T21:24:00.423Z
That makes sense, thanks.  I wonder how Bitcoin Core could be refactored slightly to make this possible (if at all).
edwargix
CC BY-SA 4.0
2023-01-17T10:39:22.100Z
2023-01-17T11:56:21.527Z
2023-01-17T11:56:21.527Z
RedGrittyBrick
<p>Suppose I have an archiving full node (i.e. a full node where <em>all</em> blocks are saved to disk forever) running on one of my computers.</p>
<p>Now suppose I have another computer where I'd like to run a separate full node, but where I need to prune blocks instead of archiving them because the disk of this computer doesn't have enough space to store every block.</p>
<p>Obviously, I could begin running the new pruned node from scratch as normal and have it download and validate every block from the Bitcoin Network.  But this would be quite wasteful in terms of network bandwidth and CPU cycles, as I already have an archiving full node that I fully trust with the UTXO set and all of the blocks available.</p>
<p>How exactly could I copy (using standard tools like <code>sftp</code> or <code>rsync</code>) only the data I absolutely need from the archiving node to this new pruned node that will store, say, 2 GiB worth of blocks (<code>prune=2048</code>)?</p>
<p>Without a doubt, we'll want to copy the <code>chainstate</code> folder over in full for the UTXO set.  I assume we'll also want the <code>blocks/index</code> folder for the block metadata in LevelDB as well (plus, it's only 112MiB at time-of-writing).  So, the trick will be to copy only the <code>blocks/blk*.dat</code> and <code>blocks/rev*.dat</code> files that are absolutely necessary.</p>
<p>Copying everything over and then running with pruning enabled isn't an option as the disk isn't big enough.</p>
<p>Is it possible to, say, copy just the last 2 GiB worth of blocks from the <code>blocks/blk*.dat</code> and/or <code>blocks/rev*.dat</code> files to get the pruned node up and running?</p>

CC BY-SA 4.0
2023-01-17T14:48:22.717Z
You could sidestep the bandwidth use by connecting only to your already synced node during synchronization. It would still process the whole blockchain, though.
Murch
CC BY-SA 4.0
2023-01-21T21:22:28.767Z
Thanks @Murch, that definitely at least helps.
edwargix
<bitcoin-core><full-node><pruning>
Creating a pruned node from an archiving node
edwargix
# Creating a pruned node from an archiving node

(Asked by: username_0 on 2023-01-17)

Suppose I have an archiving full node (i.e. a full node where *all* blocks are saved to disk forever) running on one of my computers.

Now suppose I have another computer where I'd like to run a separate full node, but where I need to prune blocks instead of archiving them because the disk of this computer doesn't have enough space to store every block.

Obviously, I could begin running the new pruned node from scratch as normal and have it download and validate every block from the Bitcoin Network. But this would be quite wasteful in terms of network bandwidth and CPU cycles, as I already have an archiving full node that I fully trust with the UTXO set and all of the blocks available.

How exactly could I copy (using standard tools like `sftp` or `rsync`) only the data I absolutely need from the archiving node to this new pruned node that will store, say, 2 GiB worth of blocks (`prune=2048`)?

Without a doubt, we'll want to copy the `chainstate` folder over in full for the UTXO set. I assume we'll also want the `blocks/index` folder for the block metadata in LevelDB as well (plus, it's only 112MiB at time-of-writing). So, the trick will be to copy only the `blocks/blk*.dat` and `blocks/rev*.dat` files that are absolutely necessary.

Copying everything over and then running with pruning enabled isn't an option as the disk isn't big enough.

Is it possible to, say, copy just the last 2 GiB worth of blocks from the `blocks/blk*.dat` and/or `blocks/rev*.dat` files to get the pruned node up and running?

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

> **Comments:**
> **username_1**: You could sidestep the bandwidth use by connecting only to your already synced node during synchronization. It would still process the whole blockchain, though.  
> **username_0**: Thanks @username_1, that definitely at least helps.  

---

## 1 answers

### Answer by username_2 on 2023-01-17. Score: 1

> How exactly could I copy (using standard tools like sftp or rsync) only the data I absolutely need from the archiving node to this new pruned node that will store, say, 2 GiB worth of blocks (prune=2048)?

I'm pretty sure that is not possible using those tools. The data isn't arranged in a way that makes this approach possible.

> Is it possible to, say, copy just the last 2 GiB worth of blocks from the blocks/blk\*.dat and/or blocks/rev\*.dat files to get the pruned node up and running?

It is very likely that there are indexes elsewhere that point into block data, if those indexes are missing or point to files that don't exist, I imagine Bitcoin core will regard this as a fatal error during startup.

---

See also

* [Pruning Blockchain, what does it remove?](https://bitcoin.stackexchange.com/q/101044/13866)

> **Comments:**
> **username_0**: That makes sense, thanks.  I wonder how Bitcoin Core could be refactored slightly to make this possible (if at all).  

---

