LVM ソフトウェア RAID1 パーティションのリサイズ（縮小と拡張）

目的と想定読者

この文書は、mdadm によるソフトウェア RAID1 の上に LVM（論理ボリュームマネージャ）があり、その上に ext3/ext4 等のファイルシステムがある環境で、RAID デバイス自体のサイズを変更する（縮小／拡張）必要がある場合の手順を示します。想定読者はシステム管理者または上級ユーザーで、ブート可能なレスキュー環境（例: Live CD/USB）を扱えることを前提とします。

重要な一行定義:

• mdadm: Linux のソフトウェア RAID 管理ツール。
• LVM: 論理ボリューム管理。物理ボリューム（PV）→ボリュームグループ（VG）→論理ボリューム（LV）という階層を管理する。

重要: この作業はデータ破損や起動不能となるリスクがあります。必ず事前にフルバックアップ（イメージ or ファイル単位）を取得してください。

プライオリティと準備（事前確認）

• バックアップ: リードオンリであっても、必ず外部にバックアップを持つこと。
• レスキュー環境: システムルートをリサイズする場合、ターゲットシステムの通常ブート環境では作業できないため、Live CD/USB（例: Knoppix、SystemRescueCD など）を用意する。
• コマンドの理解: mdadm、pvresize、pvdisplay、vgdisplay、lvdisplay、lvreduce、lvextend、resize2fs、e2fsck の動作とリスクを理解していること。
• ディスクの健康: SMART や dmesg を用いて物理ディスクに重いエラーがないか確認する。必要なら交換する。

重要な確認項目:

• 対象 RAID デバイス名（例: /dev/md1）
• RAID を構成するブロックデバイス名（例: /dev/sda5 /dev/sdb5）
• その PV が属する VG 名（例: server1）と LV 名（例: /dev/server1/root）
• 現行のファイルシステム使用量（df -h）および e2fsck の状態

目次

• 前提と背景
• 健全な（イントактな）アレイでの縮小手順（詳細）
• 劣化（degraded）アレイでの縮小とディスク交換フロー
• 拡張手順（一般ケース）
• 検証と起動後の確認
• 役割別チェックリスト
• インシデント対応 / ロールバック手順
• トラブルシュート集（よくある失敗例と対処）
• リスクマトリクスと軽減策
• 意思決定フローチャート（Mermaid）
• コマンドチートシート
• 1行用語集
• まとめ

背景（原文の要約）

あるサーバで RAID1 が劣化している（例: /dev/sda5 が故障、/dev/sdb5 が生きている）ことが判明しました。さらに同期中に /dev/sdb に末端の不良セクタが検出され、同期が繰り返し失敗する状況があったため、破損セクタを回避するために RAID パーティション自体を一時的に縮小し、故障ディスクを交換して再同期した後に元のサイズへ戻す、というワークフローが必要になりました。

以下では、同様のユースケースに適用できる手順を具体的に示します。元の例では 5GB ディスクを用いてテストしていますが、実際の環境では容量が大きく、処理時間が長くなります。

健全な配列（イントактアレイ）での縮小 — 概要

主要な流れ:

1. レスキュー環境で起動し、必要なカーネルモジュールを読み込む。
2. mdadm を用いて RAID をアセンブルして起動する。
3. LVM を起動し、ファイルシステムをオフラインでチェックしたうえで縮小可能か確認する。
4. resize2fs でファイルシステムを縮小（ファイルシステムサイズ <= LV サイズ）。
5. lvreduce で LV を縮小。
6. 必要に応じて末尾の LV（swap 等）を削除して PV の連続領域を確保。
7. pvresize –setphysicalvolumesize で PV サイズを縮小。
8. mdadm –grow で md デバイス自体を縮小（サイズは KiB 単位、64 の倍数など要条件）。
9. pvresize で PV を再スキャンして VG に余裕を作る。
10. LV を再作成/拡張、ファイルシステムを resize2fs で拡張。
11. e2fsck で整合性確認してから再起動。

注意: コマンド引数の単位と境界条件（KiB/MB/GB/PE の単位）に注意すること。pvresize、mdadm の –size の意味は異なる。

健全な配列での実際の手順（詳細、翻訳付き）

次に、実際にレポートされた手順の日本語訳と補足を示します。コード／端末の出力は元文をそのまま保持します。

1. レスキュー環境で必要モジュールをロード

modprobe md modprobe linear modprobe multipath modprobe raid0 modprobe raid1 modprobe raid5 modprobe raid6 modprobe raid10

2. mdadm の設定をバックアップしてアセンブル

cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_orig mdadm –examine –scan >> /etc/mdadm/mdadm.conf

mdadm -A --scan

3. LVM の起動

/etc/init.d/lvm start 

4. ファイルシステムチェック（必須）

e2fsck -f /dev/server1/root

5. ファイルシステムの縮小（例では root LV を 2GB に縮小）

resize2fs /dev/server1/root 2G

注: この時点で指定するサイズは、「ファイルシステムに実際に収まる」ことを必ず確認する。df -h や du -sh で使用容量を確認し、余裕を見て指定する。

