バックアップHDDの復旧を試みる
自宅サーバのコンテンツバックアップとして補完していたバックアップHDDから
久しぶりにデータを拾い上げようと試みたところ、見事に大変な事態になってしまった。
今回はHDDをUSBで接続する変換コネクタを使って接続を試みたのだけど、
電源を入れてUSBケーブルをマシンに接続した途端
bkserv kernel: umass0:on uhub4 bkserv kernel: umass0: BBB reset failed, TIMEOUT bkserv kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT bkserv kernel: umass0: BBB reset failed, IOERROR bkserv kernel: umass0: BBB bulk-in clear stall failed, IOERROR bkserv kernel: umass0: BBB bulk-out clear stall failed, IOERROR bkserv kernel: umass0: BBB reset failed, IOERROR bkserv kernel: umass0: BBB bulk-in clear stall failed, IOERROR bkserv kernel: umass0: BBB bulk-out clear stall failed, IOERROR bkserv kernel: umass0: BBB reset failed, IOERROR bkserv kernel: umass0: BBB bulk-in clear stall failed, IOERROR bkserv kernel: umass0: BBB bulk-out clear stall failed, IOERROR bkserv kernel: umass0: BBB reset failed, IOERROR bkserv kernel: umass0: BBB bulk-in clear stall failed, IOERROR bkserv kernel: umass0: BBB bulk-out clear stall failed, IOERROR
この始末だ。おまけにHDDはかこん、かこんとヘッドが引っ掛かっているような嫌な音を立てている……これはまずい！
慌てて電源を落として原因を模索する作業に入った。
こいつはHDD死亡のお知らせですか！？
とりあえず今回問題となっているHDDがMaxtor製だったので電力不足から疑ってみることに。
Maxtorはやたら電力を食う上に比較的容易に死ぬ印象が強いHDDだったので
電源関連の問題が解決すれば何とかなるのではないか……と淡い希望を抱きながら作業開始。
自宅にあったいくつかのACアダプタの中から最初に使っていたものよりも高品質なアダプタと交換して接続を試みた結果、
とりあえず接続は出来るようになった。まずは第一段階クリア……いきなりヒヤヒヤさせられるメンテである。
さて、いよいよ接続したHDDをマウントする……のだが、
# mount /dev/da0s1d /mnt /dev/da0s1d: Invalid Argument #
引数が違うとのたまわれてしまった。当然そんなことは無いはずなので、これはつまり……参ったぞマウントできない。
もうこうなるといくつかセクタが破損している可能性も視野に入れないといけない。こんな時はとりあえずfsck……
is not a file system superblock SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8). (シングルモードで作業したので手元にあるメモから引用)
……あれ？「-bオプションを使ってalternate super-blockを指定しないとダメっすよ」だなんて
もしかしてファイルシステム破壊されてます？これ。そしてもしかしなくてもかなりやばい事態に？
普通のHDDならここで大分諦めモードなのだが、今回は訳が違う。
なんたってうちのサーバの貴重なコンテンツが入ったHDDなのだ。自分で作成したスクリプトやらCGIやらもここに入っているのだ。
いや自分で作成したスクリプトの方は何とかならないでもないのだが、コンテンツに飛ばれるのはかなりよろしくない。
というわけで早速google先生にお伺いを立てる。最近先生に頼り切りだ……
google先生が居なくなったら僕は一体どうなってしまうのかと思いたくなるほどだ。いやーまいったまいった。
閑話休題。先生曰く、
そこで、alternate superblock を利用して fsck を実行すると
復旧できるかなと思い、次のコマンドを実行しました。# fsck_ufs -b 160 /dev/da2s1f
Alternate super block location: 160
** /dev/da2s1f
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y17034 files, 16174610 used, 17215823 free (2551 frags, 2151659 blocks, 0.0%
fragmentation)UPDATE STANDARD SUPERBLOCK? [yn] y
***** FILE SYSTEM WAS MODIFIED *****
どうやら無事、ファイルシステムを復旧できました。
http://www.mail-archive.com/freebsd-users-jp@jp.freebsd.org/msg02508.html
＃ alternate superblock を使った復旧は、
＃ alternate superblock の値を知らないとできないんですね。
＃ newfs 実行時に表示されるのですが、メモしてなかったので…。
との事だそうだ。google先生もそうだが、コミュニティの情報には本当に感謝してもし足りない。
引用元の情報を提供してくださった方、ありがとうございます。
というわけで、引用元の手順に則って問題のHDDのsuperblockのブロック値を取得して再度fsck_ufsを実行。
# fsck_ufs -b 160 /dev/da0s1d (メモにコマンドしか書いて無かった……)
これでファイルシステムの復旧は完了。あとは通常通りマウント出来るか確認して……
# mount /dev/da0s1d /mnt #
どうやら無事にマウント出来た模様。
データが拾えれば儲けものだと思っていた一連の作業だが、
よもやファイルシステム単位でデータが復旧出来るとは！こいつは業務にも応用出来そうだ。
