はじめに
この記事は本番環境などでやらかしちゃった人 Advent Calendar 2025の20日目 の記事です。
あれはRHEL 6は出てたかも知れないが、CentOS 6はまだこの世に存在しない時代でした。
私は社内サービスを提供しているオンプレの物理サーバ群を、将来的に仮想基盤に移行するための評価として、仮想基盤となる物理サーバとデータ用のiSCSIストレージを利用したいわゆる3ティア構成で自前構築しました。
物理サーバにはCentOS 5を、ハイパーバイザにはKVMを利用していました。iSCSIストレージではブロックボリュームのシンプロビジョニングをサポートしていなかったため、仮想サーバのブロックボリュームを各サーバに直接アタッチするのでは無く、ストレージ全体を1つの領域として確保し、物理サーバでマウントして利用していました。
ある日の出来事
仮想サーバの作成や運用にもある程度慣れ、障害時の影響が限定的なサービスについて試験的にいくつかを仮想サーバで本番運用していました。
ある日、私は新たな仮想サーバを構築しようと、IP-KVM装置経由でサーバのコンソールに接続してVirt-managerを起動して作業を開始しました。virshコマンドでは仮想マシン作成作業が面倒だったこと、ヘルプデスク担当でもあったため、作業のたびにサーバ室に移動することが厳しかったため、IP-KVMを利用して作業PCのWebブラウザ経由で物理サーバのKVM切り替え機に接続していました。
しかし、なぜか作業中に突然Windowsが応答をしなくなってしまったのです。数分待っても状況が変わらなかったため、「やれやれ・・・これだからWindowsは・・・」などと言いながらCtrl+Alt+Delを押しました。すると、急に画面表示が戻り、ブラウザ上でシャットダウン処理が表示されはじめました。そう、Ctrl+Alt+DelはIP-KVMによりリモートの物理サーバに送られ、サーバの再起動が始まったのです！
私は我が目を疑いながら、次に必要な作業を考えました。CentOS 5では仕様？により、iSCSIでマウントしたディスクのアンマウントより先にネットワーク接続が終了させられてたため、iSCSIのアンマウントに失敗してシャットダウン処理が途中停止するという現象が起こっていました。そのため、通常の運用では手動でアンマウントしてからシャットダウン処理を行っていました。予想通りシャットダウン処理が途中で停止したため、手動で電源を切りにサーバ室へ向かいました。再度手動で電源を再投入することで問題解決すると思っていました。この時は・・・
おきのどくですが ファイルシステムは きえてしまいました
手動でサーバの電源を強制断から再投入し、コンソールを確認すると問題なく物理サーバは再起動・・・しませんでした。なぜかiSCSIストレージのマウントに失敗しています。レスキューモードで再起動し、iSCSIディスクを確認するとなぜかパーティションがありません！私の頭は真っ白になりました。
リカバリプランの検討
上司に状況を報告し、対応を考えます。まず夜間バックアップはあるものの、それらはデータだけであり今回のような仮想サーバも纏めて消し飛ぶような状況は想定していませんでした。手元の手順書を元にユーザに影響があるサービスを復帰させることが可能なのは、早くて翌日だと見積もりました。
しかし変です。ディスク全体が再起動時の不整合で消えるなどと考えられません。そこでデジタルフォレンジックに詳しい知人に助けを求めてみました。溺れているときには浮いている板も掴みたいものです。すると、「同容量のディスクを用意して、先頭のXXX（512だったか？）バイトのコピーを上書きしてみろ。」との回答が。
そんなもので直るもんかいな？と二信八疑でしたが、幸いストレージは同一構成で2機存在し、片方をバックアップ用に運用していたため、そこからddでダンプを取得してみることにしました。なお、バックアップ処理時のみマウントする運用だったため、再起動時の影響を受けていませんでした。
ささやき いのり えいしょう ねんじろ！
どうせ他にできることは無いのだからと言われたとおりに作業をすると、なんとストレージのディスク領域は復活したでは無いですか！にわかには信じられませんでしたが、動作チェックも問題なく、サービス復帰となりました。再起動からここまでで1時間ちょっとでした。ユーザにはシステム障害として報告し、対応完了としました。
その後
その後、本番用に導入した仮想基盤では、この経験を踏まえて機種選定や運用方法の検討をおこないました。