PC系セットアップ覚書

NASが壊れた!! NAS上のファイルは?! 2014/01a

　表題のとおり。突然、NASにアクセスできなくなりました。バッファロー社のNASで、 LS-WS1.0TGL/R1WH [URL] というやつです。 発売は2008年みたいですけど、私が使い始めたのは 2009年3月からのようで、 5年弱ほど使い続けているモノになります。

　あれ? 何かトラブル?? と思い、NASの80番ポートにアクセスしてみたところ、 意外な表示が‥。

RAIDアレイにエラーが発生しました。 本製品ではお客様ご自身によるHDDの交換、及びRAIDの再構成をサポートしておりません。 ご迷惑をおかけ致しますが、添付マニュアル、弊社ホームページに記載の弊社サポート窓口まで ご連絡をお願いします。

‥‥‥口あんぐり。マジか!!

　そこでまず。NASの電源を一旦落として、何事もなかったかのように再起動してみますけど‥ダメだ ダメですね全然ダメだ。この時点で、妙な脂汗が出てきます。落ち着け、落ち着け‥。

[Table of Contents]

とりあえずデータだけ何とか

まず、このNAS装置そのものは ここで捨てるしかないだろう、と腹をくくります。 もし万事うまいこといってNASが再度使えるようになったとしても、 次いつトラブルを起こすかわからない状況になったものを使い続けるわけにはいけません。 なのでNASを捨てることは良いとして。

　問題なのは、NAS上にあったデータです。これを 全部は無理としても、ほんの一部であっても 回収できないだろうか。‥もちろん、こんなこともあろうかと、 重要なデータについては日頃から別ディスクにバックアップするようにしていましたので、 それほど致命的なダメージを受ける状況ではないですけど。でも、そんなに重要じゃないデータで あっても回収できるものなら回収したいじゃないですか。しかも私はこのNASをRAID1モード、 つまり「データを内蔵する2つのディスクの両方に書いておく(ミラーリング)」感じで使っていましたので、 もしディスクの片方がパーになったとしても、どちらかのディスクにはデータがちゃんと 残っている可能性が高いわけで。それを、この手のトラブルがあったからデータ全部あきらめるなんて、 じゃあ一体 何のためにRAID1で使ってきたのか?! という話にもなりますよね。

　ということで。データ回収のための方針をたててみます。こんな感じです。

• NASを分解して、その中にあるディスクを取り出す
• バッファローのNASはどうやらXFSというファイルシステムを用いているらしい。 XFSを扱える環境(Linux)なら、ディスクが大丈夫のはずのディスクからデータにアクセスできるはず
• アクセスできたデータの退避

これらについて、順にメモを。

[Table of Contents]

NASからディスクを取り出す

NAS筐体を見てみますが、どこにもネジらしきものが見当たりません。ややや?! ‥と思い、 調べてみたところネジは全く使われていないようですね。参考にしたのは‥

• 「分解 (disassemble)」(LinkStation／玄箱をハックしよう)
• Buffalo NAS LS-WS500GL/R1 HDD換装 ［本体分解］

最初のツメを外すのにけっこう苦労しましたけど、最初のツメを外した後は順調に解体できました。

　取り出したのはSATAの2.5インチのハードディスクです。 SATAのディスクをどうやってPCに接続するか? ‥ちょっと悩んだんですけど、 ちょうどSATA-HDDに対応した外付けHDDケース(USB接続)がありましたので、 それを使ってUSBでPCに接続することにします。

[Table of Contents]

データの読み込み

[Table of Contents]

手元のFreeBSDではダメっぽい?!

私の手元にちょうどFreeBSDマシンがあったので、まずそれで何とかできないか考えます。 けど、たぶんムリだろうとの結論に達します。ディスクの救済には、XFSのディスクの 何かをクリアしないといけないらしいとか何とかという話をネットで見かけたんですけど。 私の手元にある FreeBSD ではXFSにはリードオンリーでしか接続できない、つまり 読み込みしかできないから、XFSディスクの何かをクリアすることはできない‥。 そんな感じみたいで、残念ながらFreeBSD以外の何か‥‥具体的にいうと、 Linux系の何かを用意するしかなさそう。そういう結論に達したのです。残念。

[Table of Contents]

なるべく小さいLinuxパッケージを

ネットでいろいろ調べると、Debian とか Ubuntu を使って‥というパターンが多いみたいですけど。 しかし、単にXFSのディスクの中身を吸い出すために、わざわざ LibreOffice みたいな超巨大なソフトウェアが含まれたパッケージをダウンロードなんてこと、 やってられません。脂汗を流して心臓バクバクいわしてる状況で 巨大なパッケージのダウンロードを長時間待ち続けるなんて、ある種地獄にいるような気分じゃないですか。 耐えられません。 なので使えそうな、それでいて小さなパッケージを探してみます。

