Wrong version number on backup?

I’ve got a site running 2.5.0.beta2 ( c4bc734b11 ). For . . . reasons . . . I need to keep it an its plugins pinned to a particular version.

I’ve built a new container on a staging site with Discourse pinned to a commit and each plugin reset --hard to the same commit that the current production site is running. Now I want to restore a backup to make sure that this actually did what I think it did.

The backup file is named community-2020-06-10-163052-v20201303000002.sql.gz

And restoring it fails because:

Validating metadata...
  Current version: 20200320193612
  Restored version: 20201303000002

or, for readability:

Validating metadata...
  Current version: 2020 03-20-19:36:12
  Restored version: 2020 13-03-00:00:02

I vaguely remember that there was a problem with backups having the wrong version number, but I can’t find it.

I guess I need to just rename it to community-2020-06-10-163052-v20200303000002.sql.gz rather than community-2020-06-10-163052-v20201303000002.sql.gz?

EDIT: Renaming the backup file worked, at least for the database-only backup. . .

EDIT 2: And I was then able to restore a renamed full backup.

3 Likes

Can you check if a plugin has a DB migration with “20201303000002” in the filename?

1 Like

Darn. I don’t see such a filename or that string in any plugins. And it seemed like such a good explanation!

A Google search for that string finds this topic, and this: FIX: ensures migration order is correct (#27) - discourse-calendar - Discourse Reviews

Which pretty much explains what happened :slight_smile:

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.