1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIX rootvg バックアップ手法のまとめ

1
Last updated at Posted at 2026-06-13

はじめに

AIX の OS 領域である rootvg のバックアップ方法は、mksysb 以外にも複数の選択肢が存在します。本記事では、OS 標準機能からストレージ・仮想化基盤の機能まで、rootvg を保護するための代表的な手段を整理しました。

最後にユースケース別の推奨パターンと比較表も掲載していますので、環境に適した手法の選定にお役立てください。

想定読者

  • AIX サーバーの運用設計やバックアップ設計を担当する方
  • mksysb は理解しているが、他の代替手段も整理したい方
  • PowerVM 環境における OS バックアップ方式を検討している方

検証環境

  • AIX 7.2 / 7.3 (コマンド例は 7.x 共通)

全体

rootvg のバックアップ・保護手段は、大きく 5 カテゴリに分類できます。

カテゴリ 手法
① OS 標準(イメージバックアップ) mksysb(ファイル / テープ / USB)、mkcd / mkdvdmksysb_iso(7.2 TL5〜)
② 代替ディスク系 alt_disk_copyalt_disk_mksysb
③ NIM(ネットワーク)系 NIM mksysb リソース
④ LVM 冗長化系 mirrorvg
⑤ 仮想化・ストレージ基盤系 FlashCopy / ストレージスナップショット、PowerVC キャプチャ

① OS 標準のイメージバックアップ


1. mksysb(ファイルへの取得)

rootvg バックアップにおける最も標準的な手法であり、ブート可能な OS イメージを作成します。NFS マウント先や別 VG のファイルシステムへ出力するのが一般的です。

# /etc/exclude.rootvg を反映しつつ、image.data を再生成してバックアップ
mksysb -e -i /backup/mksysb/$(hostname)_$(date +%Y%m%d).mksysb

ポイント:

  • -i : mkszfile を実行し、image.data(LV/FS 構成情報)を最新化してイメージに含める
  • -e : /etc/exclude.rootvg に記載したパスを除外

リストアは NIM 経由、またはインストールメディアからの「System Backup からのインストール」によって行います。

# 取得済み mksysb の内容確認
lsmksysb -lf /backup/mksysb/hostname_20260613.mksysb
# ファイル単位の取り出しも可能
restore -xvqf /backup/mksysb/hostname_20260613.mksysb ./etc/hosts

[!TIP]
mksysb に関する詳細な FAQ やベストプラクティスについては、IBM 公式サポート情報である IBM Support: AIX mksysb FAQs もあわせてご参照ください。


2. mksysb(テープへの取得)

物理テープ装置が存在する環境では、テープ自体がブートメディアになります。

近年は仮想環境の普及に伴いテープの直結構成が減少し、利用機会は減少傾向にあります。


3. mksysb(USB デバイスへの取得)

AIX 7.2 以降では USB フラッシュメモリ(/dev/usbmsX)への mksysb 取得およびブートがサポートされており、スタンドアロン機の簡易的なバックアップ手段として活用できます。


4. mkcd / mkdvd(ブート可能 ISO / DVD の作成)

mksysb イメージをブート可能な ISO / DVD 形式に変換します。可搬性が高く、「単一のファイルでブートからリストアまで完結する」媒体を作成したい場合に有効です。物理ドライブは不要であり、ISO ファイルとして取得して仮想環境で利用するのが現在の主流となっています。

mkdvdmkcd コマンドへのリンク(実質的に同一プログラム)であり、基本的な動作や指定可能な機能は共通しています。


