After migration, sync two instances?

I migrated gitlab from an old centosl 7 server to a rocky 9 server.
There was a long thread posted about the conversion and it worked but some things didn’t get in sync.
Now that I have both the new and the old servers running at the same versions, I’d like to find a way to 100% sync them up without having to go through any backup/restore process.

Is there a way of doing this?

Hi, there is no sync option for that. You have to use backup/restore.

I suggest that you stop the CentOS 7 server so that nobody uses it and point them to the Rocky server when you are finished. You cannot do a migration like that when people are still using the old server. You should have made the backup and then shut the old server down. Then install the same version of Gitlab on Rocky, that was installed on CentOS 7 and then restore the data (Gitlab can only be restored to the same version, so if backup was taken on 15.0.5 then it can only be restored to 15.0.5). Then upgrade from that version to the latest after the restore.

Hi, Yes, I went through all this before, backing up and restoring to the new server. However, some things never made it across to the new server and I hoped there might be a way to sync them up later without having to backup/restore.

Pretty sure I can do it using git commands as I think about it.

There is a possibility of using git commands, if it’s just stuff from the repositories that are missing. If relating to issues, then will be more difficult rather impossible.

There is also push mirroring from one repo to another on a different server, so that when a commit is made on the old server it will push to the new one. Pull mirroring is only possible with a subscription, push can be used for free. But again, this only refers to things missing from the repository, it doesn’t include issues. Whether that will be possible or not though is another matter but perhaps worth a shot.

A backup/restore would normally contain everything, I’ve never had a restore happen that has missed something out. Unless the backup didn’t contain it in the first place due to being omitted from the backup (this is possible to do by only specifying what to backup).

I understand and in my other post, you said the same, never seen it happen but it happened to me and it was documented in the post. Now I’m stuck on rocky 9 but that’s better than centos 7.9 :). However, I never got to use the new server since not all of the files showed up in the restore.

I’ll try another backup/restore now and see what happens between the two servers running all the same versions again.

Errors;

2023-06-12 21:23:12 UTC -- done
Restoring PostgreSQL database gitlabhq_production ... ERROR:  must be owner of extension pg_trgm
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension btree_gist
ERROR:  must be owner of extension pg_trgm

**SNIP**

Then later...

2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/backup_information.yml
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/db
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/repositories
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/uploads.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/builds.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/artifacts.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/pages.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/lfs.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/terraform_state.tar.gz
2023-06-12 21:26:32 UTC -- Cleaning up /var/opt/gitlab/backups/packages.tar.gz
2023-06-12 21:26:32 UTC -- Deleting tar staging files ... done
2023-06-12 21:26:32 UTC -- Deleting backups/tmp ...
2023-06-12 21:26:32 UTC -- Deleting backups/tmp ... done
2023-06-12 14:26:32 -0700 -- Deleting backup and restore lock file
rake aborted!
Errno::ENOENT: No such file or directory - /var/opt/gitlab/backups/registry.tar.gz
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/files.rb:97:in `run_pipeline!'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/files.rb:60:in `restore'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:104:in `run_restore_task'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:237:in `block in run_all_restore_tasks'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:235:in `each_key'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:235:in `run_all_restore_tasks'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/manager.rb:79:in `restore'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:26:in `block (4 levels) in <top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:203:in `lock'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:23:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
Tasks: TOP => gitlab:backup:restore
(See full trace by running task with --trace)
Transfering ownership of /var/opt/gitlab/gitlab-rails/shared/registry to registry

No idea what it’s talking about here;
Errno::ENOENT: No such file or directory - /var/opt/gitlab/backups/registry.tar.gz

Nothing was ever mentioned of such a file?

All of the numbers are the same. Same number of projects, stats etc. Seems like it worked even with the above errors.

That error “just” means that any registry you might have had wasn’t in the backup. When you use SKIP=registry to leave it out, it’s noted in the backup_information.yml in the backup, so I would think the restore was smart enough not to try extracting it. So either:

  • your old server didn’t have a registry and the backup process just didn’t make a file in the backup, I simply don’t remember what happens.
  • your transfer of the backup from the old to the new server was interrupted? If there is a bad network connection that would also explain why the first backup+restore you did failed to include even all repositories.
1 Like

It must be the first item you mention then because it seems to have gone perfectly.

Thank you.