この記事にはプロモーションが含まれていることがあります

Docker版GitLabのデータバックアップ・リストア方法 (backup/restore)

IT
2020.02.04

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

スポンサーリンク

準備

今回使うGitLabサーバについて（おさらい）

GitLabサーバを構築した時の記録

この記事のベースとなるGitLabサーバを構築した時の手順を記録したものです。参考までに。

GitLabを自分のパソコンや社内サーバで動かしてみる
最近のシステム開発プロジェクトのバージョン管理は、すっかりGitになりましたね。今どき、CVSやSVNを使っている現場は少なくなってきているのではないでしょうか。 私は40代、バリバリPGしていた頃はCVSでした。GitはCVSやSVNと概...
blackbird-blog.com
2020.01.13
LAN内へのGitLabサーバ設置に向けた設定変更備忘録
前回、練習用のGitLabサーバを構築しました。前回は私のこっそり練習の場を作りたかったので、とりあえず動かすことを優先したため、いろいろ適当でした。 ただ、社内で開発資材の管理をGitLabをやろうというタイムリーな話が出てきたので、きち...
blackbird-blog.com
2020.01.19

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

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

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

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

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

GitLabのバージョン確認

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

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

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

Docker版GitLabのバージョンを確認する方法
Docker版GitLabのバージョンを確認する方法 Dockerコンテナ版じゃない方は、目次１.２のGitLabのバージョン確認だけ実施すればよいと思います（たぶん） GitLabのコンテナにアクセス GitLabコンテナを特定する Do...
blackbird-blog.com
2020.02.01

バージョンが違った場合

バージョンが一致していた場合は、ここは読み飛ばしてください。
ちなみに私の時は、こんな感じでズレてました。今回新しく予備の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‘

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

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

https://hub.docker.com/r/gitlab/gitlab-ce/tags
hub.docker.com

書き換えたら保存して、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:/#
追加で手動バックアップが必要な場合もあるようです

Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.

このようなメッセージが場合は、gitlab.rbとgitlab-secrets.jsonを手動でバックアップする必要があるようです。

私の環境では、探してみたところ、GitLabコンテナの中のここにありましたので、これも一緒にバックアップしておきました。

root@localhost:/etc/gitlab# ls -l /etc/gitlab/
total 136
-rw------- 1 root root 15611 Jan  8 01:12 gitlab-secrets.json
-rw------- 1 root root 92446 Aug 21  2019 gitlab.rb

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

作成されたバックアップファイルを確認しましょう。
/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のデータをすべて消して、バックアップの内容で置き換えます。画面はこんな感じで処理が進み、途中で２回処理を進めてよいか確認されます。

全部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.rbとgitlab-secrets.jsonのバックアップをしている場合は、そのファイルも所定の位置に戻してください。

エラーが発生する場合は、一番下のトラブルシューティングを御覧ください。

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

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

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

スポンサーリンク

トラブルシューティング

エラーが発生する場合　2020.03.03 追記
Unpacking backup ... tar: 2020_03_03_12.1.6_gitlab_backup.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
unpacking backup failed

Cannot open: Permission denied　と言われていますので、データが詰まったtarファイルが開けないとのことです。パーミッションがDockerコンテナ内のユーザIDのみ読み書きになっていることが原因です。

chmodコマンドで666指定（全員読み書き可能）することでパーミッションを設定できます。設定したら、再度gitlab-rakeしてください。今度は成功するはずです。

# chmod 666 2020_03_03_12.1.6_gitlab_backup.tar

コメント

  1. 遠藤慎一 より:
    2020-05-18 09:27

    # gitlab-rake gitlab:backup:create
    の方法でバックアップを取得していました。

    2020年05月13日に12.10.3 にアップデートしたところ
    その後の最初のバックアップ実施で下記のエラーが出るようになりました

    調べて、また報告します

    rake aborted!
    Psych::SyntaxError: (): could not find expected ‘:’ while scanning a simple key at line 572 column 5
    /opt/gitlab/embedded/service/gitlab-rails/config/initializers/1_settings.rb:6:in `’
    /opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:5:in `’
    /opt/gitlab/embedded/bin/bundle:23:in `load’
    /opt/gitlab/embedded/bin/bundle:23:in `’
    Tasks: TOP => gitlab:backup:create => gitlab_environment => environment

    返信
  2. 遠藤慎一 より:
    2020-05-18 10:06

    判明です　　ご心配おかけしました
    バックアップ先の指定で、パーミションと保持時間の部分で
    コロンの後に空白を空けずに数字を記述してしまった、それだけでした。

    /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml で
    backup:
    path: “/var/opt/gitlab/backups”
    # Relative paths are relative to Rails.root (default: tmp/backups/)
    に書かれているので、ここを　変更します。
    path: “/backupWk” # Relative paths are relative to Rails.root (default: tmp/backups/)
    archive_permissions: 0644 # Permissions for the resulting backup.tar file (default: 0600)
    keep_time: 7200 # default: 0 (forever) (in seconds)

    返信
    • ばったん（プロフ詳細） ばったん より:
      2020-05-18 21:29

      遠藤さん

      はじめまして。

      ブログをご覧いただきありがとうございます。
      自己解決されたようで良かったです。

      12.10.3ですか、もうそんなにバージョン上がってるんですね^^;

      周りのエンジニアはだいたいGitLab.com使っていて、
      なかなか自前で立てる人いないので、ちょっと嬉しいです(^o^)

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