4-1. 主な特徴と概念

  • 取得と変換の柔軟性: 新規に mksysb を取得しながら同時に ISO 化を行うことも、すでに別ディレクトリに取得済みの mksysb イメージファイルを後から ISO 化することも可能です。
  • DVDサイズとフォーマットの選択:
    • mkcd では標準の CD サイズ(650MB)のほかにオプションで DVD サイズ(4.7GB)を指定できますが、mkdvd を使用した場合はデフォルトで DVD サイズが適用されます。
    • 通常の ISO9660 フォーマットに加え、大容量のバックアップを1つのイメージに収めるためにファイルサイズ制限を緩和した UDF(Universal Disk Format)を選択することも可能です。
  • イメージ出力とファイル名: 作成されたブート可能イメージ(ISO)は指定した任意のディレクトリに出力されます。その際、コマンドのプロセスIDなどを含む一時的な名称(cd_image_<PID>dvd_image_<PID> など)で作成されるため、適宜管理しやすい名称にリネームして運用します。

4-2. 作業領域と運用上の注意

  • 一時領域(ステージング領域)の確保: mkcdmkdvd は ISO イメージの生成過程で、一時的なファイルシステムを自動的に構築します。一時領域を作成するボリュームグループの容量に余裕がない場合は、生成処理が失敗するため、あらかじめ別の場所(別の VG や専用のディレクトリ)をステージング領域として明示する必要があります。
  • マルチボリューム化への対応: バックアップデータの容量がメディアのサイズ上限を超えた場合、イメージが複数枚(ボリューム1、ボリューム2...)に分割されます。この際、1枚目のディスク以外からはシステムをブートできなくなるため、ファイルシステムを除外定義に登録する等して、ファイルサイズを規格内に収める構成設計が重要になります。
  • 作成されたイメージの検証: 生成された ISO イメージは、通常の CD/DVD イメージと同様に loopmount コマンド等を使用して仮想的にマウントし、中のファイル構成や正常性を確認できます。

[!TIP]
VIOS の ISO メディアを loopmount しようとする際、-V cdrfs の代わりに -V udfs オプションを指定しないと、「A system call received a parameter that is not valid.」エラーが発生することがあります。詳細は Chris Gibson's Blog: Loopmount and VIOS ISO media を参照してください。


4-3. VIOS の仮想メディア・リポジトリからのリストア

作成された ISO ファイルは、物理メディアに書き込むだけでなく、PowerVM 環境の **VIOS(Virtual I/O Server)の「仮想メディア・リポジトリ(Virtual Media Repository)」**に登録して利用できます。

これにより、物理光学ドライブを介さずに、以下のような手順でクライアント LPAR のブート・リストアを迅速に行うことが可能です。

  1. 作成した ISO ファイルを VIOS 上のディレクトリ(/var/vio/VMLibrary など)に配置する。
  2. mkvopt コマンド等を使用して、仮想メディア・リポジトリに ISO を登録し、ロードする。
  3. 対象のクライアント LPAR に割り当てられた仮想光学ドライブデバイス(vopt)に対して、当該 ISO イメージをアサイン(マウント)する。
  4. クライアント LPAR を再起動し、SMS(System Management Services)メニューのブートデバイス選択で仮想光学ドライブを指定して、システムインストール(mksysbリストア)を開始する。

NIM(Network Installation Management)サーバーが存在しないネットワーク孤立環境や、簡易的なベアメタル復旧を行いたい場合に非常に有効な手段となります。


4-4. 【AIX 7.2 TL5 以降】mksysb_iso

AIX 7.2 TL5 より、ブート可能 ISO 作成の専用コマンドである mksysb_iso が追加されました。「ISO ファイルを直接作成する」という目的に特化しており、従来の mkcd -S の役割をシンプルに置き換えることができます。

# rootvg の mksysb 取得からブート可能 ISO(ISO 9660)作成までを一括で実行
mksysb_iso -O /backup_isos/$(hostname)_$(date +%Y%m%d).iso -e

# 取得済みの mksysb ファイルから ISO 化
mksysb_iso -O /backup_isos/hostname_20260613.iso \
           -m /backup/mksysb/hostname_20260613.mksysb

