ある晩、自宅サーバが起動しなくなって

第十一話 動き出す 熱い鼓動が

　真っ黒い背景の素っ気ないコンソールに、沢山の文字が流れていく。

　ＯＳの起動シーケンスが実行されている証。

　先ほどは、このシーケンスの中のディスクチェックでエラーで止まってたんだけど、今度は……

「通った！」

　ディスクチェックをクリアし、サービスが起動し始める。

　そうして、

login:

　というプロンプトで停止する。

「来た……」

　ここまでくれば、少なくとも OS は起動しログイン可能な状態となったってこと。

　早速、 root ユーザでログインする。

　少し待ち時間があり、エラーになったりしないかドキドキしてたけど、

#

　管理者を示す # のプロンプトが表示され、コマンド実行可能な状況になる。

「ここは、データベースが生きてるか、よね」

　ファイルで取り出せるものは一通り取り出すことができた。後は、データベースのダンプが作成できれば、傷は相当に浅く済むわ。

　因みに、データベースには、趣味で書いてるブログの記事なんかが入ってる。千件以上の記事があったりするので、復活させられると、とっても嬉しい。

　一度諦めてただけに、ここまで来ると、本当、なんだか欲が出てきてしまう。

　期待に胸が熱い鼓動を刻んで高鳴る。

　でも、落ち着いて。

　こういうとき、焦るとうっかりデータを消しちゃったりするからね。

　思い返せばあの晩、最初に「調子が悪いな？」って思ったときに、何も考えず焦って再起動しちゃったのが全ての失敗の元だったから。

　再起動の前にバックアップ取ってれば、こんな苦労しなくてよかったのは間違いない。あのときは、ディスクの調子が悪くともデータベースは動いてたから。

　反省も籠めて、深呼吸。

　眼鏡のレンズを拭いて視界をクリアにする。

　そうして、作業を開始する。

　まず、データベースである mysqld のプロセス起動状況を確認。

ps -ef | grep mysqld

　を実行し、

「うん、 mysqld のプロセスは起動はしてるわね」

　起動してるってことは、データのダンプが可能ってこと。早速、ダンプコマンドを実行する。

# mysqldump --all-database -uroot -p --opt -r/tmp/mysql_dump

「あちゃぁ……駄目、か」

　一応、ダンプファイルは作成されているが、幾つかのテーブルでエラーが発生していた。

「さて、修復できるかな？」

#mysqlcheck -uroot -p --all-database

　チェックコマンドを実行してみる。

「う～ん、全部は無理か」

　若干のテーブルは修復できたけど、どうにもならないテーブルが幾つか残っていた。

　ただ、そのテーブル名を眺めていて、気になったことがあった。

「あれ？　でも、このテーブルって……」

　ブログのテーブル仕様を確認して。

「別に、なくてもいい？」

　奇跡と言っていい。

　修復できなかったテーブルは、どれも操作ログなどを記録したモノで、記事やブログの設定には影響しないものばかり。

　そう、データが飛んでも特に困らない。

「なら……」

　落ち着いて、テーブル名を確認してから。

#mysql -uroot -p

　mysql の操作コンソールに入り、 DROP TABLE で削除してしまう。

「さぁ、これでいけるかな？」

　再び、

# mysqldump --all-database -uroot -p --opt -r/tmp/mysql_dump

　を実行。

「よっしゃ！」

　思わずディスプレイの前でガッツポーズ。

ls -al /tmp

　で確認すれば、無事、ダンプファイルが作成されていた。

「これで、データの復旧は九割成功したって言えるわね」

　これにてサーバの各種設定、その他補助的自作のスクリプト、ファイルベースのデータ、そして、データベースのダンプまでがサルベージできたのだ。

　OS のインストール作業とかはどうしても必要になるけど、設定はサルベージした内容があれば簡単に元の環境が構築出来る。

　データベースも、ダンプファイルさえあれば復旧は容易。

「よかったぁ……」

　そこまで見通しが立って、少し緊張が解けて、

「ふわぁ……」

　大きなあくびが一つ続く。

　うん、なんだか、眠い、わね。

　サーバに新しいディスクを繋いだりは、明日でいいよね。

「今日はこの辺にして、寝よっと」

　あたしは布団に入り、眼鏡を外し、眠りに就く。