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?

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 OhtamaaMar 9 '15 at 2:03

1

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 MyersMar 9 '15 at 4:01

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 OhtamaaMar 9 '15 at 4:06

So the approach you suggest with addnode seems to be reasonable.
– Mikko OhtamaaMar 9 '15 at 4:08

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.
– JannesMar 9 '15 at 9:50

1 Answer
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...).