エンタープライズSANの物理障害：大規模データ復旧の課題

【注意】エンタープライズSANの物理障害では、通電の継続・再起動・リビルド継続・設定変更などの“いつもの運用操作”が、障害の連鎖やメタデータ破損を招き、復旧難易度と損失を一気に引き上げることがあります。結論として、現場での自己流の分解・修理・復旧作業は行わず、まずは安全な初動（被害最小化・ダメージコントロール）に徹し、状況が重い／判断に迷う場合は株式会社情報工学研究所のような専門事業者に相談してください。

　

赤ランプは突然来る——「止められない現場」でSANが壊れた夜

「また障害か……。でも、止められないんだよな」

オンコールや当番の夜、監視が跳ねて、ストレージのアラートが“赤”になる。アプリのログもDBも遅延しはじめる。
その瞬間に頭に浮かぶのは、理想論じゃなくて現実です。

「冗長化してあるはずなのに、なんでこんなに怖いんだっけ」
「上に説明する時間がない。まずサービスを落としたくない」
「でも下手に触ったら、もっと悪化する気もする」

---

冒頭30秒：まず“安全側”に倒す初動ガイド

エンタープライズSANの“物理障害”では、正しい操作より先に「やらない判断」が重要です。復旧は後からでもできますが、壊れ方によっては一度書き換わったメタデータやキャッシュの内容は元に戻せないことがあるためです。

よくある症状	まず取るべき行動（被害最小化）	やってはいけない例
I/Oが急に遅い／タイムアウトが増える	アプリ側で書き込みを抑制し、可能なら対象サービスを“読み取り優先”へ。ログと状態を採取して変更を止める。	原因不明のまま再起動、パスの手動切替、設定変更、無計画な再試行ループ
LUNが消えた／片系だけ見える／パスが暴れる	ホスト側のマルチパス状態・HBA・スイッチのログを確保し、構成変更を凍結。不要な再スキャンを避ける。	再スキャン連打、パス設定の作業、ゾーニングやLUNマッピングの変更
RAIDがDegraded／Rebuildが走っている	リビルド継続が安全とは限らないため、ディスク障害の範囲・メディアエラー状況を確認して方針を決める（記録を優先）。	根拠なくリビルドを加速、故障ディスクの入れ替えを連鎖させる
コントローラ再起動／電源系アラート	通電の反復は状態を変える。状況証拠（イベントログ、ダンプ、時系列）を確保し、不要な電源操作を避ける。	電源OFF/ONの反復、部品の抜き差し、手順不明のファーム更新

---

「修理手順」を探して来た人へ：まず“やらない判断”が復旧を近づける

検索で辿り着く人の中には、「故障パーツを交換すれば直る？」を期待している方もいます。ですがSANは、単体サーバのパーツ交換と違い、構成情報（マッピング、冗長化、キャッシュ、メタデータ、再構築履歴）がデータそのものと不可分です。

「ハードが壊れたならハードを替えればいい」——その発想自体は自然です。けれど、SANの現場では、交換・切替・再同期・再スキャンなどの“復旧に見える操作”が、実際には障害状態を前進させてしまうことがあります。ここで大切なのは、場を整える／空気を落ち着かせるように、状態変化を最小化して観測可能性を確保することです。

---

依頼判断ページ：今すぐ相談すべき条件（一般論の目安）

次に当てはまる場合、現場だけで抱え込むほど損失が増えやすいので、早めに専門家へエスカレーションした方が結果的に速いことがあります。

• ビジネス上の重要データで、復旧の失敗が許容できない（RPO/RTOが厳しい、監査・法令・契約が絡む）
• 障害がディスク1本では説明できない（棚全体、複数筐体、コントローラ再起動、電源／温度／バックプレーンなどの兆候）
• リビルド中に新たなエラーが増えている／I/Oタイムアウトが増加している
• 構成変更（ゾーニング、LUNマッピング、マルチパス設定など）を最近触った／担当が不在で履歴が追えない
• ログや状態取得が難しい／取得するほど状態が変わってしまう懸念がある

「これ、どこまで自分たちでやっていいんだろう……」と迷った時点で、それは健全な疑いです。判断材料を揃えるだけでも価値があります。

相談導線：株式会社情報工学研究所への無料相談フォーム：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

---

この章のまとめ

SAN障害の最初の勝負は、復旧テクニックよりも「状態を変えない」「証拠を残す」「不用意に前へ進めない」というブレーキの設計です。次章から、なぜSANの物理障害が“ディスク交換”では済まないのかを、構造の観点でほどいていきます。

　

