fbpx

GitLabのバックアップを取ってみた #gitlab #gitlabjp

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。


 

GitLabは毎月22日に新しいバージョンをリリースしています。

リリースされた新しい機能を実装するためには、データのバックアップ+バージョンアップは運用面の重要なポイントとなり、避けて通れません。
今回は、Vagrant+VirtualBoX環境にOmnibusインストールで構築したGitLabサーバのバックアップ取得手順をご紹介します。

 

バックアップを取得する環境

  • CentOS7.5
  • Gitlab11.0.3-ee.0.el7(Enterprise Edition)

データは入っておらず、空のレポジトリ「panda」を1つ作成しました。

 

バックアップ情報の種類

GitLabのバックアップ対象は2種類に分かれています

(1)GitLab構成情報
(2)GitLabアプリケーションデータ

(1)は該当のディレクトリをtarで固めて退避、(2)はGitLabで用意されているコマンドを実行することで、それぞれのバックアップを取得します。

 

(1)GitLab構成情報のバックアップ取得

デフォルトでインストールされている場合、構成情報は/etc/gitlabに格納されています。
バックアップファイルを格納する任意のディレクトリで以下を実行します。

$ sudo tar cvzf /home/vagrant/yyyymmdd.tar.gz -C /etc gitlab


(実行例)
$ sudo tar cvzf /home/vagrant/yyyymmdd.tar.gz -C /etc gitlab
gitlab/
gitlab/gitlab-secrets.json
gitlab/trusted-certs/
gitlab/gitlab.rb

出来上がったtarファイルのサイズは約30KBでした。

 

(2)アプリケーションデータのバックアップ取得

次に、アプリケーションデータのバックアップを行います。
アプリケーションデータのバックアップのために、GitLabではコマンドが用意されています。

$ sudo gitlab-rake gitlab:backup:create


(実行例)
$ sudo gitlab-rake gitlab:backup:create
Dumping database ...
Dumping PostgreSQL database gitlabhq_production ... [DONE]
done
Dumping repositories ...
* root/panda ... [SKIPPED]
* root/panda.wiki ... [SKIPPED]
done
Dumping uploads ...
done
Dumping builds ...
done
Dumping artifacts ...
done
Dumping pages ...
done
Dumping lfs objects ...
done
Dumping container registry images ...
[DISABLED]
Creating backup archive: 1531369164_2018_07_12_11.0.3-ee_gitlab_backup.tar ... done
Uploading backup archive to remote storage ... skipped
Deleting tmp directories ... done
done
done
done
done
done
done
done
Deleting old backups ... skipping

コマンドを実行後、デフォルトの設定だと/var/opt/gitlab/backups以下にtarファイルができるので、それが生成されているかを確認しましょう。

 

バックアップファイルの保存先変更

tarファイルの格納先を指定したい場合は、/etc/gitlab/gitlab.rb中の「gitlab_rails['backup_path']」を書き換えます。

試しに、デフォルト保管先以外の場所を指定してみます。

$ sudo vi gitlab.rb

ファイルを編集モードにし、以下のように修正し、保存します。

(修正前)

### Backup Settings
###! Docs: https://docs.gitlab.com/omnibus/settings/backups.html
# gitlab_rails['manage_backup_path'] = true
# gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

↓  ↓  ↓

(修正後)

### Backup Settings
###! Docs: https://docs.gitlab.com/omnibus/settings/backups.html
gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups2"


$ sudo gitlab-ctl reconfigure
$ sudo gitlab-rake gitlab:backup:create

でバックアップを実行すると、/var/opt/gitlab/backups2にtarファイルが生成されました!

この時、gitlab-rake gitlab:backup:createを実行する前に予め/var/opt/gitlab/backups2のディレクトリを作成し、
パーミッションもデフォルトの格納先と合わせておいたのですが、存在しないディレクトリを指定した場合の挙動が気になりました。

そこで、バックアップ実行前に存在しないディレクトリ(/var/opt/gitlab/backups3)を指定してみたところ、
ファイル編集後に実行するgitlab-ctl reconfigureの処理の中でディレクトリを作成していました。(※)

(reconfigureの標準出力から抜粋)

* storage_directory[/var/opt/gitlab/backups3] action create
* ruby_block[directory resource: /var/opt/gitlab/backups3] action run
- execute the ruby block directory resource: /var/opt/gitlab/backups3

