データ保護とシステム整合性の原則

エンタープライズ環境において、GitLabはソースコードと開発資産の中心的な役割を担います。データ消失を防ぐため、データベース、リポジトリ、アップロードファイル、ビルド成果物などを単一アーカイブにまとめたバックアップの取得は必須の運用タスクとなります。復元処理はバックアップ取得時と完全に一致するGitLabバージョンでのみ保証されるため、インフラの移行や災害復旧シナリオではバージョン整合性を最優先する必要があります。

保存パスと保持期間の定義

Omnibusパッケージの標準設定ではバックアップが /var/opt/gitlab/backups に格納されますが、ディスク容量の拡張性やバックアップ戦略の観点から、外部ストレージパスへの変更が推奨されます。設定はメイン構成ファイルを通じて行い、変更後は設定反映コマンドを実行してディレクトリの権限を自動調整させます。

# /etc/gitlab/gitlab.rb の追記箇所
archive_storage_base = '/mnt/backup_volumes/gitlab_snapshots'

gitlab_rails['backup_path'] = archive_storage_base
gitlab_rails['backup_keep_time'] = 604800  # 保持期間を秒単位で指定（7日間相当）

構成ファイルを編集後、以下のコマンドで設定を反映し、ディレクトリの所有権とアクセス権が git ユーザーへ適切に設定されることを確認します。

sudo gitlab-ctl reconfigure

保守スクリプトによるバックアップ実行

単一バックアップの取得は専用Rakeタスクで実施できます。運用の標準化を図るため、コマンド実行をシェル変数と条件分岐を用いた構造に再編成した例を以下に示します。実行が完了すると、指定パスに <EPOCH>_<YYYY>_<MM>_<DD>_<VERSION>_gitlab_backup.tar の命名規則でファイルが生成されます。

#!/bin/bash
BACKUP_ENGINE="/opt/gitlab/bin/gitlab-rake"
TARGET_DIR="/mnt/backup_volumes/gitlab_snapshots"

# ディレクトリ存在確認とバックアップタスクの呼び出し
if [[ -d "${TARGET_DIR}" ]]; then
    sudo "${BACKUP_ENGINE}" gitlab:backup:create
    echo "バックアッププロセスが正常に終了しました。"
else
    echo "エラー: 指定された保存パスが存在しません。"
    exit 1
fi

アーカイブファイルには、リポジトリデータ、Wiki、LFSオブジェクト、コンテナレジストリイメージなどが包括的にパッケージ化されます。

Cronデーモンによる定期実行の登録

企業の開発資産を保護するため、最低でも1日1回の完全バックアップを自動化すべきです。 CRON=1 環境変数を付与することで、正常終了時の標準出力を抑制し、エラー発生時のみ通知するように動作を最適化できます。

/etc/cron.d/gitlab_maintenance
----------------------------------
# 毎日 AM 2:00 に実行。進捗出力はエラー時のみ許可
0 2 * * * root /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

データ復元のプロセス

リポジトリの誤削除やサーバー障害が発生した場合、事前のアーカイブから状態を戻します。復元中はデータベースへの書き込み処理を完全に停止する必要があります。書き込みサービスが稼働したまま復元を行うと、データの不整合や破損を引き起こすため、以下の順序で実行してください。

#!/bin/bash
# 復元対象のタイムスタンプを指定（拡張子を除く数字部分のみ）
RESTORE_TARGET="1693500120_2023_08_31_15.4.0"

# 1. データベース書き込みプロセスの安全な停止
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq

# 2. サービス状態の検証
sudo gitlab-ctl status

# 3. データベースの既存テーブル削除とアーカイブからの展開・復元
sudo gitlab-rake gitlab:backup:restore BACKUP="${RESTORE_TARGET}"
# 対話プロンプトには「yes」で応答

# 4. 全サービスの再起動と稼働確認
sudo gitlab-ctl start
sudo gitlab-ctl status

プロセスが完了すると、Webインターフェース上で削除前のリポジトリ構造とコミット履歴が再現されます。

RPMパッケージの更新手順

システムを最新バージョンへ移行する場合、ダウンロードしたRPMパッケージを用いてアップグレードを行います。データ競合を防ぐため、更新前にネットワークアクセスとデータ書き込みサービスを遮断し、パッケージマネージャー経由でファイルの置き換えを実施します。

#!/bin/bash
NEW_PACKAGE="gitlab-ce-16.5.0-ce.0.el8.x86_64.rpm"

# 関連コンポーネントの停止
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop nginx

# パッケージの更新適用（依存関係解決とファイル配置）
sudo rpm -Uvh ${NEW_PACKAGE}

# 新しい設定の反映とサービス群の初期化
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

メジャーバージョン間の更新はデータベーススキーマの変更や非推奨機能の削除を含むため、本番環境に適用する前にステージング環境での検証が不可欠です。リスクを最小化したい場合は、新規サーバーに最新版をインストールし、バックアップファイルからインポートするマイグレーション方式が推奨されます。