それ、ディスクだけの話じゃない——SANの“物理障害”が難しい理由

物理障害というと「壊れたディスクを交換して終わり」を想像しがちです。ですがエンタープライズSANは、現実には複数の故障モードが同時に起こり得る複合システムです。ここを見誤ると、復旧は一気に難しくなります。

---

SANは「ストレージ＋ネットワーク＋分散制御」の組み合わせ

エンタープライズSAN環境では、一般に次の要素が連動しています（製品や構成で差はありますが、考え方は共通です）。

• ディスク（HDD/SSD）：単体故障だけでなく、同一ロット・同一寿命の同時故障リスクがある
• ディスクシェルフ／バックプレーン：電源・ケーブル・エンクロージャの問題が複数ディスク障害のように見えることがある
• コントローラ：キャッシュ、NVRAM/バッテリ、ファームウェア、パス制御など“状態”を持つ
• ファブリック（FC/iSCSI）：スイッチ、SFP、ケーブル、ゾーニング、ターゲット/イニシエータ設定
• ホスト側：マルチパス、ファイルシステム、DBのI/Oパターン、再試行挙動

つまり、SANの障害は「部品の故障」だけでなく、状態遷移（フェイルオーバー、再同期、再構成）まで含めた問題です。ここが“難しさの本体”です。

---

冗長化があるのに危ない理由：自動処理が“状態を進める”

冗長化は、可用性のためにあります。ただし物理障害の局面では、冗長化の自動処理が障害を連鎖させるトリガになり得ます。

• コントローラ間の切替・再同期が繰り返される
• パスが揺れてホスト側が再試行し、I/Oが増幅する（タイムアウト→リトライ→負荷増）
• リビルドや再配置が走り、弱ったディスクに追加負荷が乗る

現場の“あるある”として、こういう独り言が出ます。

「冗長化してるんだから放っておけば戻るでしょ……って言われても、今この揺れ方は嫌な予感しかしない」

この予感は大事です。冗長化は万能ではなく、故障の種類によっては自動回復が逆効果になることがあります。だからこそ、初動で「状態変化を抑える」ことが意味を持ちます。

---

“物理”でも論点はメタデータ：LUNとRAIDの情報はどこにあるか

大規模データ復旧の課題は、容量の大きさだけではありません。むしろ厄介なのは、構成の正しさを保証する情報（メタデータ）が多層にあることです。

• RAIDレベルやストライプ、パリティ、ディスク順序などの構成情報
• LUNの割り当て、マッピング、アクセス制御
• キャッシュやジャーナル、書き込み順序の整合性

これらは、単一の“設定ファイル”にまとまっているとは限りません。製品実装により保存先や冗長化方法が異なり、障害の影響範囲も変わります。ここで無理に操作を進めると、復旧時に必要な手がかり（時系列や状態）が消えてしまうことがあります。

---

この章のまとめ

SANの物理障害は「壊れた部品の交換」ではなく、状態を持ったシステムの障害対応です。次章では、見た目の症状が似てしまう中で、どこが壊れている可能性が高いのかを、観測点（ログ・挙動・切り分け）から整理します。

　

症状は同じに見える——コントローラ／シェルフ／ファブリック障害の見分け方

現場で困るのは、「何が壊れているか」がすぐには分からないことです。しかも、症状は似ます。I/O遅延、タイムアウト、LUN消失、パスのフラップ（出たり消えたり）……どれも起こり得ます。

ここで大事なのは、“当て勘”で触るのではなく、観測点を固定して切り分けることです。闇雲な操作は、復旧のための証拠を削ります。

---

切り分けの基本：ホスト／ファブリック／アレイの三角形で見る

まずは、障害点を三つの領域で考えます。

領域	よく出る症状	まず見るべき観測点
ホスト（OS/MPIO/HBA）	特定ホストだけ遅い／再試行が増える／パス優先度が崩れる	OSログ、マルチパス状態、HBAリンク状態、I/Oタイムアウトの発生点
ファブリック（FC/iSCSI）	複数ホストで同時にパスが落ちる／フラップする	スイッチログ、リンクアップ/ダウン、エラーカウンタ、SFP/ケーブル交換履歴
アレイ（コントローラ/シェルフ/ディスク）	全体遅延／リビルド遅延／コントローラ再起動／棚単位の障害	イベントログ、構成状態、ディスクメディアエラー、コントローラのフェイルオーバー履歴

ポイントは「どこを見るか」を先に決め、観測しながら手を止めることです。焦ると、こうなりがちです。