※ファイルの編集が終わったら、設定を反映させるために$ sudo gitlab-ctl reconfigure を忘れずに実行しましょう。

 

バックアップの保管場所について

バックアップコマンドを実行すると、このようなファイル名のtarファイルが生成されました。

1531379488_2018_07_12_11.0.3-ee_gitlab_backup.tar

なお、ファイルサイズはインストールして空のレポジトリを作っただけの状態で、100KB弱でした。

取得した構成情報のバックアップファイルと、アプリケーションデータのバックアップファイルはセキュリティの観点から、
別の場所に保管することが望ましいとのことです。保管場所、保管方法についてもよく検討しましょう!

 

実運用のイメージ(cron利用)

(1)構成情報は週次で、(2)アプリケーションデータは日次でバックアップを取ることを想定してcronを設定してみます。
うまく動くでしょうか。

日次

/etc/cron.daily以下に以下の実行ファイルを配置

# cat /etc/cron.daily/gitlabrake-backup
echo "######### start daily backup #########" >> /home/vagrant/gitlabrake-backup.log
echo ""`date`"" >> /home/vagrant/gitlabrake-backup.log
sudo gitlab-rake gitlab:backup:create >> /home/vagrant/gitlabrake-backup.log

日次バックアップコマンドは標準出力が出てrootにメールが飛ぶので、ログにリダイレクトしています。
今回、検証環境なので/home以下にログ出力していますが、実運用では/var等になると思います。

週次

/etc/cron.weekly以下に以下のコマンドを書いたファイルを配置

tar cfz /home/vagrant/$(date "+etc-gitlab-%Y%m%d%S.tar.gz") -C / etc/gitlab

/etc/cron.d/dailyjobsを編集します。

# cat /etc/cron.d/dailyjobs
# Run the daily, weekly, and monthly jobs if cronie-anacron is not installed
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# run-parts
50 16 * * * root [ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.daily
00 17 * * 3 root [ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.weekly
42 10 1 * * root [ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.monthly

日次バックアップは16時50分に、週次バックアップは水曜日(本日)の17時00分に設定しました。

結果、設定した時刻にそれぞれバックアップファイルが取得されていました!
 
 
日次バックアップ
デフォルトのディレクトリ、/var/opt/gitlab/backups以下にファイルが作られました。

# ls -ltr
total 460
-rw-------. 1 git git 92160 Jul 12 13:19 1531369164_2018_07_12_11.0.3-ee_gitlab_backup.tar
-rw-------. 1 git git 92160 Jul 25 16:19 1532503175_2018_07_25_11.0.3-ee_gitlab_backup.tar
-rw-------. 1 git git 92160 Jul 25 16:25 1532503545_2018_07_25_11.0.3-ee_gitlab_backup.tar
-rw-------. 1 git git 92160 Jul 25 16:45 1532504752_2018_07_25_11.0.3-ee_gitlab_backup.tar
-rw-------. 1 git git 92160 Jul 25 17:11 1532506300_2018_07_25_11.0.3-ee_gitlab_backup.tar  ← ← ← バックアップファイル

 
週次バックアップ

# ls -ltr
total 40
drwxrwxr-x. 2 vagrant vagrant 166 Jul 23 17:32 old
-rw-r--r--. 1 root root 1992 Jul 25 16:45 gitlabrake-backup.log
-rw-r--r--. 1 root root 30692 Jul 25 17:00 etc-gitlab-2018072501.tar.gz ← ← ← バックアップファイル

 
 
今回稼働確認のために夕方に取得していますが、実運用では以下のように、火曜~土曜の夜中の1時に取得する(全営業日のバックアップを取得することを意味します)
といったような利用状況に合わせた設定をすることが多いと思われます。

0 1 * * 2-6 root [ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.daily

 
 
 
参考サイト:
https://docs.gitlab.com/omnibus/settings/backups.html

GitLab日本語情報サイト:
https://www.gitlab.jp/

GitLab社内活用事例:
GitLab CIを活用した英日翻訳改善
 
 

Gitトレーニングのご案内

日本で唯一のGitLab認定パートナーであるクリエーションラインがGit初心者向けにトレーニングを開催します。
詳細はこちらから。
 
 
クリエーションラインについて
クリエーションライン株式会社は日本で唯一のGitLab Authorised Partnerです。
GitLabのサブスクリプション販売、日本語サポートなど、提供サービスの詳細はこちらをご覧ください。
https://www.creationline.com/gitlab

新規CTA