Thank you for reading this post, don't forget to subscribe!

у меня есть ста­рый сер­вер на centos 6 и gitlab 10.4.3

под­го­тав­ли­ва­ем новый сер­вер на centos 7 и ста­вим такую же версию:

yum install pygpgme yum-utils
yum install -y curl policycoreutils-python openssh-server

cat /etc/yum.repos.d/gitlab_gitlab-ce.repo

yum install -y yum-plugin-downloadonly

ста­вим нашу версию:
yum install gitlab-ce-10.4.3

пра­вим кон­фиг файл в соот­вет­ствии со ста­рым сервером:

vim /etc/gitlab/gitlab.rb

пере­за­пус­ка­ем реконфигурацию:
gitlab-ctl reconfigure

Так как с дис­ко­вым про­стран­ством у меня печаль беда, я на новом сер­ве­ре доба­вил диск в 100 гб  для переноса:

pvcreate /dev/sdc
vgcreate backup /dev/sdc
lvcreate -n backup -L 100G backup
mkfs.ext4 /dev/mapper/backup-backup
mount /dev/mapper/backup-backup /var/opt/gitlab/backups/
chown -R git:root /var/opt/gitlab/backups/
chmod 700 /var/opt/gitlab/backups/

что­бы ста­рый сер­вер смог создать бэкап я по nfs про­ки­ну этот диск, на новом сер­ве­ре (там же где и диск)
ставим:
yum install nfs-utils nfs-utils-lib -y
systemctl start nfs
systemctl start rpcbind

cat /etc/exports
/var/opt/gitlab/backups 10.230.244.186/32(rw,sync,no_root_squash,no_subtree_check)

exportfs -rav

 

теперь пере­хо­дим на ста­рый сер­вер и ста­вим nfs паке­ты чтоб под­ки­нуть нашу директорию:

yum install nfs-utils nfs-utils-lib -y
mount -t nfs 10.230.244.210:/var/opt/gitlab/backups /var/opt/gitlab/backups

chown -R git:root backups/

запус­ка­ем созда­ние бэкапа:
gitlab-rake gitlab:backup:create

дожи­да­ем­ся окон­ча­ния бэка­па (для объ­ё­ма в 30Gb тре­бу­ет­ся мини­мум 60Gb)

после мож­но сме­ло отмон­ти­ро­вать раздел:
umount /var/opt/gitlab/backups

пере­хо­дим на новый сервер
cd /var/opt/gitlab/
ещё раз пра­вим владельца:
chown -R git:root backups/

запус­ка­ем все про­цес­сы гитлаба:

gitlab-ctl start

сто­па­рим процессы:
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq

cd /var/opt/gitlab/backups/
и разворачиваем:

gitlab-rake gitlab:backup:restore BACKUP=1621239484_2021_05_17_10.4.3

даль­ше появят­ся вопро­сы про пере­за­пись дан­ных, отве­ча­ем yes

ну и всё дан­ные перенеслись.
даль­ше запус­ка­ем гитлаб
gitlab-ctl start

и про­ве­ря­ем
gitlab-rake gitlab:check SANITIZE=true

+ пра­вим вла­дель­ца regiistry:

chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker/

а то не будут обра­за пушится

====================================================================================================

 

ВОЗМОЖНЫЕ ПРОБЛЕМЫ:

при пере­ез­де на новый сер­вер пере­ста­ли рабо­тать ci/cd pipeline вот с такой ошибкой:

The scheduler failed to assign job to the runner, please try again or contact system administrator

при запус­ке на ране­ре команды:
gitlab-runner -debug run
вхож­де­ний со сто­ро­ны гит­ла­ба нету,
вот тут:
https://docs.gitlab.com/ee/raketasks/backup_restore.html#when-the-secrets-file-is-lost
нашёл реше­ние что нуж­но уда­лить пере­мен­ные, под­клю­ча­ем­ся к базе гитлаба:

gitlab-rails dbconsole   (про­хо­дит коман­да долго)

смот­рим

SELECT * FROM public."ci_group_variables";
SELECT * FROM public."ci_variables";

и уда­ля­ем:

DELETE FROM ci_group_variables;
DELETE FROM ci_variables;

Не забы­ва­ем пра­вить вла­дель­ца домаш­ней дирек­то­рии для gitlab-registry

chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker/

так как уда­ли­ли пере­мен­ные их надо создать, на ста­рой тач­ке смот­рим id про­ек­тов где есть переменные:

под­клю­ча­ем­ся:
gitlab-rails dbconsole

и дела­ем запрос:

gitlabhq_production=> SELECT project_id FROM public."ci_variables"

полу­чим результат:

если нуж­но исклю­чить из поис­ка какую-то переменную(в моём слу­чае kubeconfig) то мож­но сде­лать запрос:

gitlabhq_production=> SELECT project_id FROM public."ci_variables" where key not like '%kubeconfig%';

 

что­бы узнать назва­ние про­ек­тов по id, дела­ем запрос

SELECT * FROM public.projects where id = 526;

узнав имя про­ек­та  надо будет руч­ка­ми создать такую же сек­рет­ную пере­мен­ную  как и на ста­ром сер­ве­ре (увы я дру­го­го не придумал)

либо как ука­за­но вот тут:
https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab

ско­пи­ро­вать и подкинуть:

• /home/git/gitlab/config/secrets.yml
• /home/git/gitlab/config/gitlab.yml

но я это не тестил.

после чего по новой рега­ем ранеров(с новым реги­стра­ци­он­ным токе­ном) ииии пои­дее долж­но быть всё ок.

Кста­ти если были ssh клю­чи поль­зо­ва­те­лей они тоже похе­рят­ся, их надо будет сно­ва вруч­ную добавлять.