主なオプション:

  • -O (必須): 作成する ISO のファイル名またはフルパスを指定する。ファイル名のみを指定した場合は、デフォルトの /mksysb_iso/iso_images 配下に作成される
  • -m: 既存の mksysb イメージから ISO を作成する。mksysb の AIX バージョンと実行するシステムのバージョンが一致している必要がある点に注意が必要 (例: AIX 7.3 のシステム上では AIX 7.3 の mksysb のみ指定可能)
  • -M: -m を使用しない場合に、一時的な mksysb イメージを格納するディレクトリを指定する
  • -C / -V: ISO 構築用の作業ファイルシステム、およびそれを作成する VG を指定する(mkcd と同様。未指定時は /mksysb_iso/ 配下に自動作成され、処理後に自動削除される)
  • -T: JFS2 の外部スナップショットを利用し、静止点を確保しながらバックアップを取得する
  • そのほか -e(exclude)、-x-i(image.data)、-u(bosinst.data)、-z(カスタマイズスクリプト)、-b(バンドル)、-p / -l(追加パッケージの同梱)など、mksysb / mkcd 系の主要オプションが利用可能

mkcd と比較して、メディアへの書き込みオプションがなく、出力ファイル名を最初から指定できる(cd_image_<PID> からのリネーム作業が不要)点がメリットです。AIX 7.2 TL5 以降の環境であれば、ISO化の手法としてまず mksysb_iso を第一候補とし、AIX 7.2 TL4 以前が混在する環境では mkcd -S を使用する形で使い分けるとよいでしょう。


② 代替ディスク系(ダウンタイム最小化に有効)


5. alt_disk_copy(稼働中の rootvg クローン作成)

システム稼働中に rootvg を別ディスクへ丸ごと複製します。OS のアップデート(TL/SP 適用)前に実行する標準的な手順であり、アップデートが失敗した場合には bootlist を切り替えて再起動するだけで元の環境に復元できます。

# hdisk1 に rootvg のクローンを作成(-B: bosboot 実行および bootlist 変更をスキップ)
alt_disk_copy -d hdisk1 -B

# 確認
lspv | grep altinst
# 切り戻し(旧環境から起動する場合)
bootlist -m normal hdisk1
  • メリット: 切り戻し(リストア)にかかる時間が実質的に「再起動 1 回分」で済む
  • デメリット: rootvg と同等以上の容量を持つディスクが別途 1 本必要
  • クリーンアップは alt_rootvg_op -X altinst_rootvg を実行する

6. alt_disk_mksysb(mksysb イメージの別ディスク展開)

取得済みの mksysb イメージを、稼働状態を維持したまま代替ディスクに展開します。「イメージバックアップによる可搬性」と「代替ディスクによる即時切替」のメリットを兼ね備えています。

alt_disk_mksysb -m /backup/mksysb/hostname_20260613.mksysb -d hdisk1

別 LPAR で取得した mksysb を展開してクローン環境を構築する、といった応用も可能です(その際はデバイス再構成への配慮が必要です)。

ミラーリング環境の mksysb を利用する場合の注意点

rootvg が mirrorvg でミラーリングされている環境で取得した mksysb には、image.data 内に COPIES=2 が記録されています。展開先が 1 本のディスクである場合、そのまま実行するとアロケーションエラー(0516-404 allocp: This system cannot fulfill the allocation request)が発生して失敗します。

対処方法は後述の「Tips: ミラーリングされた rootvg の mksysb 取得とリストア」におけるパターン 2 と同様であり、COPIES=1 に修正した image.data-i オプションで渡します。

# 編集済み image.data を -i で渡して展開(COPIES=1 に修正したもの)
alt_disk_mksysb -m /backup/mksysb/hostname_20260613.mksysb \
                -d hdisk1 \
                -i /tmp/image.data.single

展開先も 2 本のディスクでミラー構成を再現する場合は、-d hdisk1 hdisk2 のように複数指定することで、元の image.data をそのまま使用できます。


