Zero to Bitcoin in sixty seconds - how to set up a Bitcoin client in case you need it fast?

Question

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?

Answer 1

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 2

lordcirth's VM suggestion 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 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.