<p>This is some old, but I stumpled over it, so here my two cents:</p>
<p>I think &quot;deduplication&quot; is the solution you're looking for. Due to the fact you need to keep each node in its usersapce independent AND at the same time you don't want to prune the nodes databases you can have a look at deduplication. deduplication is a complete transparent service provided by your filesystem/operation system.</p>
<p>Basically, when storing the same chunk of data the FS decides not to write a complete copy, but an &quot;address&quot; where to find it. For the user there is no difference, but on the media it spares a lot of physically adressed storage resources. That all works with kind of hashtables and severeal FS support deduplication (by file, block, chunk, and whatever). For your use acse it should be fine. you need to setup one &quot;server&quot; which provides for each node a &quot;user&quot;. you export your some space (over the net) and there you let all the nodes write their indivudual blockchains to. In the background the server takes care that whenever there are data chunks recognised as &quot;same&quot; they're not written, but an &quot;link&quot; set. If one node write anything different than the others for some reason (which should not happen, but who knows) it gets its own Chunk of data (which occupies of course its own space on the media). Be aware that you creat a SPoF with it anyway. But it is quite easy to catch that with redudant server/services.</p>
<p>Some NAS support deduplication out-of-the-box (AIK) and file systems like BTRFS and ZFS also support it. Check on <a href="https://en.wikipedia.org/wiki/Data_deduplication" rel="nofollow noreferrer">wikipdia</a> for more details.</p>

CC BY-SA 4.0
2022-06-29T03:09:02.037Z
2022-06-29T03:11:57.813Z
2022-06-29T03:11:57.813Z
jagottsicher
<p>I don't think this is possible; you'd have multiple node instances trying to read/write a single data directory. This is not the intended operation, you'd likely end up with corrupt data. </p>

<p>If you must run multiple independent nodes and are worried about storage requirements, I'd recommend looking into 'pruning mode', it will limit the storage requirements for each node instance. </p>

<p>Note that you can copy the data directory folder of a synced node, so that you will not need to run through the initial block download and sync for each individual node (lots of savings in time and computation here). Just be sure to stop bitcoind before copying the data directory, and then start it up again once the copy is complete. This will help avoid potential data corruption/loss. </p>

CC BY-SA 4.0
2019-09-29T08:52:49.623Z
Thanks for the explanation. I agree, a node should be independent. A shared disk would be a single point of failure for such a cluster. With my question I had in mind that there's a lot of redundancy at the price of hard disks, but redundancy IS actually good for the network.
Michael
CC BY-SA 4.0
2019-09-28T21:25:21.720Z
2019-09-28T21:25:21.720Z
chytrik
<p>I'm planning to create a Raspberry Pi Cluster in order to run several bitcoin nodes. Can I share parts of the <code>~/.bitcoin/</code> folder in order to not have to store the entire hundreds of GB for each of the nodes? My idea would be that one of the nodes has an external hard drive with the bulk data and the others make use of it over nfs or smb. </p>

<p>Any ideas or even experience on this? </p>

<blockchain><nodes><raspberry-pi><storage-footprint>
Is it possible to share blockchain data between multiple nodes?
Michael
# Is it possible to share blockchain data between multiple nodes?

(Asked by: username_0 on 2019-09-28)

I'm planning to create a Raspberry Pi Cluster in order to run several bitcoin nodes. Can I share parts of the `~/.bitcoin/` folder in order to not have to store the entire hundreds of GB for each of the nodes? My idea would be that one of the nodes has an external hard drive with the bulk data and the others make use of it over nfs or smb.

Any ideas or even experience on this?

**Tags:** blockchain, nodes, raspberry-pi, storage-footprint


---

## 2 answers

### Answer by username_2 on 2019-09-28. Score: 7 | Accepted answer

I don't think this is possible; you'd have multiple node instances trying to read/write a single data directory. This is not the intended operation, you'd likely end up with corrupt data.

If you must run multiple independent nodes and are worried about storage requirements, I'd recommend looking into 'pruning mode', it will limit the storage requirements for each node instance.

Note that you can copy the data directory folder of a synced node, so that you will not need to run through the initial block download and sync for each individual node (lots of savings in time and computation here). Just be sure to stop bitcoind before copying the data directory, and then start it up again once the copy is complete. This will help avoid potential data corruption/loss.

> **Comments:**
> **username_0**: Thanks for the explanation. I agree, a node should be independent. A shared disk would be a single point of failure for such a cluster. With my question I had in mind that there's a lot of redundancy at the price of hard disks, but redundancy IS actually good for the network.  

---

### Answer by username_1 on 2022-06-29. Score: 0

This is some old, but I stumpled over it, so here my two cents:

I think "deduplication" is the solution you're looking for. Due to the fact you need to keep each node in its usersapce independent AND at the same time you don't want to prune the nodes databases you can have a look at deduplication. deduplication is a complete transparent service provided by your filesystem/operation system.

Basically, when storing the same chunk of data the FS decides not to write a complete copy, but an "address" where to find it. For the user there is no difference, but on the media it spares a lot of physically adressed storage resources. That all works with kind of hashtables and severeal FS support deduplication (by file, block, chunk, and whatever). For your use acse it should be fine. you need to setup one "server" which provides for each node a "user". you export your some space (over the net) and there you let all the nodes write their indivudual blockchains to. In the background the server takes care that whenever there are data chunks recognised as "same" they're not written, but an "link" set. If one node write anything different than the others for some reason (which should not happen, but who knows) it gets its own Chunk of data (which occupies of course its own space on the media). Be aware that you creat a SPoF with it anyway. But it is quite easy to catch that with redudant server/services.

Some NAS support deduplication out-of-the-box (AIK) and file systems like BTRFS and ZFS also support it. Check on [wikipdia](https://en.wikipedia.org/wiki/Data_deduplication) for more details.


---

