Being Cautious: Database backup + restore process when testing things

I’m about to test a process of importing a boatload of content, but want to make sure I can revert properly in case things go sideways on me.

I run an external PostgreSQL instance, so my thought is that I don’t really need to backup the Discourse Rails instance in Docker, but simply the database via the following steps:

BACKUP:

  1. ./launcher stop app
  2. pg_dump -U username -p 12345 -W -F p databasename | xz > ~/backup/database/$(date +"%d-%m-%Y_%H.%M.%S").databasename.pgsql.xz
  3. ./launcher start app
  4. ### IMPORT CONTENT ###

If things went badly, RESTORE:

  1. ./launcher stop app
  2. xzcat ~/backup/database/DATE.databasename.pgsql.xz | psql -U username -p 12345 -W databasename
  3. ./launcher start app

And things should be back to sane and functional… correct?

Probably, there is a built in easy to restore that’s tested, supported, and requires just a couple of clicks or a single command line.

If your way doesn’t work you’re on your own.

1 Like

As I noted, this is for an external PGSQL database since I’m not using the Dockerized one and sadly the normal backup/restore method just doesn’t work for me (probably because I’m running a little bit newer version of PGSQL on the big DB server).

Oh. Yeah. If you’re running pg11 then you’re on your own. If you’re running pg10 on an external db it should be fine.

But test it and see if it works.

1 Like

PG11 and PG12 will be supported quite soon in the backup & restore process. Stay tuned.

4 Likes