はじめての GitLab バックアップ

バックアップが大切なことは説明不要だと思いますが、バックアップは障害からの復旧のための作業の一つでしかありません。バックアップの取得自体がリストアを保証しているわけではありません。バックアップを取っていたけど復旧ができなかった事例もあります。復旧できるようバックアップを取得する必要があります。

GitLab Omnibus Package には gitlab-backup コマンドが同梱されています。このツールはデータバックアップ用であり、OS ごと吹っ飛んだ場合などのゼロからのリストアのためには追加の作業が必要です。

• OS 自体をリストアできるよう、OS 及び構成情報のバックアップが別途必要です。
• GitLab の構成情報 (gitlab.rb / gitlab-secrets.json) も別途バックアップが必要です。
• 標準では GitLab のデータと同じストレージにバックアップが作成されますので、バックアップ場所を AWS S3 などに変更しなければなりません。

データバックアップさえあれば、最悪 OS や gitlab.rb ファイルは記憶を頼りになんとかなるでしょと思う方もいるかもしれません。しかし、gitlab-secrets.json ファイルはそうはいきません。これには、CI/CD 変数をはじめとするいくつかのデータの暗号化用共通鍵が含まれています。バックアップを忘れると GitLab の一部が機能しなくなります。

gitlab-backup コマンドでのバックアップに手間がかかるということは、リストアもその分だけ手間がかかるということです。リストア手順書としてまとめてそれをテストする必要があるため、手間がかかればかかる分だけ運用コストが上昇します。

こういったことに手間をかけられない場合は、クラウドサービスの仮想マシンのスナップショットバックアップ機能がおすすめです。GitLab のデータだけでなく、構成ファイルや OS もまとめてバックアップができます。

シングルノード構成 (一台のサーバーに Omnibus Package をインストールする最も単純な構成) であればバックアップの設定も簡単です。仮想マシンの構成情報もバックアップに含めてしまえば、リストアも数クリックで済みます。リストア手順書の作成もテストも簡単です。

最後になりますが、バックアップの手段が何であれ、リストア試験は必ず行ってください。可能な限り消防訓練のように定期的に行ってください。前任者からの引き継ぎで「バックアップはあるよ」と言われても安心しないでください。

バックアップは障害対応の最後の砦です。他の何よりも優先してください。バックアップより優先すべきなのは安全性くらいです。バックアップやリストアの体制が取れない場合は GitLab.com への移行を検討してください。