GitLabのデータバックアップ方法

IT

以前、自前で趣味で構築して社内向けに公開したGitLabサーバですが、気がついたら利用者が増えていました。さて、そうなると万が一に備える必要が出てきます。今回はギットラボのバックアップについて書きます。

スポンサーリンク

準備

今回使うGitLabサーバについて(おさらい)

万が一というのは、例えばサーバが故障してGitLabにコミットされたファイルが消失してしまった場合に、使っていた人たちが積み上げた資産がまるごと消失してしまうわけです。これは「ごめん」では済みませんね。大損害ですから。こういう時にSaaSのマネージドGitLabは有料で月々お金取られますが、面倒なこと考えなくてよいからお手軽でいいですね。自前で構築すると月々無料な分、頑張らないと行けないところもあります。

さて、自前構築組はどうするか。
答えは自分でGitLabのバックアップをする!

この記事ではGitLabのバックアップ(退避)とリストア(復元)のやり方について紹介します。

今回使う環境
  • Ubuntu
  • Docker
  • GitLab CE (Docker版) を2環境

Docker版のGitLabを使っていますので、Docker版じゃない場合は適宜読み替えてください。GitLabは2つ使います。一つはバックアップ対象のGitLab。もう一つはバックアップしたデータをリストアするGitLab。

GitLabのバージョン確認

バックアップ元とリストア先のGitLabはバージョンは同じである必要があります

リストア先のGitLabはバックアップ元のGitlabとマイナーバージョンも含めてすべて完全一致のものを用意してください。

マイナーバージョンぐらい違っても大丈夫じゃない!? と思って試したのですが、ダメでした。GitLabのバージョンは確認して、両環境のGitLabのバージョンが同じか確認しておいてください。

バージョンが違った場合

バージョンが一致していた場合は、ここは読み飛ばしてください。
ちなみに私の時は、こんな感じでズレてました。今回新しく予備のGitLabサーバを作ったのですが、前に作った時よりバージョンが新しくなってしまいました。

バックアップ元:12.1.6
リストア先:12.5.4

バージョンが異なる場合、バックアップはできますが、それをリストアすることができません。そのため、どちらかのGitLabのバージョンを変更しなければなりません。

バックアップ対象のGitLabのバージョンを変更するより、リストア先のGitLabのバージョンをバックアップ元に合わせるのが良いでしょう。

GitLabのバージョンを変更

これはDocker版なら簡単です。コンテナが動いている場合は停止します。
その後、リストア先のGitLabのコンテナとイメージを削除します。

$ docker-compose down
$ docker image rm gitlab/gitlab-ce

実行するとこのようなメッセージが表示されるかも知れませんが問題ありません。

Untagged: gitlab/gitlab-ce:latest
Untagged: gitlab/gitlab-ce@sha256:e8418e2449ca13a0ee5b2fe7803f31e09c67bb8e4445120e212eddd8670b6ada
Deleted: sha256:0f070900f085da55f98e3e28083e3dc9fe801bdce9ee50ef32afb7afa331191a
Deleted: sha256:6105850bbd1c6799758c11420ec66c5b0ae48b5cad2e6c15fc2f0762fca13300
Deleted: sha256:661f53c29a4d8cca45c74bf046fa2ba670f0269d5b3f8f77ebbc8317c62ce301
Deleted: sha256:5af34018b59d494ac62c1d23c1309c319e8db892ff2b8cd7791a8a491add9f2e

Dockerリポジトリからバージョンを指定して取得

これが私が使っているdocker-compose.yamlファイルですが、imageの部分を見ると、latestになっていますので、常に最新版を取得するようになっていました。これだと、イメージを取得するタイミングが変わるとバージョンが変わってしまいます。

gitlab:
  container_name: gitlab01
  image: 'gitlab/gitlab-ce:latest' ← ここです
  restart: always
  hostname: 'localhost'
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://local-gitlab'
      gitlab_rails['time_zone'] = 'Asia/Tokyo'
  ports:
  - '80:80'
  - '2022:22'
  volumes:
  - '/docker/gitlab/config:/etc/gitlab'
  - '/docker/gitlab/logs:/var/log/gitlab'
  - '/docker/gitlab/data:/var/opt/gitlab'

GitLabのバージョンを指定して、バックアップ元と同じバージョンのイメージを取り直すようにdocker-compose.yamlを修正します。

image: ‘gitlab/gitlab-ce:latest’

image: ‘gitlab/gitlab-ce:12.1.6-ce.0

過去のバージョンの探し方

公式サイトで過去のバージョンのイメージ名を探してください

