Introduction:
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
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
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.
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 16.0.1.ee to 15.9.3.ee: A step by step Guide.
