Backup failing to restore "Cannot restore into different schema"

(Matt) #1

Hi, I’m trying to restore a backup of Discourse from an older version into a newer one, however it fails with these errors:

[2018-05-25 03:32:07] Marking restore as running...
[2018-05-25 03:32:07] Making sure /var/www/discourse/tmp/restores/default/2018-05-25-033207 exists...
[2018-05-25 03:32:07] Copying archive to tmp directory...
[2018-05-25 03:32:07] Unzipping archive, this may take a while...
[2018-05-25 03:32:08] No metadata file to extract.
[2018-05-25 03:32:08] Validating metadata...
[2018-05-25 03:32:08]   Current version: 20180521190040
[2018-05-25 03:32:08]   Restored version: 20170731075604
[2018-05-25 03:32:08] Extracting dump file...
[2018-05-25 03:32:08] Cannot restore into different schema, restoring in-place
[2018-05-25 03:32:08] Enabling readonly mode...
[2018-05-25 03:32:08] Pausing sidekiq...
[2018-05-25 03:32:08] Waiting for sidekiq to finish running jobs...
[2018-05-25 03:32:08] Restoring dump file... (can be quite long)

Not sure what the line “Cannot restore into different schema, restoring in-place” means as I thought it could restore backups of older versions. Anyone got any ideas how to fix this?

(Cameron:D) #2

The database schema must have changed between those two versions.
I think the best way to go about restoring it would be to set up another copy at the old version, restore the backup, then upgrade it to the latest.

If you look at the default app.yml there should be a line that reads

#version: tests-passed

If you uncomment that and change it to the version/tag the backup was made on (for a list of versions: Tags · discourse/discourse · GitHub) then you should be able to build a new container at a specific version.

(Matt) #3

Hey Cameron, thanks for that advice.

Just to be clear, I’d uncomment that line and put something like:

version: 1.8.3

Is that correct?

(Cameron:D) #4

Yes. It would need to be the name of a tag from that page, so v1.8.3 would be correct.
Also note that you won’t be able to revert your exisiting container/install to an older version, you’ll need to create a new.

(Matt) #5

Thanks Cameron, how do you specify an older version at the install? Isn’t the app.yml created during the setup process?

(Cameron:D) #6

app.yml is just the default name the setup gives it. It’ll probably be easiest to use your existing app.yml, so try…

  • Copy app.yml to a new file, lets say restore.yml
  • Edit restore.yml and set the version
  • At the bottom of restore.yml edit the volumes section to change the paths so we don’t overwrite anything (lets say, change /var/discourse/shared/standalone to /var/discourse/shared/restore)
  • Save and exit
  • Stop your current container ./launcher stop app
  • Build the restore container ./launcher rebuild restore
  • When that’s done load it up, get into the admin area and restore your backup
  • When that’s done, update the restore container by setting the version line back to what it was and running ./launcher rebuild restore (may need to do this multiple times because of the Postgres upgrade)
  • Site should be back up at the latest version.

That’s how I would do it, but I’m not sure if there is a better way or not.

(Matt) #7

Thanks for your help Cameron, but unfortunately no luck. Whenever I try to bootstrap, start or rebuild with an earlier version I get this error:



Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 14565 exit 1>

Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'

exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --verbose --without test --without development --retry 3 --jobs 4'", "su discourse -c 'bundle exec rake db:migrate'", "su discourse -c 'bundle exec rake assets:precompile'"]}


** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Not quite sure what to try next. Frustrating that officially restoring from older versions is supported, but in reality it’s not. :weary:

(Michael - #8

This is not an error but just a message. If you run a recent version of Postgres then this message appears. There is nothing to fix there, this should work fine.

If your backup fails to restore then there must be an error further on.

(Matt) #9

Hi Michael, thanks for your advice. I’ve looked further down and the only other error I can see is:

[2018-05-25 11:33:36] ERROR:  schema "restore" does not exist
[2018-05-25 11:33:36] EXCEPTION: psql failed
[2018-05-25 11:33:36] /var/www/discourse/lib/backup_restore/restorer.rb:327:in `restore_dump'

Would that likely be it? If so, can you advise on what I should do to correct it?

(Michael - #10

Yes, the line with the big word ERROR is the actual error.

What Postgresql versions are you running on both servers?

(Matt) #11

Thanks Michael, I’m just used to having errors flagged that aren’t always the cause of the error. I try not to assume…

A noob question sorry, how do I check what Postgresql versions I’m running? A Google search hasn’t revealed any info on how to check when you’re using Docker & Discourse that I could find.

(Matt) #12

Found it in the sql file of the backup: Dumped from database version 9.5.7

The destination version database version 10.3 (Ubuntu 10.3-1.pgdg16.04+1)

Given I can’t get into the server which the backup is from (hence the need for the backup), can anyone suggest a next step?

(Michael Brown) #13

There were some problems with restoring a backup few months ago but those have been all sorted out as far as we know.

Can you check the version of Discourse to which you are trying to restore the backup? It’ll show that in the admin panel:


Copy the version link and paste it here and we can take a look to see how old it is.

If you’re still having trouble getting it restored feel free to start a trial, upload the backup and email us to try restoring it. If it doesn’t restore on our platform that’s something we need to fix.

If it does then we’ll probably need to see your entire restore log to look further.

(Karl Romanowski) #14

In your web.template.yml or app.yml there is a section:

  version: tests-passed

change version: tests-passed to version: <commit_hash>

Release 1.8.3 would be:

version: 53f3c54e4de44238f90667753bd4ef9a4622e476

(Michael - #15

It’s pretty recent

[2018-05-25 03:32:08] Validating metadata...
[2018-05-25 03:32:08]   Current version: 20180521190040

@Karl_Romanowski older versions of Discourse cannot handle newer Postgresql versions, especially regarding backup/restore, so there is no point in reverting to an older Discourse version. That’s not going to solve anything.

(Matt) #16

Hi Michael, it’s v2.0.0.beta10 +170

I’ll test the trial and see how it goes.

(Gerhard Schlager) #17

We managed to fix and restore the backup.
Here is how we fixed the backup in case anyone is interested in the solution:

  • Extract the dump.sql.gz and uploads folder from the backup
  • Extract the dump.sql from the dump.sql.gz
  • Edit the dump.sql and remove the following line at the end of the file:
    CREATE TRIGGER users_email_readonly BEFORE INSERT OR UPDATE OF email ON public.users FOR EACH ROW WHEN (( IS NOT NULL)) EXECUTE PROCEDURE restore.raise_users_email_readonly();
  • gzip compress the dump.sql
  • Put the new dump.sql.gz and the original uploads folder into a new tar.gz file