Restoring Postgres from a snapshot?

Rack (Version 2)
1

I saw a couple hints in the past of being able to create a new database from a snapshot:

i. e. [20171002150509] RDS Fix and Improvements

But can’t seem to find any documentation on it. How would one go about doing this? Or what would be the best practices to restore from a snapshot and have it accessible from convox rack resources or convox resources?

2 Likes
2

Also very curious about this. I found this: https://github.com/convox/rack/blob/master/provider/aws/templates/resource/postgres.tmpl

Specifically interested in ‘DatabaseSnapshotIdentifier’.

Although those params don’t line up with the database options in my convox.yml so I’m not sure if those are for internal use only.

Any insight from the devs? Is there a way to have a postgres type resource automatically initialize from an RDS snapshot?

3

We’ve been experimenting with this ourselves with

convox rack resources create postgres DatabaseSnapshotIdentifier=arn:aws:rds:us-east-1:...

There are some gotchas around this though. The username and database name will come from the snapshot (and not necessarily what convox rack resources info reports), but the password will be randomly generated by convox. Also, the settings of the new database must match the original (Encrypted, AllocatedStorage, EngineVersion, Family, etc).

FYI we’ve only done some dry runs of this, and haven’t done it in production yet. We’ve had some problems updating the parameters afterwards. It also appears this isn’t possible for app resources, only for rack resources.

4

We also have ended up doing the same thing as what @julian said.

This bit:

Also, the settings of the new database must match the original (Encrypted, AllocatedStorage, EngineVersion, Family, etc).

is important, as it caused us a bit of a headache!

Re: “We’ve had some problems updating the parameters afterwards,” we have ended up modifying the RDS instance directly rather than through convox, which has put the convox vs. real settings out of sync – not ideal, but managing the DB directly through the AWS console is not a big deal for us. Could probably cause issues down the line though, so take with a grain of salt! :sweat_smile:

We successfully did this replicating some production instances, (wait for it to replicate, then switch over our services to use the new postgres instances, then kill the old instance).