「とりあえず再スキャンすれば戻るかも」
「片系だけ見えるなら、パスを手で固定しよう」

でも、それが“状態を進める操作”になってしまうことがあります。特に、マッピングやパスの変更は後から追跡が難しく、切り分けの土台を崩します。

---

「複数ディスク障害に見える」＝ディスクが悪いとは限らない

ディスクが複数本同時にエラーを出しているように見えても、原因が別にあることは珍しくありません。例えば、棚側（シェルフ）の電源・バックプレーン・ケーブル・エンクロージャ管理の問題が、複数ドライブのエラーとして表面化することがあります。

このときに怖いのが、“壊れていないディスクまで交換してしまう”ことです。交換やリビルドの連鎖は、健全だったメディアに余計な負荷をかけ、状況を悪化させるリスクがあります。

---

コントローラ障害のサイン：遅延の質が変わる／再起動／フェイルオーバーの反復

コントローラ（またはコントローラ周辺：キャッシュ、バッテリ、NVRAM等）に問題がある場合、単なるディスク遅延とは違う“揺れ”が出ることがあります。

• 一定周期でタイムアウトが波打つ
• フェイルオーバーが発生し、その後も安定しない
• ログに再起動・例外・ハートビートの異常が残る

ここで「再起動で直るかも」と思うのは自然です。ですが、再起動は状態遷移を強制します。復旧の観点では、まず“何が起きたか”を固定し、ログ・時刻・症状の整合を取る方が再現性があります。

---

この章のまとめ

症状が似ているほど、操作を増やすほど、原因の特定と復旧の再現性が落ちます。次章では、冗長化の要であるマルチパス／フェイルオーバーが、なぜ「安心」を壊す瞬間があるのかを、運用あるあると設計の観点で整理します。

　

冗長化が“安心”を壊す瞬間——マルチパスとフェイルオーバーの落とし穴

「冗長化してあるんだから、片系が落ちても大丈夫」

この言葉は間違いではありません。平常時の設計思想としては正しい。ただ、物理障害の局面では“正しいはずの仕組み”が、現場の不安を増やす瞬間があります。

「落ちたなら切り替わるはずなのに、なんで遅いまま？」
「切り替わったっぽいけど、また戻った……何が起きてる？」

---

マルチパスは“保険”ではなく“制御ループ”である

マルチパス（MPIO）は、複数経路を使って可用性や性能を上げる仕組みです。ですが実際には、故障時に自動的に経路選択を変える制御ループです。制御ループは、観測と反応で成り立ちます。

• 観測：タイムアウト、エラー、応答遅延、リンク状態など
• 反応：パスの切替、優先度変更、キュー深度の調整、再試行

問題は、障害が“確定的な断”ではなく、中途半端な不安定（遅延が増える、瞬断が起きる、エラーが散発する）で起こるときです。制御ループが「切替→戻る→切替」を繰り返し、I/Oが揺れます。

---

落とし穴1：フェイルオーバーの“繰り返し”が状態を進める

コントローラ冗長（A/B）やパス冗長は、障害時にフェイルオーバーします。しかし、物理障害の原因が残ったままフェイルオーバーが繰り返されると、次のような副作用が出ます。

• ホスト側のI/Oが再試行を重ねて増幅し、負荷が跳ねる
• キャッシュやキューの状態が揺れ、遅延の質が変わる
• ログが大量に出て、後追いで因果が追えなくなる

現場の心の会話はだいたいこうです。

「切り替わるたびに少しマシになるけど、すぐまた悪化する。これ、回復じゃなくて“揺れてる”だけでは？」

この疑いは健全です。揺れを放置すると、“そのうち落ち着く”ではなく、むしろどこかの弱い要素が先に限界に達することがあります。

---

落とし穴2：自動処理が“被害最小化”と逆向きになることがある

被害最小化（ダメージコントロール）の観点では、「書き込みを増やさない」「状態を変えない」「観測点を固定する」が基本です。ところが、冗長化は“自動で動く”ため、こちらの意図と逆方向に進む場合があります。

自動機構	狙い	障害時の副作用
パス自動切替	通信断でもI/O継続	切替を繰り返してI/Oが揺れ、再試行で負荷増
リビルド／再配置	冗長性の回復	弱ったメディアへ追加読み書きを発生させ、エラーが増える
再同期（ミラー等）	整合性の回復	不安定な側へ同期を走らせて状態を悪化させる可能性

もちろん、すべてのケースで止めるべきだと言っているわけではありません。重要なのは、今この障害の局面で、その自動処理が安全側に働いているのかを確認できる状態にすることです。

