I have a simple monolithic architecture:
A Django project hosted on an EC2 instance, talks to a PostgreSQL DB running on the same instance. I chose this architecture considering the traffic and cost. So, don't bash me on this one. :)
For disaster recovery, I regularly dump my DB (a full dump pg_dump -U postgres fishercoder_db > fishercoder_dump.sql
).
At restoring, I cannot get Django and the restoring DB to talk nicely with each other:
If I launch Django and run
./manage.py migrate
first, and then restore the DB from the dump, it fails because Django has already created a bunch of internal tables after running./manage.py migrate
which have exactly the same name of in my dump;If I restore the DB from the dump first, then my Django app cannot stand up because of insufficientprivilege to run
./manage.py migrate
, details asked here.
My question is:
Is my DR strategy reasonable? Any other more optimal ways?
How can I get this approach to work: restore my site on a new EC2 instance with DB restored from a .sql dump.