Use something like Ansible (Puppet, Salt, Chef, whatever) to provision your servers, along with backups. You can also use DO disk images but they're not as good a solution; my Ansible playbooks will let me configure and deploy a fully functioning app or db server instance at the drop of a hat, on almost any infrastructure; a DO image is only good for deploying onto DO infrastructure.
If you're "in the cloud" (or hell, even if you're using your own bare iron servers), you need to be accepting that your server could just go away at any time (and Murphy's Law being what it is, probably at the worst possible time).
The real trick is figuring out how to handle backups and user data properly. It's easy to say "you need to plan for your main DB server going poof"; it's harder to actually make sure you can handle that without downtime and loss of user data. :)
> The real trick is figuring out how to handle backups and user data properly. It's easy to say "you need to plan for your main DB server going poof"; it's harder to actually make sure you can handle that without downtime and loss of user data. :)
Exactly this.
My little side project is fairly minimal, but users are paying for services. If the site goes down before my next backup, I'm going to have to reverse some charges (and look bad in the process!). One option might/would be to run failover on a $5 droplet, but then I also need to cluster Redis (server-side sessions), etc, etc... and it starts to become an "operations" side project and not a "product" side project. I'm using Puppet to automate the build process (and will build a "hot spare" image to get things up faster), but backups and failover are still tricky problems to solve.
If you're "in the cloud" (or hell, even if you're using your own bare iron servers), you need to be accepting that your server could just go away at any time (and Murphy's Law being what it is, probably at the worst possible time).
The real trick is figuring out how to handle backups and user data properly. It's easy to say "you need to plan for your main DB server going poof"; it's harder to actually make sure you can handle that without downtime and loss of user data. :)