---

落とし穴3：“手動で直す”が追跡不能になる

焦ると、こうした操作をやりたくなります。

• 一時的に片系パスを無効化して“安定させる”
• 優先パスを固定して“遅延を減らす”
• ゾーニングやマッピングを“整理してみる”

しかし、これらは後から見たときに「障害が自然に起きたのか、操作で状態が変わったのか」が混ざります。大規模復旧では、時系列が命です。時系列が崩れると、原因究明だけでなく、復旧計画（どの状態に戻すか）の土台も揺らぎます。

---

この章のまとめ

冗長化は正義ですが、物理障害の局面では“自動で状態を進める”面があります。現場の安全策は、制御ループを落ち着かせ、観測点と時系列を固定することです。次章では、実際にやりがちな操作がなぜ致命傷になり得るのかを、初動の「凍結」設計として具体化します。

　

やりがちな一手が致命傷になる——ログ・状態・I/Oを「凍結」する初動設計

障害対応で一番怖いのは、「復旧のつもりでやった操作」が結果的に状況を悪化させることです。特にSANは、障害点がストレージ筐体に見えても、実際にはホストやファブリックの再試行、冗長化の自動処理が絡み、“書き込みが続いてしまう”構造になりがちです。

「止めたら怒られる。でも動かし続けたら壊れそう」
この板挟みは、現場の本音として自然です。

---

初動の目的は「修理」ではなく、被害最小化と再現性の確保

この章で言う「凍結」とは、物理的に何かを冷やす話ではなく、状態変化を最小にして観測可能性を守るという意味です。具体的には、次の3点が核になります。

• I/Oの増幅を止める（再試行の嵐、リビルド負荷、同期負荷を抑える）
• ログと状態を確保する（時刻・イベント・構成・エラーカウンタを“固定”する）
• 変更作業を凍結する（ゾーニング、マッピング、MPIO設定、ファーム更新など）

---

「やりがち」だけど危ない操作（一般論）

ここは誤解がないように書きます。環境や製品仕様によって“やってよい条件”はあります。ただ、判断材料が揃っていない段階で実施すると、復旧の手がかりを失う操作が多いのも事実です。

やりがちな操作	現場の狙い	危険になり得る理由
再起動（コントローラ／ホスト）	一時的な回復を期待	状態遷移が起き、ログ因果が崩れたり再同期が走ったりする
再スキャン連打	LUN復活を狙う	不安定なパスを刺激して揺れを増やし、再試行負荷を増幅させる
ゾーニング／マッピング変更	構成整理で復旧を狙う	“元の状態”が不明になり、復旧計画の起点を失う
リビルド加速／連鎖交換	冗長性を早く回復	弱ったメディアに追加負荷をかけ、別ディスクの障害を誘発する可能性

---

凍結の実務：最小限の“安全な初動”は何か

製品や契約（保守ベンダ、メーカーサポート）の範囲にもよりますが、一般的に「後戻りしやすい」順番で安全策を組みます。

1. 変更停止：構成変更、ファーム更新、設定投入、入替作業を止める
2. I/Oを抑える：可能なら重要系を読み取り優先へ、バッチや大量処理を止める
3. 観測点固定：アレイ／スイッチ／ホストのログ・状態を時刻付きで確保する
4. 切り分けを計画化：触る前に「何を見て、何が分かったら次に進むか」を決める

ここでのコツは、「いま確実にできること」に絞ることです。復旧のハックではなく、場を整える。これが次の章の“依存関係の地図”につながります。

---

この章のまとめ

SAN障害の初動は、勇気ある“ブレーキ”です。操作を増やすほど状況が混ざり、復旧の再現性が落ちます。次章では「データはどこにあるのか」を、LUN・RAID・キャッシュ・メタデータの依存関係として整理し、なぜ大規模復旧が“再構成”になるのかを具体化します。

　

データはどこにある？——LUN、RAID、キャッシュ、メタデータの依存関係

「LUNが見えない＝データが消えた」ではありません。けれど「LUNが見えている＝データが安全」でもありません。

エンタープライズSANの難しさは、データが“ディスクの上にある”のは事実でも、そのディスクの並び・役割・整合性を保証する情報が多層に存在する点にあります。物理障害が起きた瞬間、現場が混乱するのは当然です。

「どれが正しい経路？」「どの状態が最新？」「いま動いているから触らない方がいい？」
その迷いをほどくために、まず“依存関係の地図”を頭の中に作ります。

