We are planning to migrate our present Gitlab on Centos 7.9 to a new server with Rocky Linunx 9.4.
Would it be sufficient to stop Gitlab, then perform the backup and afterwards do the
sudo scp /var/opt/gitlab/redis/dump.rdb @new-server:/var/opt/gitlab/redis
sudo scp /var/opt/gitlab/backups/your-backup.tar @new-server:/var/opt/gitlab/backup
?
If you stop Gitlab, then the backup won’t work since it needs the services running to do it.
Everything related to backup/restore you can find here: Back up and restore GitLab | GitLab
No, you do not need to copy the redis database, that is just what is in-memory when the server is running. You just restore, reconfigure and use the server.
Quick-step:
Install new server
Install same version of Gitlab on new server.
Take backup of old server
Copy /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json from old server to new server
Copy backup to /var/opt/gitlab/backups on new server
Run initial reconfigure to get Gitlab running
Run restore
Run reconfigure once more
Start using Gitlab.
It’s explained in more detail in the documentation.
Gitlab has official documentation for this - Migrate to a new server | GitLab
Many thanks for the Info.
I am running GitLab Version 15.3 on present server and have installed a later version (17.1) on new server. I guess there will be migration issues, so I have to downgrade to the same version of Gitlab on new server and do the upgrade after successful migration.
Yes, I was reading this before opening this query. I was just a bit uncertain with the many steps and setting changes needed before copying backup to target server. In case of a fallback (migration failure), I will need to undo all of these changes to get the old server back up and running.
I have to request a Gitlab service outage before I could perform this migration. Any idea how long this will take ?
That depends too much on your hardware (both the old and the new), the number of repos and several things about the actual repos, including but limited to:
So we have no way of saying anything specific. But if you take regular backups the time they take will give an indication. Restore is typically slower (but it’s different hardware). The best way to get an indication is probably to perform a trial run, you don’t need to do anything else on the old server than take a backup, for a trial run a backup taken while GitLab is being used should be fine, so there should be nothing in the process that causes any risk to the existing setup, just don’t point DNS (or whatever is used to determine which is authoritative) to the new.
Present and new Server for Gitlab are both VM Guests having the same system resources.
For the trial, I can run
sudo gitlab-backup create
without performing the necessary steps mentioned in the documentation ?
I will take a VM snapshot before doing this.
What VM solution? And are the guests on the same piece of hardware (some VM solutions allow you to select that a guest should have access to a certain number of CPU’s, but “a CPU” is just whatever is in the computer it runs on, i.e. not the same between hardware).
As I said it depends on a lot of other factors in addition to the hardware, so I don’t think it helps much.
A VM snapshot is nice to have, but it’s what is mentioned in step 1 of the procedure you posted a screenshot of. And in most cases a running CI/CD job or a running background job will not cause the backup to be unusable (for test, it might be unusable for restoring to a working system in a consistent state, but that’s not really your goal when you just do a test). So yes, you can skip steps 2-7 if you don’t intend to use the system you restore the backup taken in step 8 to.
Ok thanks again.
I was planning to downgrade Gitlab on the new server to Version 15.1 which is presently running but repo is just showing versions from 16.0 - 17.2 on new server running rocky Linux 9.4. How can I get version 15.1 and would this be compatible with rocky Linux 9.4 ?
.
I have no knowledge on how it works with rocky Linux, with Debian and derivatives (including Ubuntu), the recommendation is usually to install an older version and add an OS upgrade step among the GitLab upgrades.
Would migrating Gitlab with version 15.1 to another server with version 16.0 work ?
As mentioned on official docs:
You can only restore a backup to exactly the same version and type (CE/EE) of GitLab on which it was created.
Thanks!
Then I have to find out which Rocky Linux version/release Gitlab version 15.1 is available.
Presently our Gitlab is running on Centos 7.9 which is out of support and in our installation
we are mainly using rocky Linux now.
I have another option. Gitlab version 16 is available on Centos 7.9, so I will try to upgrade to
latest release on version 16 (16.9.1) from 15.1 and if successful, I will install the same on new Server running Rocky Linux 9.4 as this version/release is available there.
Best way is upgrade the CentOS 7.x one to the latest possible version of Gitlab and then at this point take a backup and restore it to the same Gitlab version on the new server.
Since older versions of Gitlab may not exist for Rocky 9.x.
I’m told fapolicyd can interfere with GitLab. Disabling that didn’t help me, unfortunately.
Here’s my ticket for that issue.
Good luck.
Many thanks for the heads up . I will check the repos after the migration .
This will be a tricky migration…
Present server with Centos 7.9 and Gitlab 15.3 only offers
16.9.1 version of Gitlab for upgrading.
Gitlab version 16.9.1 is available on new server running Rock Linux 9.4
For migration same version/release of Gitlab is required.
Due to reported CVEs, I will need to upgrade Gitlab on new server to at least version 17.2
after successful migration.
A fallback scenario for unsuccessful migration will be tedious.
I was able to upgrade from gitlab version 15.3.4-ce.0.el7 to latest 17.3.1-ce.0.el7 as the later Gitlab versions suddenly appeared on repos used by Centos 7.9. On the new server, running rocky Linux 9.4 Gitlab version 17.3.1-ce.0.el9 is installed.
Next step will be to create backup from 17.3.1-ce.0.el7 and restore this on 17.3.1-ce.0.el9
I was able to create a backup + and redis db dump on my present Gitlab server running Centos 7.9 and Gitlab 17.3.4 which tokk > 4 hours and almost requiring 1TB of additional disk space.
I noticed though that uid/gid of needed Gitlab users are different on present server and new server running Rocky Linux 9.4.
[root@ascgitlab ~]# grep -i gitlab /etc/passwd
gitlab-www:x:997:994::/var/opt/gitlab/nginx:/bin/false
git:x:996:993::/var/opt/gitlab:/bin/sh
gitlab-redis:x:995:992::/var/opt/gitlab/redis:/bin/false
gitlab-psql:x:994:991::/var/opt/gitlab/postgresql:/bin/sh
gitlab-prometheus:x:993:990::/var/opt/gitlab/prometheus:/bin/sh
gitlab-runner:x:992:989:GitLab Runner:/home/gitlab-runner:/bin/bash
registry:x:991:988::/var/opt/gitlab/registry:/bin/sh
[root@ascgitlab ~]# cat /etc/os-release
NAME=“CentOS Linux”
VERSION=“7 (Core)”
[root@digitlab1 ~]# grep -i gitlab /etc/passwd ; cat /etc/os-release
gitlab-www:x:986:986::/var/opt/gitlab/nginx:/bin/false
git:x:985:985::/var/opt/gitlab:/bin/sh
gitlab-redis:x:984:984::/var/opt/gitlab/redis:/bin/false
gitlab-psql:x:983:983::/var/opt/gitlab/postgresql:/bin/sh
gitlab-prometheus:x:982:982::/var/opt/gitlab/prometheus:/bin/sh
registry:x:981:981::/var/opt/gitlab/registry:/bin/sh
gitlab-runner:x:980:980:GitLab Runner:/home/gitlab-runner:/bin/bash
NAME=“Rocky Linux”
VERSION=“9.4 (Blue Onyx)”
Doing a restore on new server would probably have permission issues due to difference in uid/gid .
Any suggestion/s ?