Docker Hub

書き換えたら保存して、docker-composeします。

$ docker-compose up -d

バージョンの指定がうまくいくと、このような感じで指定したバージョンのGitLabのイメージを取得が始まり、取得でき次第、GitLabが起動します。

Pulling gitlab (gitlab/gitlab-ce:12.1.6-ce.0)...
12.1.6-ce.0: Pulling from gitlab/gitlab-ce
f7277927d38a: Pull complete
8d3eac894db4: Pull complete
(省略)

GitLabが起動したら、先程のバージョン確認方法で念の為、確認してください。

バージョン合わせを実施した方はお疲れさまでした。いよいよ次からバックアップ本編です。私はそもそもバージョン合わせる必要がことすら知らなかったので、ちょっと大変でした…

スポンサーリンク

バックアップ・リストア

バックアップ方法

バックアップ元のGitLabコンテナへ接続

バックアップするデータの取得は、gitlab-rakeコマンドを実行するだけです。まずはGitLabのコンテナに接続します。docker-compose.yamlでコンテナ名「gitlab01」で定義しているので、その前で接続しています。コンテナ名を付けていない場合は、docker psでコンテナIDがわかるのでそれを指定します。

GitLabのコンテナ内に入ると、プロンプトがroot@localhost: /# に変わります。

$ docker exec -it gitlab01 /bin/bash
root@localhost:/# 

GitLabのバックアップコマンド実行

GitLabのコンテナに接続できたら、GitLabのバックアップコマンドを実行します。実行するといろいろ表示されますが、ここでは割愛します。最後にBackup task is done.と表示されればバックアップ完了です。

root@localhost:/# gitlab-rake gitlab:backup:create
(省略)
Backup task is done.
root@localhost:/# 

バックアップファイルの確認

作成されたバックアップファイルを確認しましょう。
/var/opt/gitlab/backupsの下にtarファイルが生成されます。
うんうん、無事にできてますね。バックアップ側での作業は完了です。

root@localhost:/# ls -l /var/opt/gitlab/backups/
total 82220
-rw------- 1 git git 84193280 Dec 25 09:41 1577266883_2020_01_31_12.1.6_gitlab_backup.tar
root@localhost:/#
root@localhost:/# exit
exit
$ 

私の場合はdocker-compose.yamlを見ていただくとわかりますが、ボリュームの定義「’/docker/gitlab/data:/var/opt/gitlab’」でコンテナ内のファイルを外にリンクして出していますのでこれで完了ですが、もしGitLabのコンテナ内にバックアップファイルが作成された場合は、docker cpコマンドでGitLabのコンテナの外に出して置いてください。

スポンサーリンク

リストア方法

バックアップファイルの配置

バックアップファイルの配置場所は、バックアップ時にtarファイルが出力された場所と同じです。 GitLabのコンテナ内の /var/opt/gitlab/backups です。

私のdocker-compose.yaml設定では、コンテナ外とリンク作ってありますので、/docker/gitlab/data/backups に配置すればOKです。

GitLabのリストアコマンド実行

リストアにはバックアップの時と同様、gitlab-rakeコマンドを使いますので、リストア先のGitLabコンテナに接続します。

$ docker exec -it gitlab01 /bin/bash
root@localhost:/# gitlab-rake gitlab:backup:restore

実行すると、リストア先のGitLabのデータをすべて消して、バックアップの内容で置き換えます。画面はこんな感じで処理が進み、途中で2回処理を進めてよいか確認されます。

全部YesでOKです。リストア先のGitLabの内容が消えたらまずい場合や、あれ?この環境にバックアップの内容で差し替えちゃって本当に大丈夫なんだっけ?と不安なった方は一度止めて再確認しましょう。

Unpacking backup ... done
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)?

2020-01-13 12:49:23 +0000 -- Cleaning the database ...
...
2020-01-13 12:50:13 +0000 -- done
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

Deleting tmp directories ... done
...
done
Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need to restore these files manually.
Restore task is done.

Restore task is done.が表示されたら無事にリストア完了です。

リストア先のGitLabのWeb画面を表示してください。バックアップ元のGitLabと同じユーザでログイン出来て、中身も同じものになっていると思います。

スポンサーリンク

バックアップ取得の自動化

バックアップ・リストアの手順は確立できました。あとはこれを手動でやると面倒くさいのと、多分忘れてやらなくなると思います。いざという時にバックアップが取れていなかったということはよくありますので、定型業務はcronでも使って自動化しておくとよいと思います。

コメント

タイトルとURLをコピーしました