---

まず押さえるべき層：ホスト→ファブリック→アレイ→ディスク

データI/Oは、概ね次の層を通ります。ここでのポイントは、障害がどの層で起きても、同じような症状（遅延・タイムアウト・消失）に見えることです。

• ホスト：ファイルシステム／ボリューム管理／DB、MPIO、HBA
• ファブリック：FC/iSCSIスイッチ、ゾーニング、IP/リンク
• アレイ：コントローラ、キャッシュ、LUNマッピング、スナップショット等
• ディスク：RAID構成、ストライプ、パリティ、メディアエラー

---

「メタデータ」は設定ファイルだけではない

ここで言うメタデータは、いわゆるアプリの“メタデータ”だけではありません。SANでは、ストレージが論理的に動作するための情報全般を指します。

• RAIDの構成情報（順序、サイズ、パリティ配置など）
• LUNのマッピング情報（ホストへの割当、アクセス制御）
• キャッシュやジャーナル（書き込み順序や整合性に関わる）

そして厄介なのは、これらが「一か所に完全な形で保存されている」とは限らないことです。実装はベンダや機種、構成（冗長、拡張、スナップショット等）によって異なります。だからこそ、一般論で断定せず、個別案件として情報を集め、筋道を立てて判断する必要があります。

---

現場で役に立つ“観測ポイント”の整理

「どこを見れば、依存関係が崩れているか」を整理しておくと、余計な操作を減らせます。

見たいもの	意味	注意点
アレイのイベントログ（時刻付き）	何が先に起きたか（因果）	再起動や設定変更でログの連続性が崩れる場合がある
RAID状態（Degraded/Rebuild等）	冗長性が残っているか／負荷が増えていないか	「走っている＝安全」とは限らない。追加エラーの有無を確認
ホスト側のMPIO状態	どのパスが生き、揺れているか	手動固定は後追いが難しい。まず記録してから
ファブリックのリンク/エラー統計	瞬断や物理層の兆候	ケーブル/SFP交換は“状態変化”なので計画的に

---

ここでの結論：復旧は「ディスク」ではなく「依存関係」から始まる

大規模データ復旧では、容量よりも、依存関係の正しさがボトルネックになります。データは残っていても、依存関係が崩れると“正しい順序で読めない”。その結果、復旧は単なるコピーではなく「再構成」になりがちです。

次章では、その「再構成」がなぜ必要になるのか、そして現実的にどう進めるのかを、手順の発想（読み取り戦略・再現環境・検証）として整理します。

　

大規模復旧は“復元”ではなく“再構成”——再現環境と読み取り戦略

「バックアップから戻す」ができるなら、それが最短です。ですが現実には、SAN障害の相談が来るケースほど、バックアップが不完全だったり、復旧に時間がかかり過ぎたり、そもそも最新世代が取れていなかったりします。

そこで登場するのが“データ復旧”です。ただしエンタープライズSANの物理障害では、復旧はしばしば復元（restore）ではなく再構成（reconstruct）になります。

---

再構成とは何か：正しい読み取り順序を取り戻す作業

再構成の目的は、ざっくり言うとこうです。

• ディスク群や構成情報から「正しいRAID/LUNの姿」を推定する
• 読み取りを優先し、書き込みを極力発生させない形でデータを抽出する
• 抽出したデータを、別の安全な器（ストレージ）へ移す

ここで重要なのは、「元のSANを直す」ことと「データを取り出す」ことは別だという点です。現場はつい、サービス復旧とデータ保全を同じ線で考えがちです。しかしデータ復旧の観点では、“直すための操作”がデータを遠ざけることがあります。

この違いを理解した瞬間、現場の温度が少し下がります。焦りが消えるというより、議論が過熱しにくくなる。これが、被害最小化の第一歩です。

---

読み取り戦略の基本：まず「変化させない」

物理障害下では、通電・負荷・再試行・再同期が、状態を変えます。再構成で最初に狙うのは、次の2つです。

• 状態の固定：ログ、構成、時系列を確保し、変更を止める
• 読み取り優先：可能な限り“読むだけ”で情報を集める

実務では「どこまでが読むだけで、どこからが状態変化か」は製品や状況で変わります。だから一般論だけで“これをやれ”とは言い切れません。ここが、専門家が必要になる理由の一つです。

---

再現環境が必要になる理由：本番を触るほど危険が増える

大規模復旧の現場では、次の発想が重要です。

「本番環境で試行錯誤しない」

