docker版GitLabの、データリカバリ方法について

概要

以前構築した社内GitLabサーバーのHDDが危険な状態になっておりまして、急遽別マシンにGitLabを稼働させ、バックアップファイルからデータを復元させました。

特に問題なく復元できたのですが、リカバリ操作の備忘録として記事にまとめておこうと思います。あくまで備忘録ですので、結果を保証するものではございません。

ゴール

新しく構築するGitLabのバージョンを、バックアップ元のGitLabバージョンと一致させる

そう、バックアップからデータを復元するには、バックアップファイルを取得したGitLabのバージョンと、復元先のGitLabのバージョンが一致している事が条件になります。前環境ではWindowsサーバーにバックアップファイルを退避しており、そのファイルを確認すると、以下のファイル名となっています。

1760288455_yyyy_mm_dd_17.11.2_gitlab_backup.tar

年月日の次がGitLabのバージョンに当たりますので、「17.11.2」と言う事になります。

続いて、GitLabのdocker用composeファイルにバージョンを記述する必要がありますが、正式に何と記述すれば良いのかを公式サイトを使って確認します。
https://hub.docker.com/r/gitlab/gitlab-ce/tags

続いて上記のバージョンを、dockerのcompose.yamlに設定します。以下がcompose.yamlです。

services:
  web:
    #    image: 'gitlab/gitlab-ce:latest'    # ←以前のimage設定。
    image: 'gitlab/gitlab-ce:17.11.2-ce.0'   # ←上で調べた使用バージョンを限定した記述
    restart: always
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://xxx.xxx.xxx.xxx:8929'
        nginx['listen_port'] = 80

    ports:
      - 8929:80
      - 2224:22
    volumes:
      - '/srv/gitlab/config:/etc/gitlab'
      - '/srv/gitlab/logs:/var/log/gitlab'
      - '/srv/gitlab/data:/var/opt/gitlab'

コンテナを実行して正常に稼働するかを確認します。config関係はホスト側の「/srv/gitlab/config/」に配置されていますので、コンテナ起動前に入れ替えておきました。コンテナ起動後に入れ替えても、「reconfigure」コマンド使えば問題ないと思います。

$ docker compose up -d

リストアコマンドの実行

いよいよリストアを実行します。手順は簡単です。

1. バックアップファイルをGitLabのBackupsディレクトリに配置
2. コンテナに入る
3. DB操作しているサービスを停止する
4. リストアコマンド実行
5. GitLabサービスの再起動
6. 動作確認

1.バックアップファイルをGitLabのBackupsディレクトリに配置

配置する前に、GitLabのバックアップファイル配置場所がどこなのかを確認します。ホスト側の/srv/gitlab/configディレクトリにある「gitlab.rb」を開きます。

・・・
gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
# gitlab_rails['backup_gitaly_backup_path'] = "/opt/gitlab/embedded/bin/gitaly-backup"

###! Docs: https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html#backup-archive-permissions
gitlab_rails['backup_archive_permissions'] = 0644

# gitlab_rails['backup_pg_schema'] = 'public'

###! The duration in seconds to keep backups before they are allowed to be deleted
gitlab_rails['backup_keep_time'] = 604800
・・・

以前設定していたようで、設定されている通り「/var/opt/gitlab/backups」がバックアップファイルを取り扱うディレクトリです。この表現はコンテナ内のディレクトリになりますので、ホスト側ではcompose.yamlで指定している「/srv/gitlab/data/backups/」となります。

$ sudo cp [バックアップファイル] /srv/gitlab/data/backups/

2.コンテナに入る

以降はコンテナ内でコマンド実行しますので、コンテナに入ります。

$ docker exec -it gitlab-web-1 /bin/bash

3.DB操作しているサービスを停止する

$ gitlab-ctl stop unicorn	→要らないかも。
$ gitlab-ctl stop puma
$ gitlab-ctl stop sidekiq

「/var/opt/gitlab/backups」に移動し、バックアップファイルの所有者が「git:git」になっているか確認します。参考にしたサイトにそんな事が書かれていた気がします。

