Posted inCentos

CentOS Stream 9でBoom Boot Managerを使う：Boot EntriesとLVM Snapshotによるリストアポイント管理

CentOS tutorial - IT technology blog
CentOS tutorial - IT technology blog

昨日、チームの開発メンバーがproductionサーバーのkernelをアップデートしたところ、システムが起動に失敗してしまいました。スナップショットもなく、バックアップ用のboot entryもなく、rescue modeで3時間格闘する羽目に。sysadmin歴の長い人なら誰もが一度は経験したことのある、あの苦い記憶です。

そこで使い始めたのがBoom Boot Managerです。GRUB2でboot entriesを作成・管理できるツールで、LVM Snapshotと組み合わせることで、実際に使えるシステムの復元ポイントを構築できます。弊社にはまだCentOS 7で動いているサーバーが数台あり、AlmaLinuxへの移行はすでに対応済みの課題です。しかしCentOS Stream 9では、Boomのおかげでアップデートのたびに安心して眠れるようになりました。

5分でできる：最初のboot entryを作成する

細かい説明の前に、実際に試してどう動くか確認してみましょう。

ステップ1：Boomのインストール

dnf install boom-boot -y

ステップ2：OS Profileの作成

Boomは正しい構文でboot entriesを生成するために、OSの情報が必要です：

# プロファイルの確認
boom profile list

# なければ、現在のホストから自動作成
boom profile create --from-host

ステップ3：テスト用boot entryの作成

# 作成したプロファイルIDを取得
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')

# 現在のkernelからboot entryを作成
boom entry create \
  --profile ${PROFILE_ID} \
  --title "CentOS Stream 9 - Test Entry" \
  --root-device /dev/mapper/cs-root

# 作成されたentryを確認
boom entry list

再起動後、GRUBメニューに新しいentryが表示されます。それだけです。

詳しく理解する：Boomは何を解決するのか？

GRUB2の設定ファイルは/boot/grub2/grub.cfgにありますが、このファイルはgrub2-mkconfigによって自動生成されます。新しいkernelをインストールするたびに上書きされ、手動での変更はすべて消えてしまいます。

BoomはBoot Loader Specification（BLS）に準拠したBoot Entriesを/boot/loader/entries/内の独立したファイルとして作成することでこの問題を解決します。これらのファイルは新しいkernelのインストール時に上書きされず、grub.cfgとは独立して存在します。

# boot entryファイルの確認
ls /boot/loader/entries/