試行錯誤とは、つまり状態変化です。再現環境（検証環境）を用意し、そこで読み取り方針や手順を固めることで、本番に入れる操作を最小化できます。

「そんな余裕ない」と感じるのも自然です。ですが、余裕がないほど、場当たりの操作が連鎖し、結果として時間が溶けます。再現環境を作るのは遠回りに見えて、実は“最短の軟着陸”であることが多いのです。

---

現場が押さえるべき最低限の材料：何を渡せば復旧が速くなるか

もし専門家へ相談するなら、次の情報があるだけで、状況把握が進みやすくなります（取得可否は環境次第なので、無理はしないでください）。

• 障害発生時刻と、その前後で行った操作の記録（再起動、交換、設定変更など）
• アレイ／スイッチ／ホストのログ（時刻が分かるもの）
• LUN構成、ホスト割当、マルチパス状態のスナップショット（画面キャプチャでもよい）
• どのデータが最優先か（業務影響の順番、RPO/RTOの目安）

「何を集めたらいいか分からない」なら、そこで相談して構いません。株式会社情報工学研究所のような専門事業者は、“集めるべき情報の設計”から支援できます。

---

この章のまとめ

エンタープライズSANの大規模復旧は、しばしば「壊れたものを戻す」ではなく、「正しく読める状態を再構成して取り出す」作業です。次章では、時間との戦いを勝つために、優先順位と復旧計画をどう組み立てるかを、意思決定の形に落とします。

　

時間との戦いを構造化する——優先順位、切り分け、復旧計画の立て方

大規模障害の現場では、技術だけでなく“時間”が一番の敵になります。

「上は『いつ直る？』しか聞いてこない」
「現場は『触れば触るほど怖い』と思ってる」
「でも、止め続けるのは現実的に無理」

このギャップが、議論を過熱させます。だからこそ、復旧は気合いではなく、計画として構造化します。ここができると、空気を落ち着かせることができ、結果として復旧も速くなります。

---

まず決める：復旧の目的は1つではない

「復旧」と一言で言っても、現場が同じ言葉で違うものを指していることが多いです。

• サービス復旧：業務を動かす（暫定でもよい）
• データ保全：失いたくないデータを守る／取り出す
• 原因究明：再発防止や監査のために因果を押さえる

この3つは、同時に最大化できないことがあります。たとえば、サービス復旧を急ぐ操作が、データ保全や原因究明に不利になるケースです。ここを言語化できるだけで、社内調整が一段ラクになります。

---

優先順位付け：RPO/RTOを“現場の言葉”に翻訳する

RPO/RTOは重要ですが、数値が一人歩きしがちです。現場では、次のように翻訳すると判断が速くなります。

問い	具体化の例	決まること
何が一番困る？	受注停止／決済停止／出荷停止／診療系停止など	最優先LUN・システムの決定
何は後回しにできる？	分析基盤、ログ集計、開発環境など	切り捨て／停止の範囲
どの時点のデータが必要？	「前日でよい」か「直前が必須」か	保全戦略（バックアップ/復旧/抽出）の選択

---

切り分け計画：触る前に「成功条件」を書く

障害対応が泥沼化する典型は、操作が先に走り、成功条件が曖昧なまま試行錯誤することです。だから、次のように書いてから触ります。

• この操作で何を確認するか（観測点）
• 成功したら何が言えるか
• 失敗したら次に何をするか（ロールバック／停止判断）

ここまで書くと「そんなの当たり前」と思うかもしれません。でも現場では、夜間や緊急時ほど当たり前が崩れます。書くことで、ブレーキが効きます。

---

復旧計画の骨格：段階を分けて“軟着陸”する

大規模復旧では、いきなり100%を狙うと失敗しやすいです。段階を分けます。

1. 被害最小化：I/O抑制、変更停止、ログ確保
2. 暫定復旧：最低限の業務を動かす（代替経路や限定稼働など）
3. データ保全：重要データを別媒体へ抽出
4. 恒久対応：原因の修正、再発防止、運用設計の更新

この段階設計ができると、上層への説明も楽になります。「全部は無理でも、ここまではいつまでにやれる」が言えるからです。

---

この章のまとめ

時間との戦いは、根性ではなく計画で勝ちます。目的を分け、優先順位を決め、成功条件を固定する。これができると、損失の流出に歯止めがかかります。次章では「いつ自力をやめるか」を、感情論ではなく損失と確率の観点で整理します。

　

いつ「自力」をやめるべきか——損失期待値で決めるエスカレーション判断

障害対応で一番つらい瞬間は、「もう少し頑張れば直る気がする」と「触れば触るほど悪化しそう」が同時に頭にあるときです。