6. LV の縮小（例: /dev/server1/root を 2.5G に）

lvreduce -L2.5G /dev/server1/root

7. 末尾にある swap LV を削除して PV の末端領域を空ける（必要な場合のみ）

lvremove /dev/server1/swap_1

8. PV のサイズを指定して縮小（例: /dev/md1 を 3GB にする）

pvresize --setphysicalvolumesize 3G /dev/md1

9. md デバイス自体を縮小（mdadm –grow –size=KiB）
   mdadm の –size はキロバイト単位での最小ブロック数を指定する点に注意。例：4GB → 4 × 1024 × 1024 = 4194304

mdadm --grow /dev/md1 --size=4194304

注意: –size の値は 64 で割り切れる必要があることがあるため、事前に確認する。

10. PV を再スキャン（最大まで拡張）

pvresize /dev/md1

11. VG と LV の確認 (vgdisplay, lvdisplay など) を行い、必要なら swap LV を再作成して mkswap を実行

lvcreate --name swap_1 -l 66 server1
mkswap /dev/server1/swap_1

12. root LV を残りの空き PE を用いて拡張

lvextend -l +317 /dev/server1/root

13. 最終的にファイルシステムを最大に伸ばす

resize2fs /dev/server1/root

14. 最後に再度チェック

e2fsck -f /dev/server1/root

15. 再起動して通常システムへ戻る。/proc/mdstat 等で md1 の新しいサイズを確認する。

（原文の端末出力はここにコードブロックの形でそのまま表示されます。）

cat /proc/mdstat

および df, pvdisplay, vgdisplay, lvdisplay の出力確認。

劣化したアレイ（degraded）の場合: 破損セクタ回避とディスク交換のワークフロー

劣化したアレイで物理ディスクに末端の不良セクタがあり、同期が失敗するケースでは、次のような高レベルの戦略が有効です（原文での実際の対応に基づく）。

戦略概要:

1. まず読み取り専用/レスキュー環境でアレイを組み上げる。
2. 末端の不良セクタを避けるように md デバイスを縮小して同期可能な領域のみで再構築する。
3. 新しい交換ディスクにパーティションを作成し、mdadm で追加して再同期を完了させる。
4. 不良ディスクを外して交換後、元のサイズまで md を拡張し、PV/LV/FS を元に戻す。

具体的手順の例:

• 状況: /dev/md1（sda5, sdb5）があり、sda5 が死んでおり、sdb5 の末端に不良セクタがある。

1. レスキュー環境で md をアセンブルして LVM を起動。

2. mdadm –examine で各メンバーの状態を確認。3) 末端に不良があるディスク（例: /dev/sdb5）の使用を回避するために mdadm –grow により –size を小さくする（上記の手順参照）。
   注: md を縮小する前に PV と LV の配置（特に末尾にある LV）を調整する必要がある。

3. 代替ディスク（新 sda）に同じパーティションレイアウトを作成（fdisk/parted 等）。

4. 新しいパーティションを md に追加して再同期させる。

mdadm /dev/md1 --add /dev/sda5

5. 再同期が完了したら、問題のある /dev/sdb5 を –fail してから –remove する。

mdadm /dev/md1 --fail /dev/sdb5
mdadm /dev/md1 --remove /dev/sdb5

6. 不良ディスクを交換し、新しい /dev/sdb5 を作成して md に追加、同期させる。
7. md のサイズを元に戻し（mdadm –grow）、pvresize で PV を拡張、必要に応じて LV/FS を調整し、容量を回復する。

注意点と落とし穴:

• md を縮小している間は、縮小後の容量が PV/LV/FS の合計より小さくならないように注意する。
• md の縮小はリスクを伴い、失敗するとデータ損失に直結する可能性がある。
• 不良セクタのあるディスクを無理にリードしていると I/O エラーでシステムが遅く（あるいはハング）なるため、ログや dmesg を常に監視する。

拡張（grow）の一般的な手順（要点）

1. 物理ディスクを交換して新しい容量を導入する（パーティションを必要に応じて拡張）。
2. mdadm で新しいメンバーを追加して同期（–add）。
3. 同期完了後、mdadm –grow で md のサイズを増加（–size は必要に応じて）。
4. pvresize /dev/mdX で PV を再認識させる。
5. lvextend で LV を拡張、resize2fs でファイルシステムを拡張。

検証と起動後の確認チェックリスト

• /proc/mdstat で RAID の状態が [UU] など正常であること。
• pvdisplay/vgdisplay/lvdisplay で期待サイズが反映されていること。
• df -h でマウントポイントのサイズが期待通りであること。
• dmesg や /var/log/kern.log に I/O エラーが出ていないこと。
• ブートが成功し、サービスが正常に稼働していること。

役割別チェックリスト

管理者（実行者）:

• 必要なバックアップが存在することを確認。
• 作業手順を文書化し、メンテナンス時間枠をチームに通知。
• レスキュー環境とツール（mdadm, lvm2, e2fsprogs 等）が利用可能であることを確認。

オペレーション/オンコール:

• 作業中のログ監視（dmesg, syslog）を担当。
• 再起動後のサービスチェックを実施。

テクニカルリード:

• 作業承認とリスク評価を行う。
• ロールバック許可を出す。

インシデント対応 / ロールバック（簡易ランブック）

1. 問題発生時はすぐに作業を中断し、システムを安定した状態へ戻す。
2. 現在の md 状態を保存（mdadm –detail –scan > /root/md-state-YYYYMMDD.txt）
3. もし LV が誤って削除された場合、lvcreate の無効な再作成は避ける。まず pvdisplay/vgdisplay で PV 情報を確認する。
4. 最悪の場合、バックアップからのリストアを行う（事前に計画を用意しておくこと）。

よくある失敗例（カウンターエグザンプル）と回避法

失敗: resize2fs で指定サイズが小さすぎてデータが収まらない
回避: df, du で使用量を正確に測り、余裕を持って指定する。必ず e2fsck を事前実行。

失敗: mdadm –grow の –size を誤指定して md を破壊してしまう
回避: –size は KiB 単位のブロック数であることを理解し、64 の倍数などの要件を満たすことを事前計算する。まず非本番で検証する。

失敗: 不良ディスクにアクセスし続けて長時間 I/O エラーが発生する
回避: すぐに不良ディスクを –fail して除外し、代替ディスクで修復する。ログ監視を行う。

リスクマトリクス（主要リスクと緩和策）

• データ損失: 中〜高 → フルバックアップ、検証済みリカバリ手順
• 再同期失敗: 中 → 不良セクタ回避のための一時縮小、予備ディスクを用意
• システム起動不能: 中〜高 → レスキューメディアでの回復手順、ブート修復手順を準備

意思決定フローチャート

以下は高レベルの判断フローです。

flowchart TD
  A[RAID が degraded か?] -->|Yes| B[ディスクに不良セクタがあるか?]
  A -->|No| C[通常の縮小/拡張手順を適用]
  B -->|Yes| D[md を一時縮小して不良領域を避ける]
  D --> E[新ディスクを追加して再同期]
  E --> F[不良ディスクを除去して交換]
  F --> G[md を元サイズへ拡張し PV/LV/FS を回復]
  B -->|No| E
  C --> G

コマンドチートシート（よく使うコマンドと目的）

• mdadm –examine /dev/sdX#: メンバーのメタデータを確認
• mdadm –assemble –scan または mdadm -A –scan: RAID をアセンブル
• mdadm –grow /dev/mdX –size=NNNN: md のサイズ変更（KiB 単位のブロック数）
• pvresize –setphysicalvolumesize SIZE /dev/mdX: PV のサイズを明示的に設定して縮小
• pvresize /dev/mdX: PV をスキャンして可能な最大へ拡張
• lvreduce -L SIZE /dev/VG/LV: LV を縮小（危険。事前にファイルシステムを縮小すること）
• lvextend -l +PEs /dev/VG/LV: LV を拡張
• resize2fs /dev/VG/LV [SIZE]: ext2/3/4 の場合、ファイルシステムサイズの変更
• e2fsck -f /dev/VG/LV: ファイルシステムを強制チェック
• mdadm /dev/mdX –add /dev/sdY#: メンバー追加
• mdadm /dev/mdX –fail /dev/sdY# ; mdadm /dev/mdX –remove /dev/sdY#: メンバー除外

1行用語集

• PV: 物理ボリューム（pvdisplay で確認）
• VG: ボリュームグループ（vgdisplay）
• LV: 論理ボリューム（lvdisplay）
• PE: 割り当て単位（Physical Extent）
• md: Linux のソフトウェア RAID デバイス（/dev/mdX）

テストケース / 受入基準（簡潔）

• 受入基準1: md デバイスのサイズが意図通りに縮小/拡張され、vgdisplay が期待サイズを示すこと。
• 受入基準2: lvdisplay と df -h がファイルシステムのサイズと使用量を整合して報告すること。
• 受入基準3: システムが再起動し、主要サービスが自動的に起動すること。

互換性／移行のヒント

• ext4 を使用している場合も resize2fs, e2fsck は同様に利用可能。XFS は online で縮小できないため、XFS の場合は別プロセス（バックアップ→再作成→リストア）が必要。
• LVM メタデータのバージョンや mdadm バージョン差による挙動差に注意。可能なら作業前に同等のテスト環境でコマンドを検証する。

ログと監視の推奨

• 作業中は別端末で dmesg -w または tail -f /var/log/kern.log を監視する。
• mdadm の同期進捗は /proc/mdstat を poll して確認する。

まとめ

このガイドでは、LVM の上に乗ったソフトウェア RAID1（mdadm）を縮小・拡張する際の手順と注意点を、健全な配列と劣化した配列のケースに分けて解説しました。重要なのは、作業前のバックアップ、レスキュー環境の用意、ファイルシステムと LV/PV のサイズ関係を正確に把握すること、そしてログ監視を怠らないことです。

重要: この手順はリスクを伴います。必ず本番で行う前にテスト環境で検証してください。