# entryの内容を表示
cat /boot/loader/entries/*.conf

entryファイルは次のようになっています：

title CentOS Stream 9 - Restore Point 20240115
version 5.14.0-362.el9.x86_64
machine-id abc123def456
options root=/dev/mapper/cs-snap-20240115 ro crashkernel=1G-4G:192M
linux /vmlinuz-5.14.0-362.el9.x86_64
initrd /initramfs-5.14.0-362.el9.x86_64.img

root=の行に注目してください — ここで任意のLVM volumeを指定できます。snapshotも含めて。

応用：BoomとLVM Snapshotを組み合わせてリストアポイントを作成する

ここが最も重要な部分です。BoomはLVM Snapshotと連携するよう設計されています。特定の時点でシステムの状態をキャプチャし、そのsnapshotを指すboot entryを作成して、必要なときにそこから起動して復元できます。

現在のLVM設定を確認する

# ボリュームグループの確認
vgs

# ロジカルボリュームの詳細確認
lvs

# 出力例：
# LV    VG  Attr       LSize
# home  cs  -wi-ao----  5.00g
# root  cs  -wi-ao---- 35.00g
# swap  cs  -wi-ao----  4.00g

アップデート前にLVM Snapshotを作成する

# rootボリュームのスナップショット作成（変更分に10GBを確保）
lvcreate -L10G -s -n root-snap-$(date +%Y%m%d) /dev/cs/root

# スナップショットの確認
lvs | grep snap

snapshotのサイズは元のvolumeの20〜30%程度にするのが目安です。書き込みの多いサーバーはもう少し多めに確保が必要です。snapshotが100%に達すると自動的に無効化され、そのboot entryは使えなくなります。

snapshotを指すBoom Boot Entryを作成する

PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
SNAP_DATE=$(date +%Y%m%d)
SNAP_DEV="/dev/cs/root-snap-${SNAP_DATE}"

boom entry create \
  --profile ${PROFILE_ID} \
  --title "Restore Point ${SNAP_DATE}" \
  --root-device ${SNAP_DEV} \
  --root-opts "ro"

boom entry list

全工程を自動化するスクリプト

毎回手動でやるのは手間なので、スクリプトを書いてアップデート前に実行するようにしています：

#!/bin/bash
# /usr/local/bin/create-restore-point.sh

SNAP_DATE=$(date +%Y%m%d_%H%M)
VG_NAME="cs"
LV_NAME="root"
SNAP_SIZE="10G"
SNAP_NAME="${LV_NAME}-snap-${SNAP_DATE}"

echo "=== リストアポイントの作成：${SNAP_DATE} ==="

# 1. LVM snapshotを作成
echo "LVM snapshotを作成中..."
lvcreate -L${SNAP_SIZE} -s -n ${SNAP_NAME} /dev/${VG_NAME}/${LV_NAME}
if [ $? -ne 0 ]; then
  echo "失敗：snapshotを作成できません"
  exit 1
fi

# 2. boom entryを作成
echo "boot entryを作成中..."
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
boom entry create \
  --profile ${PROFILE_ID} \
  --title "Restore Point ${SNAP_DATE}" \
  --root-device /dev/${VG_NAME}/${SNAP_NAME} \
  --root-opts "ro"

echo "=== 完了！リストアポイント ${SNAP_DATE} の準備ができました ==="
boom entry list
chmod +x /usr/local/bin/create-restore-point.sh

# アップデート前に実行
create-restore-point.sh

# 安心してアップデート
dnf update -y

実践的なヒント

古いリストアポイントの削除

snapshotはディスク容量を消費します。溜め込みすぎないように管理しましょう：

# Entry IDを含むentries一覧の確認
boom entry list

# 不要なentryを削除（abc123を実際のEntry IDに置き換える）
boom entry delete abc123

# 対応するLVM snapshotを削除
lvremove /dev/cs/root-snap-20240110_0930

snapshotの使用率を監視する

# 使用率を確認 — Data%が100%に近い場合は要注意
lvs -o lv_name,lv_size,data_percent /dev/cs

毎日チェックするcron jobを設定して早期警告を受け取れるようにしています：

#!/bin/bash
# /etc/cron.daily/check-snapshots

lvs --noheadings -o lv_name,data_percent | while read lv pct; do
  pct_int=${pct%%.*}
  if [ -n "${pct_int}" ] && [ "${pct_int}" -gt 80 ] 2>/dev/null; then
    echo "警告：LVM Snapshot ${lv} は${pct}%使用中" | \
      logger -t lvm-snapshot-alert
  fi
done

リストアポイントからの起動と復元

  1. サーバーを再起動する
  2. GRUBの画面でいずれかのキーを押してカウントダウンを停止する
  3. “Restore Point YYYYMMDD”のentryを選択する
  4. snapshotを作成した時点の状態でシステムが起動する
  5. すべて正常か確認してから、ロールバックするかアップデートを維持するか判断する

完全にロールバックする場合は、snapshotを元のvolumeにマージします（この操作は取り消せないため、rescue modeまたはlive環境から実行する必要があります）：

# rescue modeまたはlive CDから実行
lvconvert --merge /dev/cs/root-snap-20240115_0900

Boomとgrubbyのどちらをいつ使うか？

boot entriesの管理にgrubbyを使い慣れている人も多いと思います。実際の違いとして：grubbyはgrub.cfgを直接編集するため上書きされやすいのに対し、Boomは独立したBLS entriesファイルを作成します。安全性が高く、snapshotを使ったワークフローにも適しています。LVM Snapshotワークフローを扱うなら、Boomは自然な選択です。

このワークフローを導入してから、チームはkernelや大型パッケージのアップデート時に不安を感じなくなりました。事前にcreate-restore-point.shを実行し、アップデート後に問題がなければsnapshotを削除するだけです。実際にリストアポイントを使う場面はまだ訪れていませんが、いざとなれば使えると分かっているだけで、チーム全員が自信を持って作業できるようになりました。

Share:
Tags: