Ask A Question


You’re not receiving notifications from this thread.

Disaster recover plan?!

Karim Tarek asked in Servers β€’


So I'm deploying my first Rails app built for a customer – πŸŽ‰ – to production in couple of days – I'm using Hatch – and I'm not sure what kind of setup/plan I should have for "disater recover" if things go wrong for any reason – I hope nothing will go wrong :)

I'm going to enable db backups so I always have most recent db, should I consider DigitalOcean backup – my understanding that they take a snapshot of the server every night – is that useful?

What would be the fastest way to restore the db incase I need to?

If you know of any good resource so look into that would be awesome as well.

Looking forward to your answers :)



This is a great question Karim! Exciting to get your app in production for a customer! 🍻

So a couple things to consider here:

  1. Database backups are safest when you upload them to somewhere third-party like S3. You can edit your Backup config on Hatch via SSH to use your S3 credentials for uploads. That will keep them safe in case anything happens to your server.
  2. DigitalOcean backups are handy for quick restoration of a server. You can create a new server based on your previous one in a minute or two this way. If you didn't have those, you'd need to setup a new server which takes a few minutes using Hatch. It can speed recovery up a little bit which is good.
  3. You'll want to make sure that you have practiced database restoration at least once before you go to production to be safe. Download one of the db backups from your app to your local computer and try restoring it to Postgres locally. This command should import the backup into a database: psql -U <username> -d <dbname> -1 -f <filename>.sql Once it's imported, you can check that all the same data is available locally as it was on your server.
  4. If you have file uploads that upload locally, you'll want to include those in your backup and restore process. If they're uploading to S3, you don't have to worry about it.

That's most of it. You should also setup the Backup config to notify you on slack or email for failed backups to be safe. If anything goes wrong, you'll want to address that right away.


As usual, that's some solid advice Chris :) thanks a lot.


Just a side note: it would be nice if backup config can be done through the UI ;)


Definitely agreed. That's on the todo list but there are a few things that are higher priority at the moment right now. Plus there are SO many configuration options for the backup gem, that it'd be hard to verify they're all correct and test them in the UI.


Sure I understand. Maybe you can start by the minimal amout of configurations like S3, email, and slack, that should do it for most poeple extra configurations then one gotta ssh in to server and configure him/herself.


Yeah, that's what I was thinking as a first version. πŸ™Œ


You said if file uploads are on S3 no need to backup. Does S3 have automatic backups?


I should clarify that. If your uploads are up to S3, any thing that happens to your server won't affect those files (which is good). You can also setup your S3 to back itself up to another bucket, or another service if you wanted.


Ok, that makes sense.

Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,329+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.