You are browsing a read-only backup copy of Wikitech. The primary site can be found at


From Wikitech-static
< GitLab
Revision as of 17:50, 5 August 2021 by imported>Jelto
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search is a copy of production GitLab. Currently gitlab2001 is the replica of gitlab1001.

The purpose of the GitLab replica is:

  • to have a almost identical machine with production Gitlab to test changes
  • to verify the installation path developed by S&F for gitlab1001
  • to have a host for failover in case production GitLab breaks (WIP)
  • to have parity with gerrit-replica

The purpose is not to share the load between both GitLab instances.

Manual sync of replica

to manually sync of production GitLab with the replica the latest backups have to be moved from production GitLab to the replica:

cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3

When the backup archives are transferred to the replica the GitLab restore guide should be used. The exception here is that we have to keep the gitlab.rb from the replica when restoring the config backup. So make sure to copy the old gitlab.rb before following the guide.

sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak

When the restore is finished, the settings have to be reapplied to the replica using gitlab-settings:

./settings --instance update

Automated sync of replica

Automated sync is not implemented currently. The plan is to restore backups of production GitLab every 24 hours.


The usage of gitlab-replica should be mostly internal for testing, troubleshooting and in case of an emergency. Thus login with SSO needs the groups ops, wmf or nda.