$ cd /var/opt/gitlab/backups
$ ls -al

4.リストアコマンド実行

$ gitlab-rake gitlab:backup:restore

バックアップディレクトリには、復元対象のファイルのみを配置した状態で上記コマンドを実行します。ファイル名を指定するオプションもあると思いますが、参考サイトが１ファイルで実行しておりましたので踏襲しました。実行して暫くすると、処理を継続するかを２回聞かれます。「yes」で進みますが、１回目を回答したあとエラーが表示されました。

拡張機能の「pg_trgm」「btree_gist」について、所有権が必要と言う事でしょうか。一通り調べましたが本エラーを解決する方法は見つからず。GitLabは内部でPostgreSQLを使用しているようですが、テキスト検索時、高速類似度検索を行う為の拡張機能のようです。元のGitLabでもそのような拡張設定はしていなかったので、無視する事としました。

5.GitLabサービスの再起動

ほどなくして復元実行が終了しますので、以下のコマンドでGitLabサービスを再起動させます。こちらもコンテナ内で実行します。

$ gitlab-ctl reconfigure
$ gitlab-ctl restart

6.動作確認

GitLabのサイトに入り、リポジトリ、ユーザー等、復元されている事を確認。ローカルにあるコードと同じリポジトリをCloneし、WinMergeのフォルダ一致確認も実施して問題ない事を確認。

これにてリカバリ操作は完了です。実際には、コマンドが正しく実行されるのかを確認する為に、GitLabを新規に稼働させただけの状態でバックアップを実行し、出来たバックアップファイルを復元させる、と言うテストなんかもしております。

定期バックアップの設定について

現在設定している定期バックアップ方法も記載しておきます。旧サーバーでも同じ設定でバックアップを取っておりました。

• バックアップ用シェルスクリプト
• cron設定
• mount設定
• 参考サイト

バックアップ用シェルスクリプト

# !/bin/sh

BKDIR=/srv/gitlab/data/backups

# Creating backup archive
# →BKDIRにバックアップファイルが作成される
docker exec -t gitlab-web-1 gitlab-backup create

# Create config backup archive
# /srv/gitlabにあるconfigディレクトリを、BKDIR/config内にアーカイブする。
tar cfz $BKDIR/config/$(date "+%s_%Y_%m_%d_17.11.2_gitlab_etc.tar.gz") -C /srv/gitlab config

# Delete old config backups
find $BKDIR/config -mtime +6 | xargs rm -rf

# Sync to Backup Server
rsync -auv --delete $BKDIR /mnt/gitlab_backup

$ sudo chown root: gitlab_backup.sh
$ sudo chmod +x gitlab_backup.sh

このシェルスクリプトでは、「/srv/gitlab/data/backups」配下のconfigディレクトリに設定ファイルのバックアップを作成する事になっていますが、初回は「config」フォルダは存在していません。なので実行するより前に作っておく必要があります。

$ sudo mkdir /srv/gitlab/data/backups/config

cron設定

$ sudo su -
$ crontab -e

# 毎日午前2時に、bashでスクリプトを実行
0 2 * * * bash /home/yamaken/gitlab/gitlab_backup.sh > /var/log/gitlab_backup.log CRON=1
　

実行指定の後、1行空行が必要との事です。

mount設定

上記のシェルを定期実行させる事で、ホスト側のローカル内にバックアップが作られます。今回のようにホスト本体のHDDが壊れる事もありますので、外部デバイスにデータを逃がします。

$ cd /mnt
$ sudo mkdir gitlab_backup
$ sudo mount -t cifs -o username=xxx,password=yyy //{your_network_address}/{your_shared_path} /mnt/gitlab_backup

これだけだと、ホストマシンを再起動した後はマウントが解除されてしまいますので、再起動後、自動でマウントするように設定しておきます。

$ sudo nano /etc/rc.local

上記ファイルを開き、一つ前で実行したmountコマンドを記述しておきます。

参考サイト

• https://blackbird-blog.com/gitlab-backup
• https://qiita.com/TomoyukiSugiyama/items/e9da7c873654cb86a14d