Making a Partial Backup of a Django app database
Published on
Background
When I earlier set up local development for a Django app, I wanted my environment to be as close to production as possible. Now I wanted to go further and use a copy of the existing database data, as well as images stored in the project root's media folder.
To avoid copying sensitive user data, I decided to create a partial backup of the database - excluding user-related tables - and then copy the media files. This post explains exactly how I did that, step by step.
Inspecting the database
First, I logged into the production server, activated the virtual environment, and went into the project root folder. From here I could use two shells to help - the Python shell, and the PostgreSQL shell.
To see the tables:
I also checked the models in models.py locally to see which tables might contain user data. Another handy method is to inspect foreign keys pointing to the Django auth.User table from the Python shell (by running python manage.py shell):
From here I could see which tables were likely connected to users. I could also optionally check actual data in the production database:
I decided to exlucde the following tables (built-in Django user tables and admin logs):
Plus other user-related tables.
Creating a partial backup
With the tables identified, I ran:
Notes:
--data-onlymeans the dump contains only table contents, not table definitionssudo -u postgresensures we run the command as the PostgreSQL superuser.
Check the file:
Transferring the backup to a local machine
I used SCP (Secure copy protocal), which lets you securely transfer files over SSH:
The trailing '.' means copy to the current folder, and no -r flag because it's a single file.
Restoring the partial backup locally
Make sure PostgreSQL is running:
Restore the data:
Inspect the tables:
Copying the media files
Finally, I copied the media folder from the droplet. Here I do need the -r flag because it's a directory:
After it finished, I could see all the book images locally.
Creating a local superuser
The last step was to create a local Django admin account to manage the app:
Now I could log into the admin section, from where I could make use of their brilliant built-in admin area to inspect all the data inside.
Conclusion
This process outlined how I managed to bring over a partial backup of a database in order to help mirror production more closely, without importing sensitive user data. It also highlights a few different ways you can safely check out things in the database and the Django app by using two shell environments.
Hopefully this has been of some help to anyone who has happened to stumble across this, and as always, if you want to get in touch about anything I've written here, or really anything at all, please don't hesitate to send me a message! No seriously, please do, it's lonely here.