「ここでベンダや専門家に頼んだら負けみたいで……」
「いや、負けじゃないけど、時間もお金もかかるし……」

そう感じるのは自然です。現場は“自分で直す文化”の上に立っています。ただ、エンタープライズSANの物理障害は、根性で突破できない種類の問題が混ざります。ここは感情論ではなく、損失期待値で判断するとブレにくくなります。

---

考え方：損失期待値＝（失うもの）×（起こりやすさ）×（長引くほど増える係数）

厳密な数式にする必要はありません。重要なのは、「いま自力で粘ることが、損失を減らすのか増やすのか」を言葉にすることです。

論点	現場の質問	判断が動く方向
失うものの大きさ	このLUN/DBが飛ぶと契約・監査・業務にどれだけ影響？	大きいほど早期相談が合理的
起こりやすさ（悪化確率）	揺れが増えている？新しいエラーが出ている？	増えているほど“粘る”が危険
時間で増える係数	止めている間の損失は？復旧が1日伸びたら？	伸びるほど「早く止めて整理」が効く

この3点のどれかが“重い”なら、エスカレーションは「弱さ」ではなく、被害最小化のためのブレーキです。

---

エスカレーションの目安：一般論として「迷うなら、材料集めを外に出す」

よくある誤解は、「相談＝すべて丸投げ」です。実際には、相談の価値はもっと手前にあります。

• いまの状態で、何を採取すべきか（ログ、構成、時系列）
• どの操作が“戻せる”／“戻せない”かの仕分け
• 復旧の選択肢（暫定復旧／データ保全／恒久復旧）の整理

ここを外部の第三者が整理できると、現場の社内説明も通りやすくなります。「なぜ止めたのか」「なぜ触らないのか」を“技術の言葉”で説明できるからです。

---

「自力でやる」範囲を安全に区切る

自力対応が悪いわけではありません。問題は、範囲が曖昧なまま操作が増えることです。一般論として、自力の範囲は次のように区切ると安全側に寄せやすいです。

• やる：状態の記録、変更停止、I/O抑制、関係者の合意形成、優先順位付け
• 迷ったら相談：リビルド継続判断、複数要素の同時故障が疑われるとき、構成変更が必要になりそうなとき
• やらない：根拠のない再起動反復、構成の手直し（ゾーニング/マッピング/MPIO固定）、無計画な入替連鎖

---

この章のまとめ

エスカレーションは、現場の負けではなく、損失の流出に歯止めをかける“意思決定”です。終盤では、ここまでの話をまとめて、SAN復旧の本質がなぜ「分散システムの障害対応」になるのかを結論として言語化します。

　

結論：SAN復旧は“修理”ではなく“分散システムの障害対応”である

ここまでの章で繰り返し触れたとおり、エンタープライズSANの物理障害は「壊れた部品を交換して終わり」にならないことがあります。なぜなら、SANは部品の集合ではなく、状態を持って協調動作するシステムだからです。

---

「ディスクが壊れた」より先に起きていること

物理障害が起きると、ディスクやコントローラの異常だけでなく、次のような“システムとしての揺れ”が発生します。

• 冗長化の自動処理（フェイルオーバー、再同期、再配置）が状態を進める
• マルチパスや再試行がI/Oを増幅し、負荷が跳ねる
• ログや時系列が操作で混ざり、因果が追いにくくなる

結果として、復旧の鍵は「交換手順」ではなく、状態を固定し、観測可能性を保ち、正しく再構成できる条件を守ることになります。これはまさに、分散システム障害の基本と同じです。

---

一般論の限界：同じ“症状”でも正解が変わる

ここで大事なことを、はっきり書きます。この記事は“安全側”の一般論を中心にまとめていますが、エンタープライズSANは構成・製品・運用・契約（保守）で前提が大きく変わります。

同じ「遅い」「LUNが見えない」でも、

• 原因がファブリックなのか、ホストなのか、アレイなのか
• 冗長化が効いているのか、むしろ揺れを増やしているのか
• リビルド継続が安全なのか、危険なのか

判断は変わります。つまり、一般論だけで「この操作を必ずやれ」と断定するのは危険です。ここが、“復旧の正解が一つではない”という現場のつらさであり、専門家が介入する価値でもあります。

---

「依頼判断」に寄せた結論：迷ったら、まず材料整理を一緒にやる

現場の本音はこうだと思います。

「相談したい。でも、何を伝えればいいか分からない」
「障害対応が増えるだけのやり取りは避けたい」

