记一次gitlab服务器迁移做的事gitlab14.3.0->14.7.0

由于更换了服务器,新服务器使用的是全新的debian 11 bullseye系统,旧服务器是使用的debian 10 buster系统,并且旧服务器是一路升级上来的,甚至没有uefi启动,遂准备将旧服务器上的gitlab迁移到新的服务器上

旧服务器上的gitlab是14.3.0的系统,在迁移前发现debian 11支持的gitlab最低为14.6.0,所以第一步需要将旧服务器的gitlab先升级到debian 11能够支持的版本上,最新的gitlab是14.7.0,所以这里准备将旧的gitlab升级为14.7.0,如果您的版本不支持直接升级到最新版本请查看官方的说明文档按照官方的升级路径来进行升级。

先在旧服务器上执行下面的指令(采用包管理安装):

sudo apt update
sudo apt install gitlab-ee=14.7.0-ee.0

在升级完毕后测试是否正常,如果正常进入备份流程:

sudo gitlab-backup create

在备份目录中将文件拷贝到新服务器上
备份目录在:

/var/opt/gitlab/backups/

以上步骤完毕以后进入还原流程

首先按照正常方式安装相同版本的gitlab

sudo apt install -y curl openssh-server ca-certificates perl
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo apt install gitlab-ee=14.7.0-ee.0

然后将备份的配置文件移动到/etc/目录中,并执行reconfigure过程

sudo mv ./gitlab /etc/
sudo gitlab-ctl reconfigure

将拷贝的备份文件移动到新服务器的备份目录中,假设之前的备份文件名为:1643321661_2022_01_28_14.7.0-ee_gitlab_backup.tar,并将备份目录的权限授予git用户

sudo cp 1643321661_2022_01_28_14.7.0-ee_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git.git /var/opt/gitlab/backups/1643321661_2022_01_28_14.7.0-ee_gitlab_backup.tar

进行完上面的步骤后,停止连接到数据库的进程。让 GitLab 的其余部分保持运行状态:

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# 确认服务状态
sudo gitlab-ctl status

接下来,还原备份,指定要还原的备份的时间戳:

sudo gitlab-backup restore BACKUP=1643321661_2022_01_28_14.7.0-ee

这时候会问你是否确认,因为你确认的话,数据将会被覆盖,在执行这样的操作前请确认清楚自己在做什么,以免酿成不可挽回的后果。

Unpacking backup ... done
Be sure to stop Puma, Sidekiq, and any other process that
connects to the database before proceeding. For Omnibus
installs, see the following link for more information:
https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations

Before restoring the database, we will remove all existing
tables to avoid future upgrade problems. Be aware that if you have
custom tables in the GitLab database these tables and all data will be
removed.

Do you want to continue (yes/no)? 
WARNING

The "Write to authorized_keys file" setting is disabled, which prevents
the file from being rebuilt!

It should be enabled for most GitLab installations. Large installations
may wish to disable it as part of speeding up SSH operations.

See https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html

If you did not intentionally disable this option in Admin Area > Settings,
then you may have been affected by the 9.3.0 bug in which the new setting
was disabled by default.

https://gitlab.com/gitlab-org/gitlab/issues/2738

It was reverted in 9.3.1 and fixed in 9.3.3, however, if Settings were
saved while the setting was unchecked, then it is still disabled.
Do you want to permanently enable the "Write to authorized_keys file" setting now?
Do you want to continue (yes/no)? 

在还原完毕后,重新配置、重新启动并检查GitLab

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

在 GitLab 13.1 及更高版本中,可以解密检查数据库值,尤其是在还原时,或者如果其他服务器是还原的目标。/etc/gitlab/gitlab-secrets.json

sudo gitlab-rake gitlab:doctor:secrets

为了增加保证,您可以对上传的文件执行完整性检查:

sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check
暂无评论

发送评论 编辑评论


				
上一篇
下一篇