大阪で建設会社を営む社長のボヤキ

隔世の感

本日、ハードディスクを買うために久々に日本橋へ行ってきた。

 

行くのはいつもの行きつけの店。

 

品揃えと店員の知識が豊富なこの店に行けば大体のものは揃うので昔から重宝している。

 

 

ところが、目当てのＩＤＥのＨＤＤが品切れで、入荷も未定との事だった。

 

確かに今の主流はＳ−ＡＴＡで、磁気ディスクからＳＳＤのようなシリコンストレージに移り変わろうとしている。

 

 

仕方なく違う店に行き、ＩＤＥのＨＤＤをくまなく捜した。

 

しかしどの店にも売り切れの札が・・・

 

 

ＰＣの世界は進化の速度がめまぐるしく、次から次へと新しいハードウェアや規格が生まれる。

 

たとえば１０年前ならば外部の記憶媒体と言えばＭＯやＣＤ−Ｒが普及しつつもフロッピーディスクがまだ普通に使われていた。

 

しかし現在ではフロッピーディスクはなくなり、ＵＳＢメモリに変わった。

 

 

内蔵ＨＤＤもいずれはＩＤＥがなくなる日が訪れるとは感じていたが、世間ではまだＳ−ＡＴＡのないＰＣが現役で稼動している現在、少し早いのではないかという気がした。

 

しかしそんなことより、壊れたディスクを取り替えるためにＩＤＥのＨＤＤを買いにわざわざ日本橋まで来たというのに、これでは本末転倒である。

 

こうした場合、いくつかの代替案が用意されているもので、現時点で考え得る方策を講じてみた。

 

１．新しいＰＣに買い換える　→　金が勿体無い

２．ＰＣＩのＳ−ＡＴＡ拡張ボードを取り付ける　→　互換性などの確認をせずに購入するのはリスキー

３．Ｓ−ＡＴＡ→ＩＤＥ変換アダプタを取り付ける　→　やったことないのでわからない

 

事前にきちんと調べてから購入するならともかく、その場の思い付きでこうした物を咄嗟に買って帰っても失敗するケースがよくある（経験則）

 

そして最後に思いついたのは、１台遊んでいるＳＡＴＡのＨＤＤをWindowsマシンに移植して、WindowsマシンのＩＤＥディスクをサーバへ換装してみるという案であった。

 

ところがそれをするためにはまず余っているＳＡＴＡのディスクを取り付けなければならないが、あいにく全てのインターフェイスにＨＤＤや光学ドライブが接続されているので、残された方法としてはＵＳＢ接続の外付けＨＤＤボックスに頼らざるを得なくなってしまう。

 

そして店内で物色をしていると、こんなものを見つけた。

 

裸族の頭

 

 

ネーミングはともかく、これはなかなか便利そうであった。

 

使えるＩ／Ｆも３．５インチのＩＤＥＨＤＤや光学ドライブ　そして２．５インチＨＤＤ

それにＳＡＴＡのドライブまで使えてしまう優れものである。

 

早速購入してＨＤＤを繋いでみた。

 

 

ＵＳＢコネクタをＰＣに挿し込んで、コンセントを繋いでスイッチオン！

 

動いた！

 

 

当たり前か^^;

 

 

とりあえずしばらくはコレで凌いで、また時機を見てあらたな対策を練ってみよう。

 

 

壊れたHDDの修復

月曜日の朝出社すると会社のサーバが止まっていた。

プロンプトも受け付けず、仕方なく電源OFFして強制終了→再起動すると、どうやらディスクエラーが発生していたようであった。

 

エラーのあったディスクは/dev/hdbで、hdb5を/homeとしてマウントしている。

 

/home以下にはログインユーザのホームディレクトリの他、vpopmailのバーチャルドメインアカウント用メール受信用データおよび社内のファイルサーバとしても運用しており、そのデータファイルもここに格納されている。

 

起動時のディスクチェックでは修復できたようなので、とりあえずシングルユーザモードに切り替えてから別ディスクのバックアップ領域に/home以下をバックアップした。

 

/usr/bin/rsync -av --delete /home /backup/home/ 2>&1 > /home/backup.log

(cronで走らせているコマンドをそのまま実行した）

 

 

念のため再度ディスクの検査を行い、不良ブロックをマーキングすることにした。

 

# e2fsck -c /dev/hdb5

 

そして水曜日の朝、会社に着くや否や「社長〜　またサーバがおかしいみたいです」と(￣▽￣;)

 

コンソールを叩いてみるとハングアップはしていなかったものの、画面にはカーネルから吐き出されたディスクエラーメッセージで埋まっていたのでとりあず問題のあるディスクをアンマウントして、バックアップを取っていたディレクトリにシンボリックリンクを張ることにした。

 

念のためにfstabで自動マウントされないようにhddの各パーティションをマウントしている行をコメントアウトしたものの、hdd8がswapとして使われていることに気付いた。

 

しかし/dev/hdbがマウントされていなくても特に問題なさそうなので今のところは無視することにして、hdbの修復を試みた。

 

 

まず、

 

# e2fsck /dev/hdb5

 

として、何も指定せずにやってみたところ、次のようなメッセージが表示されて終了した。

 

    e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hdb5
    Could this be a zero-length partition?

 

試しに、

 

# fdisk -l

 

とすると、/dev/hddはシステムから存在しないことになっていた。

 

完全に壊れたか・・・・

 

 

とりあえず出来る事を一つずつやってみようってことで、スーパーブロックを指定してやることにした。

 

まず、スーパーブロックの保存されている場所を特定する。

 

 

#　mkfs.ext3 -n /dev/hdb

mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)　←ブロックサイズ
Fragment size=4096 (log=2)
1305600 inodes, 2610554 blocks
130527 blocks (5.00%) reserved for the super user
First data block=0
80 block groups
32768 blocks per group, 32768 fragments per group
16320 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 2294912, 294912, 819200, 884736, 1605632　

↑スーパーブロックのバックアップが保存されている場所

 

これでスーパーブロックのサイズと場所がわかったので、

 

# e2fsck -b 32768 -B 4096 /dev/hdb5

 

としてみたが結果は同じだったので、スーパーブロックの再作成をして再度検査を行ってみた。

 

# mke2fs -S /dev/hdb5

 

が、結果は同じでした。

 

 

途方に暮れながらネットでいろいろ調べてみたら、testdiskなるツールを発見！

 

http://www.cgsecurity.org/wiki/TestDisk

 

 

藁にもすがる思いで早速ダウンロード。

 

# wget http://www.cgsecurity.org/testdisk-6.14-WIP.linux26.tar.bz2

 

解凍すると作成されたサブディレクトリにファイルが展開される。

 

# tar xjvf testdisk-6.14-WIP.linux26.tar.bz2

 

展開されたファイルのtestdisk_staticが実行ファイルで、プロンプトでタイプする。

 

#./testdisk_static

 

e2fsckではまったく手の施しようのなかったハードディスクでしたが、このツールはちゃんと認識してくれました。

 

現在ディスク表面のテストをしている最中ですが、85GBのHDDなので結構時間がかかってます。

 

かれこれ２時間近くになりますが、今現在の進捗状況は４０％です。

 

復旧できるかどうかはまだわかりませんが、作業終了後に経過報告をしたいと思います。

 

 

 

 

 

 

５時間全セクタ走査した結果、完全にお亡くなりになっていました。

 

今から日本橋へＨＤＤ買いに行ってきます。

 

 

追加メモ

 

dd_rescue

ddrescue

HDD Regenerator

 

こんなのもあるみたい。