ここでの最適解は、“全部投げる”か“全部自分で抱える”の二択ではありません。被害最小化（ダメージコントロール）に必要な材料を整え、復旧計画を立てるところから一緒に進めるのが現実的です。

具体的な案件・契約・システム構成で悩んだとき、この記事だけでは判断しきれない部分が必ず出ます。そのときは、株式会社情報工学研究所への相談・依頼を検討してください。現場の状況を前提に、どこまでを安全に自力で進め、どこからを専門対応に切り替えるかを、筋道立てて整理します。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

---

この章のまとめ

エンタープライズSANの物理障害は、分散システム障害のように「状態」「時系列」「自動処理」「依存関係」を扱う問題です。勝ち筋は、焦って操作を増やすことではなく、場を整え、被害最小化に徹し、必要なら早めに専門家と合流することです。

　

付録：現在のプログラム言語各種で“障害対応ツール”を作るときの注意点

SAN障害対応では、ログ収集、状態のスナップショット化、関係者への状況共有、復旧手順の自動化などでスクリプトを書く場面があります。ただし、障害時に走るツールは“普段の運用ツール”よりも壊れやすい前提で設計すべきです。ここでは言語ごとの典型的な注意点をまとめます（特定製品の手順ではなく一般論です）。

---

Python

• 大容量ログやバイナリを扱うとメモリに載せがちなので、ストリーミング処理（逐次読み書き）を徹底する
• サードパーティ依存を増やすと障害時に環境再現が難しい。標準ライブラリ中心＋requirementsの固定が安全
• タイムゾーンと時刻（JST/UTC）の混在で時系列が崩れやすい。出力に必ずタイムゾーンを含める

Go

• 並行処理（goroutine）でログ収集を高速化できるが、同時アクセスで対象を刺激して状態変化を起こさない設計が必要
• バイナリ配布がしやすい反面、設定や認証情報の扱いを雑にすると漏えいリスクが上がる（環境変数や安全なストアを優先）

Rust

• 信頼性の高いツールが作れるが、実装コストが高くなりがち。障害時は「早く確実に動く」ことが最優先なので作り込み過ぎに注意
• 外部クレートの依存を増やしすぎると、ビルド再現性や脆弱性管理が重くなる

Java

• 大量ログ処理は得意だが、JVMの起動やメモリ設定が障害時の現場でボトルネックになることがある
• 例外ログが冗長になりやすい。現場向けには「結論→根拠→次の一手」を短く出す設計が効く

C#（.NET）

• Windows環境との親和性が高いが、環境差（ランタイム、権限、証明書）で想定外の失敗が起きやすい
• GUI化すると便利だが、障害時はCLIの方が確実に回りやすい（ログ出力・再実行性・自動化）

JavaScript / TypeScript（Node.js）

• CLIやWeb UIが作りやすい一方、依存パッケージが肥大化しやすい。障害時はインストール不能・プロキシ制限などが起きる前提で最小依存にする
• 非同期処理でタイムアウト・リトライが暴走しやすい。対象に負荷をかけない上限（回数・間隔）を必ず入れる

Shell（bash / zsh）

• 手早く書けるが、エラー処理・例外系が弱く、途中失敗が見えにくい。終了コードとログの採取を厳格に
• コマンドの出力形式が環境差で変わることがある。解析前提のスクリプトは壊れやすい

PowerShell

• Windows運用で強力だが、実行ポリシーや権限で動かないケースがある。障害時の権限制約を前提に設計する
• オブジェクト指向の出力は便利な反面、テキストログとして残す整形を忘れると後追い検証が難しい

C / C++

• 低レベルの処理や高速I/Oに強いが、障害時に求められるのは速度より安全性と再現性であることが多い
• メモリ破壊や例外処理不足が“二次障害”（ログ欠損、誤動作）につながりやすい。慎重な設計・テストが必須

PHP / Ruby

• 運用現場にある環境で動かしやすい一方、バージョン差・拡張差で挙動が変わりやすい
• 障害対応用途では、Web経由で実行するよりCLIで実行してログを残す方が安全（認証・権限・監査の観点）

---

付録のまとめ：障害時ツールは「速さ」より「壊れにくさ」

障害時の自動化は強力ですが、設計を誤ると対象を刺激して状況を悪化させることがあります。リトライ上限、読み取り優先、ログの時刻整合、最小依存、再実行性——このあたりが共通の要点です。個別のシステム構成に合わせた“安全な自動化”を組みたい場合も、株式会社情報工学研究所に相談してください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831