<p>The easiest way would be doing a snapshot, but this method depends mainly on OS or Hardware support.</p>

<p>Another option is creating a bootstrap.dat file, which is basically a concatenation of all blocks in a single file. When the node finds this file in its data dir it loads all blocks from it before connecting to the network, so the initial load can be much faster (again, depending highly on your IO and processing capacity...).</p>

<p>You can create a bootstrap.dat file using the tools <a href="https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize" rel="nofollow" title="here">here</a>. To restore, see <a href="https://bitcointalk.org/index.php?topic=145386.0" rel="nofollow">https://bitcointalk.org/index.php?topic=145386.0</a></p>

CC BY-SA 3.0
2015-03-12T05:57:31.200Z
2015-03-12T05:57:31.200Z
Thomas Guyot-Sionnest
<p>What is a good strategy for backing up bitcoind's blockchain files (<em>not</em> its wallet file) without having to take (e.g.) a bitcoind that is powering a counterparty-server instance offline?</p>

<p>Copying the blockchain from a running bitcoind may result in a corrupted copy (<a href="https://bitcoin.stackexchange.com/a/25260/1660">https://bitcoin.stackexchange.com/a/25260/1660</a>),</p>

<p>To avoid this, is it best to run a separate bitcoind that pulls the blockchain from the first instance (by adding it as its sole network connection using addnode) and periodically stop that then rsync out any changes? Or is there a less circuitous way of getting a coherent blockchain backup from a live bitcoind?</p>

CC BY-SA 3.0
2015-03-09T02:03:26.020Z
This is an interesting question. But as blockchain is copied across every computer on the internet and offline copies are made available everywhere, what is the need for backing it up in the first place? (unless... of course, running your own blockchain?)
Mikko Ohtamaa
CC BY-SA 3.0
2015-03-09T04:01:02.333Z
It's for rapid recovery - it takes time to download and reindex the blockchain. I'm not worried about losing the blockchain, I'm worried about losing uptime if I have to recover it. :-)
Rob Myers
CC BY-SA 3.0
2015-03-09T04:06:42.907Z
As far as I can see blockchain is append-only database and even with aborted copy you should be well off with just purging and downloading the latest incomplete block, then running reindex, Though not sure if `bitcoind` can do this, though... :) Also the reindex is the expensive operation... soo you need to copy indexes as well if you want to make it fast.
Mikko Ohtamaa
CC BY-SA 3.0
2015-03-09T04:08:00.300Z
So the approach you suggest with addnode seems to be reasonable.
Mikko Ohtamaa
CC BY-SA 3.0
2015-03-09T09:50:27.267Z
Or leave them both running redundantly and have your backend connect to whichever is up (ie has the longest chain). Bonus points if each runs on a different internet connection, while they addnode each other through a local LAN IP. Or you could have the secondary instance disconnected from the internet until the primary fails and then you do some addnodes on the secondary.
Jannes
<blockchain><bitcoind><backup>
Live Blockchain Backup
Rob Myers
# Live Blockchain Backup

(Asked by: username_0 on 2015-03-09)

What is a good strategy for backing up bitcoind's blockchain files (*not* its wallet file) without having to take (e.g.) a bitcoind that is powering a counterparty-server instance offline?

Copying the blockchain from a running bitcoind may result in a corrupted copy (<https://bitcoin.stackexchange.com/a/25260/1660>),

To avoid this, is it best to run a separate bitcoind that pulls the blockchain from the first instance (by adding it as its sole network connection using addnode) and periodically stop that then rsync out any changes? Or is there a less circuitous way of getting a coherent blockchain backup from a live bitcoind?

**Tags:** blockchain, bitcoind, backup

> **Comments:**
> **username_1**: This is an interesting question. But as blockchain is copied across every computer on the internet and offline copies are made available everywhere, what is the need for backing it up in the first place? (unless... of course, running your own blockchain?)  
> **username_0**: It's for rapid recovery - it takes time to download and reindex the blockchain. I'm not worried about losing the blockchain, I'm worried about losing uptime if I have to recover it. :-)  
> **username_1**: As far as I can see blockchain is append-only database and even with aborted copy you should be well off with just purging and downloading the latest incomplete block, then running reindex, Though not sure if `bitcoind` can do this, though... :) Also the reindex is the expensive operation... soo you need to copy indexes as well if you want to make it fast.  
> **username_1**: So the approach you suggest with addnode seems to be reasonable.  
> **username_2**: Or leave them both running redundantly and have your backend connect to whichever is up (ie has the longest chain). Bonus points if each runs on a different internet connection, while they addnode each other through a local LAN IP. Or you could have the secondary instance disconnected from the internet until the primary fails and then you do some addnodes on the secondary.  

---

## 1 answers

### Answer by username_3 on 2015-03-12. Score: 1

The easiest way would be doing a snapshot, but this method depends mainly on OS or Hardware support.

Another option is creating a bootstrap.dat file, which is basically a concatenation of all blocks in a single file. When the node finds this file in its data dir it loads all blocks from it before connecting to the network, so the initial load can be much faster (again, depending highly on your IO and processing capacity...).

You can create a bootstrap.dat file using the tools [here](https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize "here"). To restore, see <https://bitcointalk.org/index.php?topic=145386.0>


---

