Document how to restore from backup #2088
Conversation
In OpenCodelists, backups are JSON fixtures rather than SQL dumps. To restore from a backup, we must remember to remove the existing database and migrate, and *then* to load the data from the fixture.
There was a problem hiding this comment.
This looks fine to me as documentation of how to restore a production backup in production. However, if it's used as a method of loading a version of the production db locally, as you did, it's probably worth some notes about how to also get the latest coding system databases (and a caveat that codelist versions use a specific coding system release, which corresponds to a database, and they won't display properly if they depend on a coding system database that you don't have locally)
| @@ -48,6 +48,16 @@ A place to put scripts to be run via [runscript](https://django-extensions.readt | |||
|
|
|||
| The production database and backups are located at `/var/lib/dokku/data/storage/opencodelists` on dokku3 (see also [deployment notes](DEPLOY.md)). | |||
|
|
|||
| The backups are created with the dumpdata management command (`deploy/bin/backup.sh`). | |||
There was a problem hiding this comment.
Might be worth noting that these are backups of the core (default) db only, and not the coding system databases (which incidentally, are not backed up at all (but can theoretically be re-created from the coding system data files))
Could I check my understanding, @rebkwok? I think this means that to restore the production database locally, I'd need to download all (or nearly all) the coding system databases. Is that correct? Would me not having done so explain #2091? And if that is correct, then would that mean downloading every (or nearly every) |
In OpenCodelists, backups are JSON fixtures rather than SQL dumps. To restore from a backup, we must remember to remove the existing database and migrate, and then to load the data from the fixture.