<p>Well, I would run the bitcoind in a VM, and regularly snapshot it.  If it fails, rollback the snapshot and reboot. Back online in &lt; 10 min, assuming frequent backups and you start working right away.  Not sure if this is the use case you're asking about, but that's what I'd do for max uptime.</p>

CC BY-SA 3.0
2012-12-20T02:52:22.163Z
2012-12-20T02:52:22.163Z
lordcirth
<p><a href="https://bitcoin.stackexchange.com/users/2472/lordcirth">lordcirth</a>'s VM <a href="https://bitcoin.stackexchange.com/a/5872/1409">suggestion</a> is great, but let's build upon it. Let's think of it more like an elastic cloud VM instead of a snapshotting procedure.</p>

<ol>
<li>VM with <code>bitcoind</code>, optional snapshotting, but definite periodic backups of wallet.dat. Period is equal to the expected rate of change of the wallet.</li>
<li>Blockchain files are stored locally but also periodically backed up to a remote disk. An increment every 2 hours would probably suffice, with the standard <a href="https://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son" rel="nofollow noreferrer">Grandfather-father-son</a> rotation. At 10 minutes per block, that's 8640 blocks that you could be behind with backups a day behind. Son is the semi-daily, father is every 12 hours, and grandfather weekly, with perhaps a great grandfather monthly.</li>
<li>When something bad happens to the running VM, don't waste the time rolling back the snapshot. Just fire up a new VM and have it get the latest backup from the remote disk.</li>
</ol>

<p>In my mind, snapshots are for when you make a change that you want to roll back. </p>

<p>When you want a highly available service that when automated can maximize uptime, go the disposable VM route. The bonus is that you get can spin up additional <code>bitcoind</code> servers on local metal or within each instance and have an authoritative backup ready to go for them. You'll just have to manage the wallet.dat coordination, since multiple <code>bitcoind</code> processes can't share those, either.</p>

CC BY-SA 3.0
2012-12-20T17:58:56.413Z
2012-12-20T17:58:56.413Z
2017-04-13T12:47:32.940Z
Colin Dean
<p>Lets say I have a bitcoind instance running on a server with proper wallet.dat backups created regularly. The server crashes, blockchain data becomes corrupted or what have you, and I need to set up a server client fast to take over traffic. Moreover, I need the service to be interchangeable with the official client - that is it needs to provide the same RPC commands, conform to the wallet.dat specification so it can be interchanged between the clients and so forth. What is the fastest way one can do that in case of emergencies?</p>

<client><bitcoind><alternatives><installation><server>
Zero to Bitcoin in sixty seconds - how to set up a Bitcoin client in case you need it fast?
ThePiachu
# Zero to Bitcoin in sixty seconds - how to set up a Bitcoin client in case you need it fast?

(Asked by: username_0 on 2012-09-24)

Lets say I have a bitcoind instance running on a server with proper wallet.dat backups created regularly. The server crashes, blockchain data becomes corrupted or what have you, and I need to set up a server client fast to take over traffic. Moreover, I need the service to be interchangeable with the official client - that is it needs to provide the same RPC commands, conform to the wallet.dat specification so it can be interchanged between the clients and so forth. What is the fastest way one can do that in case of emergencies?

**Tags:** client, bitcoind, alternatives, installation, server


---

## 2 answers

### Answer by username_1 on 2012-12-20. Score: 5

Well, I would run the bitcoind in a VM, and regularly snapshot it. If it fails, rollback the snapshot and reboot. Back online in < 10 min, assuming frequent backups and you start working right away. Not sure if this is the use case you're asking about, but that's what I'd do for max uptime.


---

### Answer by username_2 on 2012-12-20. Score: 1

[username_1](https://bitcoin.stackexchange.com/users/2472/username_1)'s VM [suggestion](https://bitcoin.stackexchange.com/a/5872/1409) is great, but let's build upon it. Let's think of it more like an elastic cloud VM instead of a snapshotting procedure.

1. VM with `bitcoind`, optional snapshotting, but definite periodic backups of wallet.dat. Period is equal to the expected rate of change of the wallet.
2. Blockchain files are stored locally but also periodically backed up to a remote disk. An increment every 2 hours would probably suffice, with the standard [Grandfather-father-son](https://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son) rotation. At 10 minutes per block, that's 8640 blocks that you could be behind with backups a day behind. Son is the semi-daily, father is every 12 hours, and grandfather weekly, with perhaps a great grandfather monthly.
3. When something bad happens to the running VM, don't waste the time rolling back the snapshot. Just fire up a new VM and have it get the latest backup from the remote disk.

In my mind, snapshots are for when you make a change that you want to roll back.

When you want a highly available service that when automated can maximize uptime, go the disposable VM route. The bonus is that you get can spin up additional `bitcoind` servers on local metal or within each instance and have an authoritative backup ready to go for them. You'll just have to manage the wallet.dat coordination, since multiple `bitcoind` processes can't share those, either.


---