　そこで目をつけたのが SystemRescueCd [URL]というパッケージ。 ‥ どうやら「緊急用」に特化したパッケージらしいとのこと。ISOのサイズが450MB程度なので、 これも十分デカく感じますけど、でもUbuntuなどよりだいぶ小さいじゃないですか。 それにディスク救済などの緊急事態に特化してるっぽいのも良さげで、すごく効きそうです。 500MB未満ということで、CD-R に焼く際に容量的な不安がない点もポイントですね。 (CD-R焼きには かんべ [URL] というやつを使用しました)

[Table of Contents]

SystemRescueCd を使ってみる

さっそく SystemRescueCd でPCを起動します。Linux が起動したら、 問題のデータが入っているUSB外付けドライブを接続します。ちょっと待ってから

# dmesg | tail -25

これでシステムのメッセージを見てみます。すると、いま接続したディスクは sdc として認識されてるっぽいことがわかります。認識されたということは、 ディスクがお亡くなりになった訳ではないということか‥。

次に実行したのがこれ。

# fdisk -l /dev/sdc

いま接続したディスクが sdc として認識されてるらしいということで、 そのディスクがどんな構成になってるのかを見てみます。この結果、 このディスクには /dev/sdc1 から /dev/sdc6 まであることがわかります。 しかも Blocks のへんを見ると、ターゲットは /dev/sdc4 か /dev/sdc6 の どちらかだな、ということがわかります。その2つだけ、ディスクの容量を示す数値が巨大ですから‥

[Table of Contents]

XFSのパーティションにアクセス

では、いよいよXFSのディスクにアクセスするための xfs 系コマンドを使ってみましょう。 まずは xfs_check です。ただ、アクセスすべきターゲットが sdc4 か sdc6 かよく わかりませんので、とりあえず順番にやってみます(大丈夫?)。

　まず /dev/sdc4 に対して xfs_check を実行してみます。

# xfs_check /dev/sdc4

なんかいろいろメッセージが出るんですけど、その中に

xfs_check: /dev/sdc4 is not a valid XFS filesystem (unexpected SB magic number 0x00000000)

こんな文字列があることを発見しました。「/dev/sdc4 はXFSファイルシステムと違うんじゃ?」と 言われています。どうやらこちらはハズレみたいですね。

　ということで、消去法的にターゲットは sdc6 ということですかね。 試しに /dev/sdc6 に対しても xfs_check を実行してみましょう:

# xfs_check /dev/sdc6 xfs_check is deprecated and scheduled for removal in June 2014. Please use xfs_repair -n <dev> instead.

「(大雑把訳) xfs_check、いろいろあって、2014/6に抹消すっから。だから、かわりに xfs_repair -n 使ってな。」‥というメッセージは出ますけど、それ以外の メッセージは出ずに無事に終了します。ターゲットは /dev/sdc6 で、しかも xfs_check で何も文句は出なかったということで、 この時点で「いける。きっと、いける」という気持ちになってきました。

