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.