③ NIM 系


7. NIM サーバーへの mksysb 取得・リストア

NIM(Network Installation Management)サーバーを利用することで、クライアントの mksysb をネットワーク経由で集中取得・リストアできます。ベアメタル復旧(ディスク全損からの復旧)における代表的な手段です。

# 1. クライアントの mksysb をリソースとして取得
nim -o define -t mksysb -a server=master \
    -a location=/export/mksysb/client01_20260613.mksysb \
    -a source=client01 -a mk_image=yes client01_mksysb

# 2. 取得した mksysb をソースにして SPOT リソースを作成
nim -o define -t spot -a server=master \
    -a source=client01_mksysb \
    -a location=/export/spot/client01_spot client01_spot

# 3. 作成した SPOT と mksysb を指定してリストア(bos_inst)を割り当て
nim -o bos_inst -a source=mksysb -a mksysb=client01_mksysb \
    -a spot=client01_spot -a accept_licenses=yes client01
  • メリット: 複数台の一元管理、物理メディア不要、自動化との親和性が高い
  • mksysb をもとにした SPOT の必要性: NIM 経由で mksysb リストアを実行する際、クライアントのネットワークブートに必要な /usr 等のバイナリを提供する SPOT (Shared Product Object Tree) リソースが必要になります。この SPOT は、復元する mksysb の OS バージョン・テクノロジーレベル (TL)・サービスパック (SP) と一致していなければなりません。バージョンが異なる SPOT でネットワークブートを行うと、デバイスドライバー不足やカーネル不整合により、ブート不可(LED 888 でのハングアップ等)に陥る原因になります。そのため、リストアの際は取得した mksysb リソースをソース元として専用の SPOT リソースを作成し、ブート環境を一致させることが強く推奨されます。
  • 設計時のポイント: NIM サーバー自体の冗長化(代替マスター構成 niminit -a is_alternate=yes や NIM マスター自身の mksysb 取得)も考慮してください。NIM が単一障害点になると、システム全般の復旧手段そのものが機能しなくなるリスクがあります。

④ LVM 冗長化系(「バックアップ」ではないが重要)


8. mirrorvg(rootvg のミラー化)

ディスク障害に対する可用性向上を目的とした対策です。誤操作によるファイル削除やアップデート失敗などの論理障害には対応できないため、バックアップの代替とはなりませんが、rootvg 保護の基本構成としてあわせて設計することを推奨します。


rootvg ミラーリングの基本構造

LVM ミラーリングでは、ボリュームグループ (VG) 内で論理パーティション (LP) が複数の物理ボリューム (PV) 上の物理パーティション (PP) にマッピングされ、データが二重化されます。

extendvg rootvg hdisk1
mirrorvg rootvg hdisk1
bosboot -ad /dev/hdisk1
bootlist -m normal hdisk0 hdisk1

⑤ 仮想化・ストレージ基盤系


9. ストレージ装置の FlashCopy / スナップショット

SAN ブート構成を採用している場合、ストレージ側(IBM FlashSystem など)で rootvg LUN の FlashCopy やスナップショットを取得できます。

  • メリット: 高速な取得が可能、OS への負荷が極めて低い、世代管理が容易
  • 注意点:
    • **静止点の確保(sync の実行や、可能であればシステム停止時の取得)を運用手順に組み込む必要があります。
    • コピー先の LUN を同一ホストにそのまま認識させると、PVID 重複の問題が発生するため、recreatevg 等による再構成が必要となります。
    • ストレージ筐体の全損などの大規模障害に備えるには、別途遠隔コピー機能(Global Mirror など)の導入が必要です。

10. PowerVC によるイメージキャプチャ

PowerVC の管理下にある LPAR であれば、VM 単位のイメージキャプチャにより rootvg(ブートボリューム)を含む OSイメージを取得し、そこから新規 VM をデプロイできます。これにより、クローン展開とバックアップを組み合わせた効率的な運用が可能です。