　そしていよいよ xfs_repair です。 正直、このコマンドが何なのかよくわかってないんですけど、 皆さん実行してるみたいですんで(^_^;

# xfs_repair /dev/sdc6

ネットでは -Lv オプションを付けてるのが多いですけど、逆に、-Lv は付けないほうがいい と書いてるページも多いみたいで、どっちに従うべきかわかりません。 とりあえずオプションなしのほうが安全ぽいので、そっちに従ってみます。

　実行してみた結果、 とりあえず、とくにエラーっぽい文字列も出ずに、xfs_repair は終了します。 これでディスクに問題がなければNASに取り残されたデータにアクセスできるはず。 さっそく。マウントしてみよう!

[Table of Contents]

ディスクの中身が読めるか?

　まず即席のマウントポイントを作っておきます。

# cd /root # mkdir mnt

そしていよいよマウントです。

# mount /dev/sdc6 mnt mount: unknown filesystem type 'linux_raid_member'

　‥あらら? ‥と、ここから いろいろ調べた結果 (たしか、この過程でPCを再起動してます)、 dmesg の出力の中にこんなの:

md: <bind sdc6> md/raid1:md124: active with 1 out of 2 mirrors md124: detected capacity change from 0 to 492011454464

こんな感じに書かれた行があるのを見つけました。ひょっとして、 この外付けHDDはすでに単なるディスクではなく raid として認識されているんじゃ ないか?? と気付きました。

　ということで。sdc6 ではなく、sdc6 を使ってるらしき raid のほう、 上のメッセージを見るとたぶん /dev/md124 というやつ、それにマウントしてみます。

# mount /dev/md124 /root/mnt # cd /root/mnt # ls mt-daapd share spool

うお! 共有データを置いていた share が見えてるじゃん!! やった!!!

【新品】APPLE Mac mini 500GB MD387J/A MD387JA [2500][在庫あり]

[Table of Contents]

データをMacに退避

ようやくアクセスできたデータ、どうやって回収する?

　ここで私が使ったのがMacintoshです。 Mac OS X は Mac の皮をかぶった unix ですから、sshd とか rsync とかは 標準装備してます。それを使うのがたぶんいちばん早くて楽だろうということで。

　Windowsでsshd起動して、そこからrsync使ってファイル転送‥。ひょっとしたら、 そういう方法もあるかもしれませんけど。ちょっと調べるのが面倒すぎなので 今回は迷わずパスです。

　退避の方法ですけど、まずMac側の設定。「システム環境設定」から「共有」、その中にある 「リモートログイン」を有効にします。すると画面にこんな感じ:

このコンピュータにリモートからログインするには、
"ssh xxx@yyy.yyy.yyy.yyy" と入力してください。

こんな感じの表示があるはずです。ここで xxx のところが「ユーザ名」、 「yyy.yyy.yyy.yyy」のところがMacのIPアドレスというのはOKですよね? (ちなみに、リモートからアクセスする際には、この「ユーザ名」に対応した パスワードが必須のはずです。「パスワードなし」で使っている場合、たしか リモートからアクセスできないはずなので注意です。)

　これでサーバ側の準備はOKです。 SystemRescueCd に戻りましょう。

　SystemRescueCd で以下を実行しましょう。

# cd /root/mnt # rsync -av share xxx@yyy.yyy.yyy.yyy:Desktop Password:

rsync を実行すると、Mac上のユーザ: xxx のパスワードを聞いてきますので、 入力します。すると、 SystemRescueCd 側の rsync と、 Macに標準装備されている rsync とが(ssh 経由で)勝手に(?)連携して ファイルのコピーを開始してくれます。 上の例では、Mac のデスクトップに share というフォルダが自動的に生成され、 その下に NAS にあったデータが保存されていくはずです。 rsync に -av オプションを指定したので、 SystemRescueCd 側の画面には、作業が終了するまで 作業状況がダラダラと表示され続けるはずです。 それを、たぶん丸一日以上、ずーーっと、眺め続けるうちに 作業は終了するはずです。

　私の場合、ディスクそのものにはとくにトラブルはなかったみたいで、 無事にファイルの回復には成功しました。やれやれ。

【送料無料】バッファローRAID対応ネットワーク対応HDD（1TB・サファイアブラック）　LS-WSX1.0...

[Table of Contents]

その後

こうしてMacに一時的に退避させたデータですけど、結局、また バッファローのNAS LS-WSX1.0L/R1J (のはず) を用意して、そちらに 移して以前のとおりに使うことにしたんですけど。使っているうち、いつのまにかNASが 接続解除されてしまい、一旦そうなると 電源コードを一旦抜くしか対応策がなくなる という、 非常にどうしようもない状況になってしまいます。何なのか? と思い、いろいろ調べてみましたけど。

• NASのIPアドレスに対してPINGを打ってみると応答あり。 (ネットワーク接続はOK)
• NASを外見から見た感じ、なんか異常が起こってそうな雰囲気なし (ハードの故障ではない?)
• Web管理画面にアクセスできない (ソフトがおかしくなってる?)

これらのことから、たぶんNASがハングアップ(フリーズ)状態になっているんじゃないかと推測しました。

　ええ? NAS がハングアップ?! ‥と思って検索かけてみたところ、こんな:

LS-V1.5TLを使用中の方、時間がたつと消えませんか？？？
http://bbs.kakaku.com/bbs/K0000148493/#12283733 (2010/11/27〜) (2014/1現在はここでアクセス可能)

こんな話題を見つけてしまいました。

　ここで紹介されている対応策というのは、具体的には

「メディアサーバーを使用しない」にする

‥と、こんな感じのようです。つまり、どうやらNAS内に多くのファイルを置いている場合、 それらのファイルも管理しようとしたNASの「メディアサーバー」機能は、 想定外に多すぎるファイル数に対処できなくなってハングアップしてしまう感じらしいのです。 それゆえ、私のように小さいサイズのファイルを大量に置くような使い方をする場合は、 「メディアサーバー」機能をオフにするか、普段NAS用に使っているフォルダを 「メディアサーバー公開フォルダー」から除外してやればいいみたいです。

　‥私もこれをやってみたところ、意外といい感じのような気がしています。 (Webで管理画面にアクセスするとき、それまではWebの管理画面のレスポンスが遅くて 「なんでたかがNASのWeb管理画面でこんな重いのか?!」とイライラしていたんですけど。 メディアサーバー機能をオフにした途端、NASのWeb管理画面がサクサク動作するようになりました) また何かあったらここに追記します。