Migration from 0.24.6 to rc1, failed, any help appreciated

Support
1

Hi,
I run a self-hosted Vikunja via Docker compose on Version 0.24.6., which worked great for many months. User Identities are linked to Google OpenID. Data on postgres.

I wanted to upgrade it last week to the latest rc1 version and simply changed
image: vikunja/vikunja:0.24.6
to
image: vikunja/vikunja:latest
in my Docker compose file.

However, I was not aware last week, that I need to change the config.yml due to the new syntax about openID.
Users could not login in. So I simply changed back to image: vikunja/vikunja:0.24.6
and forgot to restore the 0.24.6 Database. Unfortunately I was on vacation and did not realize the mistake.
So the database was already migrated to rc1 somehow, but ran again with a 0.24.6 container.

Meanwhile users entered a bit additional data in the “broken” setup.

If I switch now the docker image to “latest” and add the new Google openID syntax to the config.yml, users can login, but do not see any data.
It seems that the whole database is inconsistent.
If I run the 0.24.6 container, some data like teams seem broken/empty, but all personal tasks of the users are correct.

I tried dumping the damaged-half-migrated 0.24.6 database and do an restore. However, the restore into the rc1, does not work as versions need to be the same.
I also tried exporting individual data on 0.24.6 and import it on a fresh empty rc1 installation. This shows internal server errors.

Now, I am really lost, and need some ideas how to get out of this mess into a consistent rc1 installation.

Thanks a million.

2

Can you verify that the user account is the same id when you log in?

Another possibility might be that you’re hitting this issue: Critical error: invalid character 'd' looking for beginning of value · Issue #1339 · go-vikunja/vikunja · GitHub

Restoring only works in the same version, you can only restore a dump made in 0.24.6 in 0.24.6.

3

@kolaente your help is much appreciated (many coffees :slight_smile: )

yes, the user ID was the same.

Now I am trying another thing.

  1. I’ve dumped the running, “broken” 0.24.6. into a zip file with the dump command.
  2. Create a new empty 0.24.6 containers
  3. Restore the 0.24.6 dump into the empty 0.24.6 instance.
  4. Migrate the new 0.24.6. to rc1

However, I am stuck already with step 3:

sudo docker exec -it -u 0 -w /dumps Vikunja-1   /app/vikunja/vikunja restore /dumps/vikunja-dump_2025-08-31_21-09-39.zip
2025-09-01T11:38:38Z: INFO	â–¶ 001 Using config file: /etc/vikunja/config.yml
2025-09-01T11:38:38Z: INFO	▶ 002 Running migrations…
2025-09-01T11:38:38Z: INFO	â–¶ 06a Ran all migrations successfully.
2025-09-01T11:38:38Z: WARNING	â–¶ 06b Restoring a dump will wipe your current installation!
2025-09-01T11:38:38Z: WARNING	â–¶ 06c To confirm, please type 'Yes, I understand' and confirm with enter:
Yes, I understand
2025-09-01T11:38:44Z: INFO	â–¶ 06d The config file has been restored to 'config.yml'.
2025-09-01T11:38:44Z: INFO	â–¶ 06e You can now make changes to it, hit enter when you're done.

2025-09-01T11:38:46Z: INFO	â–¶ 06f Restoring...
2025-09-01T11:38:46Z: INFO	â–¶ 070 Using config file: /etc/vikunja/config.yml
2025-09-01T11:38:47Z: INFO	â–¶ 117 Wiped database.
2025-09-01T11:38:47Z: CRITICAL	â–¶ 119 could not create db structure: xormigrate: Tried to migrate to an ID that doesn't exist

Which ID is the restore command referring to?

4

Thanks for the coffees!

This sounds like there are leftovers from “newer” migrations from when you upgraded to the rc. Essentially, this is similar to downgrading, which is not supported.

What does the migrations.json file in the dump look like?

Did your users enter much data into the broken setup? Because if not, I would advise restoring from the backup you did before upgrading to the rc and then have them add the data manually again.

5

running out of time…
I’ve asked all 20 active users to export and import their tasks into a clean new 0.24.6 instance, and hope the migration will work from there.
As a future idea, it would be a great CLI to have a vikunja export format as-user-id command…

You’re really creating a great product. Please continue.

1 Like
6

You mean basically trigger an export for a user from the cli?

7

yes,
do what the export data in the UI does via cli on behalf of a user.
Then import it into another vikunja instances where the user ID might have changed.
this would be a migration path for broken databases like mine, or for merging teams etc.

But this is all low prio feature brainstorming.

Let’s close this one, as I’ve solved the urgent case.

1 Like