比較表

# 手法 ブート可能 稼働中取得 追加ディスク 復旧速度 主な用途
1-3 mksysb(ファイル/テープ/USB) 不要 △(リストア作業が必要) 定期バックアップの基本
4 mkcd / mkdvd / mksysb_iso(7.2 TL5〜) 不要 可搬性の高いブート可能 ISO 化
5 alt_disk_copy 必要 ◎(再起動のみ) アップデート適用前の切り戻し用
6 alt_disk_mksysb 必要 イメージからのクローン作成
7 NIM mksysb 不要 集中管理・ベアメタル復旧
8 mirrorvg 必要 ◎(無停止) ディスク障害対策(冗長化)
9 FlashCopy / スナップショット ○(※) ストレージ側 SAN 環境の高速世代管理
10 PowerVC キャプチャ 基盤側 クローン展開・基盤統合

※ 静止点確保の運用考慮が必要です。


ユースケース別の推奨パターン

パターン A: オンプレ物理 / PowerVM 環境(標準構成)

  • 平常時: mirrorvg による冗長化 + NIM への定期 mksysb(週次など)
  • アップデート(TL/SP 適用)時: alt_disk_copy で切り戻し先を確保してから実施
  • DR(災害対策)用途: mksysb_iso / mkcd で ISO 化し、遠隔地など別拠点へ保管

パターン B: SAN ブート + ストレージ機能をフル活用

  • ストレージスナップショットによる日次の世代管理
  • 四半期などの定期タイミングで mksysb も取得(論理障害・別筐体復旧用の対策)

共通の鉄則

  • バックアップは取得するだけでなく、「正しくリストアできること」をもって完了となります。必ずリストア試験を計画に組み込んでください。
  • mksysb については、lsmksysb -lf による内容確認や、可能であれば alt_disk_mksysb を用いた展開試験まで実施することを推奨します。
  • NIM サーバー自体のバックアップおよび冗長化もあわせて考慮してください。

まとめ

  • rootvg の保護手段は mksysb 単体にとどまらず、「イメージバックアップ、代替ディスク、冗長化」を適切に組み合わせて設計することが重要です。
  • 目的(障害復旧、変更時の切り戻し、DR)によって最適な手法が異なります。
  • どの方式を採用する場合でも、定期的なリストア試験の実施が運用の品質を決定づけます。

Tips: ミラーリングされた rootvg の mksysb 取得とリストア

mirrorvg によって rootvg がミラーリングされている環境であっても、mksysb の取得自体は通常通り実行可能です。mksysb はファイルシステムレベル(論理レベル)のバックアップであるため、ミラーの両系を二重に取得することはなく、バックアップサイズや所要時間は片系分のみとなります。

ただし、リストア時には注意が必要です。mkszfile が生成する image.data には、各 LV の COPIES= 2 および PP 数(LP 数 × 2)がそのまま記録されます。このイメージをディスク 1 本のみの環境にリストアしようとすると、アロケーションエラーなどの理由で失敗するか、あるいは同一ディスク内でミラーリングされる不適切な構成になります。

ミラー環境のバックアップとリストア方式


対処方法は次の 3 パターンです。

パターン 1: リストア先も 2 本ディスク構成にする

同一構成への復旧であれば、BOS インストールメニューでターゲットディスクを 2 本選択するだけで、image.data の定義通りミラー構成ごと復元されます。最もシンプルな対応方法です。


パターン 2: image.data を編集してから mksysb を取得する(シングルディスク復旧用)

# 1. image.data を生成
mkszfile

# 2. /image.data の各 lv_data スタンザを編集
#      COPIES= 2  →  COPIES= 1
#      PP= の値   →  LPs= と同じ値に変更(ミラー時は 2 倍になっているため)
vi /image.data

