ごまめの遠足。

11月の危機

サーバのディスクアクセスランプが点きっぱなしになる。

とりあえずハードウェアリセットから再起動はできたので、生きているうちにデータドライブのバックアップを取って(たぶん成功)、MySQLのデータを含む/varのアーカイブを取って(たぶん成功)、/etcのアーカイブを取ろうとしたところで再びアクセスランプが点いたままになる。

今回は、ディスクアクセスに関するエラーらしき表示をコンソールに出す余裕!?があるので、とりあえずPSUとかメモリとかは直接の原因ではなさそうだ。というわけで、システムドライブか、データドライブミラー(ARAID99-2000)か、マザーボードのいずれかでほぼ決まりだが(範囲広すぎ)、理想的な復旧シナリオとしては、

• 原因はシステムドライブの寿命で
• TrueImageでイメージを吸い出す間もちこたえて
• イメージ移植した新ドライブに入れ替えると復旧する

であったが、取り出した時点で過去何週間かのバックアップファイルが入ったままになっていて、本来2GBそこそこのバックアップイメージのはずが80GBを超える。わざわざシステムとデータを別ドライブに分けた意味を忘れて、システムドライブのサイズをいたずらに大きくしてしまったのは大不覚。強引にバックアップしようとしたが、80GBの空きのあるフリーのHDDがなく途方に暮れる。悪いことにメインPCの調子も悪いので、共有ディレクトリにアップロードすることもできない。

一応バックアップ保存先のパーティションを除外すれば、短時間でコンパクトなバックアップは取れた。あとは別ドライブに領域残して復元して、復旧後バックアップ保存用のパーティションを改めて作り直すという手順だが、TrueImageが想定している可能性が(フルバックアップよりは)低いイレギュラーな手順なので、いまいち不安は残る。というか最も理想的なシナリオにしてこのややこしさ(汗)。

でもって、ARAID2000のアクセスランプも点きっぱなしになったというところに、システムドライブはシロかなという予感も感じる。

ちなみに、ARAID2000の故障であれば、元手はかかるけど別のミラーユニットを買って、同じSATAポートに繋げれば、引き続きそのまま使える(はず)。

USBとかだと、lvmの再マウントという未経験な手順が必要だが、まあOSもそのぐらいのことは想定しているであろう。

最悪なのはマザーボードの交換が必要なケースだ。CPU/マザー/メモリの3点セットが必要なうえ、おそらくOSやらサービスやらの再セットアップが必要だ。

将来計算機ごと交換しなければならない場合でもスムーズに復旧できるように、仮想化でも導入するべきかもしれない。

2011/11/13 23:00 | カテゴリー：Fedora | コメント（0）