Step-by-Step Guide: Migrating Your GitLab Server Backup to a New Server

  • Post author:
  • Post category:Linux
  • Post last modified:August 22, 2023


The migration process for GitLab server backup means a successful data transition from one server to another server. This process is done if the both the GitLab servers have same version and prerequisites.

This guide provides you clear instructions and explanations, how to make migration process more efficient, even for users with limited technical expertise.

Before performing migration activity, review the target server, such as installing GitLab version and system requirements. If the GitLab versions are mismatched on both servers, then perform the necessary operations by upgrading or Downgrading Gitlab server versions. Then, the backup is transferred from the source server to the target server using secure file transfer methods.

Step 1:

Take Backup on Source server

To create a backup on your current server, you can use the GitLab following command

$ sudo gitlab-rake gitlab:backup:create

Gitlab Take Backup

The process will start and system will automatically  create backup file with current timestamp at location  /var/opt/gitlab/backups/1685286600_2023_05_28_15.9.3-ee_gitlab_backup.tar

Gitlab Backup File

Step 2:

Installing Gitlab on target Server

You can easily install gitLab server on Ubuntu server following Link

Step 3:

Transfer Backup file to new Gitlab server.

The first step is to copy the backup from the source server. You can use various methods such as WinSCP, SFTP (Secure File Transfer Protocol), or a file synchronization tool like rsync. In my case I have used WinSCP to transfer file.

Gitlab Backup file transfer

After successfully transferring the GitLab server backup to the target server, you need to place the backup file in a location where it is easily accessible during the migration process.

Step 4:

Now, stop the processes which are related to the database by using the below commands.

sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq

You can verify status of the GitLab services by using the below command

sudo gitlab-ctl status

Step 5:

configure Gitlab repository path as configured in previous server in /etc/gitlab/gitlab.rb

git_data_dirs ({
“default” => {“path” => “/var/opt/gitlab/git-data”},
“alternative” => { “path” => “/var/opt/gitlab/gitstorage” }

Step 6:

Now, restore the backup by using the timestamp of the backup copy

sudo gitlab-rake gitlab:backup:restore BACKUP = 1685286600_2023_05_28_15.9.3-ee_gitlab_backup.tar

Step 7:

Restart the GitLab components by using the below command

sudo gitlab-ctl restart

Step 8:

Now check the GitLab by sanitizing the database as shown below

sudo gitlab-rake gitlab:check SANITIZE = true

ditest@test:~$ sudo gitlab-rake gitlab:check SANITIZE = true
Checking GitLab subtasks …
Checking GitLab Shell …
GitLab Shell: … GitLab Shell version >= 14.23.0 ? … OK (14.23.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell … Finished
Checking Gitaly …
Gitaly: … default … OK
alternative … OK
Checking Gitaly … Finished
Checking Sidekiq …
Sidekiq: … Running? … yes
Number of Sidekiq processes (cluster/worker) … 1/1
Checking Sidekiq … Finished
Checking Incoming Email …
Incoming Email: … Reply by email is disabled in config/gitlab.yml
Checking Incoming Email … Finished
Checking LDAP …
LDAP: … LDAP is disabled in config/gitlab.yml
Checking LDAP … Finished
Checking GitLab App …
Database config exists? … yes
All migrations up? … yes
Database contains orphaned GroupMembers? … no
GitLab config exists? … yes
GitLab config up to date? … yes
Cable config exists? … yes
Resque config exists? … yes
Log directory writable? … yes
Tmp directory writable? … yes
Uploads directory exists? … yes
Uploads directory has correct permissions? … yes
Uploads directory tmp has correct permissions? … skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? … skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? … skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: …
… yes
… yes
… yes

Redis version >= 6.0.0? … yes
Ruby version >= 2.7.2 ? … yes (3.0.6)
Git user has default SSH configuration? … yes
Active users: … 46
Is authorized keys file accessible? … yes
GitLab configured to store new projects in hashed storage? … yes
All projects are in hashed storage? … yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x … skipped (Advanced Search is disabled)
All migrations must be finished before doing a major upgrade … skipped (Advanced Search is disabled)
Checking GitLab App … Finished
Checking GitLab subtasks … Finished
rake aborted!
Don’t know how to build task ‘SANITIZE’ (See the list of available tasks with rake --tasks)
/opt/gitlab/embedded/bin/bundle:25:in load' /opt/gitlab/embedded/bin/bundle:25:in

Read More related Topics

How to Downgrade Gitlab Server from to A step by step Guide.

Leave a Reply