# 3. -i を「付けずに」mksysb を実行
mksysb -e /backup/mksysb/$(hostname)_$(date +%Y%m%d).mksysb

ここで重要となるのが、mksysb コマンドにおける -i フラグの挙動です。

  • -i あり: mksysb が内部で mkszfile を再実行し、/image.data を現在の構成で再生成してからイメージに格納します(= 編集内容は上書きされて消去されます)
  • -i なし: ルート直下の既存の /image.data をそのままイメージに格納します

したがって、「mkszfile の実行 → ファイルの編集 → -i オプションを付与せずに取得」という順序を守る必要があります。


運用上の注意点も 2 点あります。

  • mkszfile の実行から mksysb 取得までの間にファイルシステムの拡張や LV の追加があると、image.data が実態と乖離したまま固定されます。編集作業はバックアップ取得の直前に実施し、運用を自動化する場合は「mkszfile の実行 → sed 等による COPIES/PP の書き換え → mksysb の実行」を一連のスクリプトで処理するのが安全です。
  • 既存の定期バックアップジョブに -i オプションが含まれている場合、その実行結果には編集内容が反映されません(都度再生成されるため)。ミラー解除版が必要な場合のみ個別で取得するか、後述するパターン 3 を適用するかを事前に検討しておく必要があります。

パターン 3: NIM の image_data リソースでリストア時に上書きする

mksysb は通常通り(-i オプション付きで)取得しておき、リストア時に NIM 側で編集済み image.data を割り当てる方法です。この方法であれば既存のバックアップ運用を変更せずに対応できるため、NIM による一元管理環境においては最も効率的です。

# 編集済み image.data を image_data リソースとして定義
nim -o define -t image_data -a server=master \
    -a location=/export/resources/image_data.single client01_imgdata

# bos_inst 時に割り当て(mksysb 内の image.data より優先される)
nim -o bos_inst -a source=mksysb -a mksysb=client01_mksysb \
    -a image_data=client01_imgdata \
    -a spot=spot_7300 -a accept_licenses=yes client01

mksysb_iso の場合(AIX 7.2 TL5〜)

「4-4. mksysb_iso」でミラー構成の rootvg を ISO 化する場合は、指定するフラグの意味が異なるため注意が必要です。同じ -i オプションであっても、mksysb コマンドとは挙動が異なります。

  • mksysb -i : mkszfile を実行して image.data を再生成する(編集内容が上書きされる)
  • mksysb_iso -i <ファイル> : 指定した image.data ファイルを採用し、mksysbイメージ内の image.data より優先させる

これにより、mksysb_iso では編集したファイルを -i オプションで渡すだけで、シングルディスク復旧用の ISO イメージを作成できます。NIM の image_data リソースと同様の「リストア定義の上書き」を、ISO 単体で実現可能です。

# 編集済み image.data を用意(COPIES= 1、PP= LPs と同値)
mkszfile
cp /image.data /tmp/image.data.single
vi /tmp/image.data.single

# 既存 mksysb + 編集済み image.data からシングルディスク復旧用 ISO を作成
mksysb_iso -O /backup_isos/hostname_single.iso \
           -m /backup/mksysb/hostname_20260613.mksysb \
           -i /tmp/image.data.single

-i オプションを指定しない場合は、mksysb イメージ内の image.data (ミラー定義のまま)が適用されるため、2 本のディスクに同一構成でリストアするための ISO イメージになります。用途に応じて 2 種類の ISO を作り分けるといった運用も考えられます。


リストア後の共通確認事項

シングルディスク構成で復元した場合は、リストア後に構成を確認し、必要に応じて再度ミラー化の設定を行います。

lsvg -l rootvg                 # COPIES が意図通りか確認
extendvg rootvg hdisk1         # ミラーし直す場合
mirrorvg rootvg hdisk1
bosboot -ad /dev/hdisk1
bootlist -m normal hdisk0 hdisk1

参考

1
0
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?