目次
01-31 Landiskと格闘中
01-31 Landisk のデータ復旧
八方ふさがりになってきたので、一旦ここまでの経緯をまとめておこう。
少し前に、使っていた NAS が壊れた。
壊れる前の話も書かないといけないね。
NAS のデータは重要なので、定期バックアップを取るようにしていた。
バックアップ終了時には、管理者（僕）にメールが届く。
ふと気づくと最近バックアップしてない。
最後のバックアップは1か月前だった。
調子が悪いのかな、と思ってリブートしたら、起動しなかった。
これが故障の経緯。
新たな NAS は購入し、バックアップデータを書き戻した。
しかし、この1か月の間に作ったデータが、古い NAS に残っている。
このデータを救出したい。
旧 NAS の機種は、I/O データの landisk HDL2-G2.0。
2008年発売で、1.0T のディスクを2基搭載している。これを raid1 設定で使用していた。
raid1 で、それまで動いていたのだから、ディスクの損傷はないと思う。
再起動できないのだから、ハードウェアに問題がある可能性もある。
しかし、まずはディスクを取り出す。
2台はミラーされた同じもの、と考え、1台は保存。迂闊に手を付けて壊れても困る。
もう1台は、Linux マシンに接続してみる。
landisk に限らず、最近の安い NAS は中身が Linux で、ソフトウェアで raid を実現している。
ディスクには６つのパーテションがあった。
1. boot パーテション
2. root パーテション
3. swap パーテション
4. 拡張 パーテション
ここら辺は、非常に一般的な Linux のパーテションの切り方だ。
ちなみに、boot も root も、この後書く５番目のパーテションも ext3 。
2008年だと考えれば、これも標準的。
4の拡張パーテションの中には、２つの論理パーテションが入っていた。
5. log などが入っている。おそらく /var にマウントするもの
6. 最大の容量を割り振られた、おそらくデータパーテション
6 をマウントして覗いても、中身は空っぽだった。
おや、おかしい。やっぱりレイドが壊れて、データは消失、再構築されてしまったのか。
…とおもったが、df で良く見ると、およそ 1T の容量のうち、半分程度が使われている。
NAS にはデータが 500M くらい入っていた。やっぱりこれがデータ領域だ。
ファイルタイプは xfs 。
今では各種ディストリビューションの標準ファイルシステムとなりつつあるが、僕はそれほど詳しくない。
知っていることとしては、大容量データを扱うためのジャーナルファイルシステムとして新たに設計されたもので、つぎはぎだらけの ext4 なんかよりも「素性が良い」という程度だ。
でも、もちろん ext4 なんかと互換性が無い。
残念ながら僕は互換性のためにまだ ext4 を使っていて、xfs は馴染みがない。
しかしまぁ、大容量も扱えるしジャーナルだし、なにより 2008 年当時には ext4 は信頼性がなかった。
xfs を使っているのは、ある意味当然だろう。
容量は使われているのでファイルは残っていると思われる。
しかし見えないのはなんでだろう。ファイルを見せないようにロックする方法とかあるんだろうか。
ここで xfs のことを調べ、実装方法にミスがあったことを知る。
古い xfs では、ジャーナルの記録が CPU のエンディアンの影響を受けていたそうだ。
「そうならないように設計していたはずなのに、実装ミスだった」とのこと。つまりはバグだ。
現在の xfs では修正されているらしい。
違うアーキテクチャの CPU でマウントする際には、元マシンで xfs_repair してから、新たなマシンでマウントすること。
xfs_repair では、ジャーナル情報を元にファイルシステムの整合性を調べ、チェックが終わったジャーナルは破棄される。
バグがあったのはジャーナル部分だけなので、これで違う CPU でも開けるらしい。
ジャーナルだけが問題なら、ファイル名とかは見えてもいいんじゃないかな、と思うけど、どうも詳細不明。
ともかく、ファイルが見えないことは事実だし、「元マシン」で xfs_repair することも叶わない。
探すと、x86 の Linux で、エンディアンが違う xfs を開くためのパッチ、とかもあるようだ。
しかし、これらは xfs のソースプログラムにパッチを当てるもので、カーネル再構築からやらなくてはならない。
家の Linux マシンは仕事に使っている物なので、自分でカーネル再構築して不安定になると困る。
この方法は見送り。
＃後日追記(2015.2.2)
この節に書いてあること、かなり間違ってました。
「ジャーナル部分にバグがあったらしい」と言っている人がいたのは事実だけど、実際にはエンディアンは「当初は気にしていなかった」というのが事実のようだ。
SGI のマシンから Linux に、まずは動くように移植され、ついでエンディアンの違いを無くすように、非常に多くのパッチが当てられ続ける。
XFS Endian bug Fix と書かれた投稿を探しただけでも、2006年ごろから 2012年ごろまで、非常にたくさんあった。
なので、元マシンで xfs_repair すればよい、という情報自体が誤り。
x86 の Linux でエンディアンが違う xfs を開くためのパッチ、ということを書いてしまったが、これも誤りで、僕がバグ Fix パッチを勘違いしただけ。
xfs_repair すると、/lost+found の中に、読めなくなったファイルが復活する、と書かれている記事もあった。
ただし、ファイル名は数字の羅列になってしまう。
これ、i-node 番号をファイル名にして、アクセスできなくなったファイルを復活させるものです。
（i-node とは、UNIX 伝統のファイル保存方法で、ファイルの実態を表す構造。
UNIX では、ファイルとファイル名は別物で、ファイルはあるのにファイル名が見当たらない、という状況にシステムが気付くと、/lost+found ディレクトリに移動される。）
ただ、先に書いたバグの中には、ファイルのデータ格納に関わるものもある。
このバグが LANDISK に残っているとすれば、「大きなファイルの場合、先頭は残ったとしても、末尾までは保証されない」と思うので、あまりお勧めできない。
データパーテションには手を出せないが、システムパーテションなどは見ることができる。
/etc/samba/smb.conf が 0byte だ。
起動しない原因はこれか？ と思ったけど、情報を調べると、landisk では毎回起動時に smb.conf を自動生成するようだ。
NAS にとって重要なファイルだから、うっかり破損したりしないようにそういう仕組みにしてあるらしい。
ファイル日付を見ると壊れた頃なので、何らかの原因で生成できなかったのかもしれない。
なぜ 0byte になったのかは不明。
自動生成しているらしいが、探してみてもどこで作りだしているのか不明。
うーん、とりあえず、ダメもとで設定ファイルを作ってみようか。
この時、disk full と怒られた。
え、なんで？ いくら root 領域だからって、そんなにギリギリに作ってあるわけがない。
しかし、本当に容量が使い切られている。
/var/log ディレクトリでもあふれたのかな、と思っても、そのディレクトリは無い。
ログ関係は５番目の領域に入っていたし、ちゃんとローテートされていたので問題ないのだろう。
du -s * してみる。
これで、ディレクトリごとにどの程度の容量を使っているかがわかる。
/bin なんかが大きいのは当然として、/usr が不自然に大きい。
追いかけると、/usr/share/usb2 というディレクトリがあり、この下が異常に大きかった。
そして、そこにはデータ領域のコピーがあった。（もちろんほんの一部）
どうやらこれが故障の原因。
このディレクトリは、背面 usb ポートに接続したディスクがマウントされる、マウントポイントのようだ。
定期バックアップのために接続していたディスクが、なぜかアンマウントされたのだろう。
ただし、アンマウントしてあるとはいえ、デバイスとしては接続はされている。
landisk は、デバイスがあるからバックアップを取ろうとして、データ領域の内容を /var/share/usb2 に書き込む。
しかし、そこはデバイスがなく、root ディスクのディレクトリに書き込まれただけだ。
ディスクのほぼすべてを占める領域からのコピーに、当然 root 領域はパンク、disk full になった。
そして、ディスクにデータを書き込めることを前提にしてあるソフトは多い。
これらがすべてうまく動かなくなる。
その一つが、おそらく smb.conf を作り出すためのプログラムで、データを作り出せないまま 0byte にしてしまったのだろう。
再起動に失敗するわけだ。
/var/share/usb2 の中を削除し、ディスクを NAS に戻して起動してみる。
…残念ながら動かない。
もう一度 Linux に接続して中身を見る。
/.autofsck を見つけた。
このファイル、Linux 起動時にファイルシステムのチェック(fsck)を行うためのものだ。
もしかして再起動しない原因はこれか？
再起動しないのではなく、fsck に時間がかかっているだけかもしれない。
＃fsck は非常に遅い。
/.autofsck は、起動後に自動的に作られる。そして、終了時に自動的に消される。
もし正常終了しないと、残されたままになり、次回起動時に fsck が動く。
つまり、なにか異常な状態で終了したので、ファイルシステムを念のためチェックした方がいいよ、ということ。
たしか、最後の再起動時に、いつまで待っても終了しなかったので電源を抜かざるを得なかった。
だから残っているのだろう。
/.autofsck を消したディスクを NAS に戻し、起動してみる。
…だめだ。やっぱり起動できない。
fstab の第6パラメータを 0 にしてみたり、/fastboot を作ってみたり。
（いずれも、fsck をさせないための設定）
しかし、やっぱりうまくいかない。fsck が問題ではないのか。
ふときづいて、NAS から取り出したディスクのパーテションを tune2fs -l してみる。
この中に、「最後にマウントされた日付」がある。
…NAS 上では、どのパーテションもマウントされていない。
PC が起動するときは、MBR （マスターブートレコード：ディスクの第１セクタのこと）からプログラムを読み込み、実行する。
複雑なのでざっくり書くと、このプログラムが第２のプログラムを読み込んで実行し、そのプログラムがさらに OS を読み込む。
Linux の場合、boot パーテションに OS のファイルが入っている。
boot パーテションだけ分けておくのは歴史的経緯もあるが、初期の「OS 読み込みプログラム」が、HDD の冒頭付近のsectorしか読めなかったためだ。
だから、boot パーテションの OS はマウントせずに読み込まれる。
そして、OS が起動すると、root パーテションをマウントする。
root パーテションには起動に必要な設定も、必要なプログラムも入っている。これで無事に起動が出来る。
起動中に、boot パーテションもマウントされ、/boot の下に接木される。
「最後にマウントされた日付」がどうなっているのかわからないのだが、起動時に自動的にルートになるのは含まないかもしれない。
しかし、少なくとも /boot に接木する段階にまでは至っていないことがわかる。
さて、どこで止まっているのか。
なにぶん、動作が全く外から見えないので調べようがない。
landisk には、前面に３つのランプがついている。
１つは電源ランプ。あとの２つは、２台のディスクの状態を示すランプ。
ディスクの状態は、いわゆる「アクセスランプ」ではなくて、異常を伝えるための物。
普段は消灯しているけど、ディスクが動かなかったりすると赤く点灯する。
電源ランプは、通常は点灯。起動時・終了時・なんらかのお知らせがあるときなどは点滅する。
landisk が外に情報を出す手段はこれしかない。
じゃぁ、これを使ってみよう。
ここまでに、起動時に動く各種スクリプトを見ているが、どこかに制御しているらしいプログラムがあった。
…見つけた。/usr/local/bin/ledcont だ。
中を見ると perl スクリプトだった。
I/O ポートを直接叩き、LED コントローラに指示を渡しているようだ。
次に inittab を読む。
UNIX では、OS が起動するとまず init というプログラムが呼び出される。
init は inittab に従って次々とプログラムを起動し、ユーザーが利用できる状況を整える。
ただ、inittab の書き方は、UNIX でも会社によって違うし、Linux でもディストリビューションで違う。
ここまでに気づいていたが、landisk は debian だ。僕が普段使っているのは redhat 系なので、少し違う。
（ちなみに、僕は slackware 系を使っていた時代もあるので、そちらならなんとか。
Netwalker は ubuntu で debian 系なのだけど、システムハックするほど使い込んでない）
ふむ、一番最初に読み込まれるスクリプトは、/etc/init.d/rcS のようだ。
このスクリプトは、 /etc/rcS.d/ 以下のスクリプトを次々起動するための物。
そこで、rcS の冒頭で ledcont を使い、表示を「起動中」以外にしてみることにした。
これで起動してみると…
LED の表示が変わらない。ということは、inittab すら読み込まれていないのか…
というわけで、現状お手上げ状態に。
最初のプログラムすら起動しない状況って、やっぱり本体が壊れている可能性もある。
ちなみに、情報によれば MBR は 0 しか書かれていない、らしい。
一般的なパソコン向けではないので、システムの ROM にブートシーケンスを入れてあるのだろう。
だから、MBR が壊れたわけではない、と思う。
OS の起動イメージが壊れている可能性はある。
実は、boot 領域には、工場出荷時の各パーテションのイメージが、tar+gz 圧縮で入っている。
この中の起動イメージと比べてみたら違っていた。
これは、アップデートがあったので当然。
最新版のアップデートは昨年暮れに出ていて、このファイルをダウンロードしてあったが、アップデートにはなぜか失敗していた。
（ダウンロードは boot 領域内に行われ、アップデートは root 領域に行われる。
先に書いたように、root が disk full だったので失敗したようだ）
このアップデートファイル内にも OS 起動イメージがあった。
昨年末のアップデートでは起動イメージは変わらなかったようで、日付が手元の物と同じ。
diff したら、全く同じ。
つまり、起動イメージに問題は無さそう。
電源ランプは、電源を入れてから
・起動中の点滅
・一瞬だけ点灯
・再び点滅
という動きをする。
点灯するところで何か動きがあるわけだけど、最初の点灯で起動イメージを読み込んで、読み込み終わったところで「起動中」の点滅を終了、その後起動イメージを動かすと、そのプログラム内で再び点滅を始めるのではないか、と思っている。
（思っているだけで根拠はない）
このあと、なぜか root ファイルシステムのマウントに失敗し、そのため init も動き出さないのだろうな。
今後の動き。
まずは、データの保全が大事。
方針は２つあって、Raise Data Recovery for XFS というシェアウェアを使うのが一つ。
これは、Windows 上で動くソフトで、壊れた XFS からでもかなり高確率でデータを復元してくれるらしい。
landisk で使っていたディスクからでも取り出せた、というのだから、先に書いたエンディアンの違い問題も対処済みなのだろう。
シェアウェアなのだけど、21.95ユーロ＝3000円程度。
フリーウェアの似たソフトの場合、復旧率が悪いというので多少の出費はやむ得ないところ。
もうひとつは、新しい NAS の外付けドライブとして無理やり突っ込んでみる方法。
新しい NAS も ARM を使っているので、エンディアンの違い問題は出ない…可能性もある。
そもそも読めない可能性だってあるし、XFS の外付けが読めたとしても、「エンディアン問題対処済み」の新たなプログラムを使っていたら、やっぱり古いバグありデータは読めないかもしれない。
さらに、SATA ディスクを USB 接続するなり、eSATA 接続するなりするためのアダプタを購入する必要もある。
…多分、先のシェアウェア代金より高くつく。
というわけで、方針はだいたい決まっているようなもの。
データ保全できれば、先に書いた「工場出荷状態への復旧」のためのファイルを試してみるのもよい。
これを行うと、多分データは消えるけど、NAS が復活するかもしれない。
同じテーマの日記(最近の一覧)
関連ページ
ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】
ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】
デイビッド・パターソン 誕生日(1947)【日記 15/11/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さっき書いた通り、Windows のシェアウェア、Raise Data Recovery for XFSを試してみた。
まずは、お金を払わないでお試し。
試すだけなら無料で出来るようになっている。
このソフト、一番重要な機能は、壊れたファイルシステムの修復だ。
工夫されたアルゴリズムで、かなり高確率でファイルを救い出せるらしい。
でも、今回の場合、どうもファイルシステムは壊れていないようだ、という確信を持っている。
Windows マシンに NAS のハードディスクをつなぎ、ソフトを起動。
ディスクドライブが見えるので、データパーテションである６番目の領域を指定して、「Explore」。
ビットエンディアンが逆の CPU である、NAS の arm で作られた XFS でも問題なく読めた。
問題無くファイルが見れた。全く壊れていない。
で、取り出せるか試す。ファイルを選んで、Copy to ボタン。
「お試し版では 512K までのファイルしか取り出せないよ」と怒られるが、別にそれでいいので続行。
作業ログが表示され、取り出せなかったファイルがどんどんリストアップされる。
どうやら、512K といいつつ、768K 未満は取り出せているらしい。
でも、そこはあまり喜ぶところではない。
さぁ、半日格闘してどうしようもなかったデータが目の前にある。
3000円程度、喜んで払おうじゃないか。
Registrationを押す。すると、日本語のページに飛ぶ。
ん？ 復旧天使、というソフトの宣伝ページだ。
調べると、「復旧天使」は、Raise Data Recovery の日本語版らしい。
日本の代理店が正式に日本語化し、販売しているようで、販売価格は4000円超。
いや、僕は別に英語で構わないから、と思っても、どこでユーロ建てのお金を払えばよいのかわからない。
ネットで探し、やっと海外の送金ページを見つけ出す。
Avangate という決済会社を通じて支払うようだ。
情報を入力して、カード番号も入れて、支払いを…
あれ、カードが無効だ、と言われる。
何か入力ミスしたかな、と思って何度も試すが、カードが無効だ、と怒られて購入できない。
お金を払おうと思っているのに、一体どうなっているのか。
サーバー不調だったりするのかな、と１時間ほどおいといても改善しなかった。
もしかしたら、僕のカードが VISA の「提携カード」だから、VISA を選んでも認証できなかったのかもしれない。
しかしまぁ、購入できないのは問題がある。
PayPal 払いできたので、わざわざ PayPal のアカウント作った。
PayPal にカードを登録すると、問題なく認証を通った。
そして、PayPal で支払。利用者側にはお金はかからない（販売者側に手数料が課金される）ので、僕としては結局カードで払うのと同じ。
最初の時点でカード使えていれば、ソフト作った会社は PayPal に取られる手数料の分まで手に入れられたのにね。
で、しばしまつ。
…このソフトを使った、という人の話だと、購入して数分でライセンスキーがメールで届く、ということだった。
でも、なかなか届かない。
まず、PayPal から「支払するよ」ってメールが来た。
次に、Avangate から「支払するよ」ってメールが来た。
それからずっとたって、ソフトの開発会社から「支払われたよ」ってメールが来て、ライセンスキーが書かれていた。
10分くらいかかったかな。
これで、問題なくデータがとりだせた。
１か月分のデータだけなので、ほんの少しだけだった。
この作業自体は非常に簡単なのに、ライセンスキー入手に無駄に長い時間がかかったことになる。
ところで、「カード払いシステム復旧しないかなー」と待っていた１時間、ただ待っていただけではない。
その間に、KNOPPIX を試していた。
DVD から直接起動して使える、インストール不要の Linux ディストリビューションだ。
＃気に入ったらインストールもできる
Landisk ではなく、Buffalo の LinkStation の壊れた XFS を、これでデータ取り出したという人がいる。
うーん、最近の Linux では XFS のバグが直っている、というようにも聞くし、もしかしたら、バグ有の XFS ディスクでも読み込めるような工夫があるのかもしれない。
＃僕が普段使っているディストリビューションは、仕事先との互換性を考えて少し古い。
XFS のドライバがバグ有なのかもしれない、と疑ったわけだ。
ダウンロードして試してみる。
ダウンロードに 10分ほど。DVD 焼くのに 10分ほど。
その間に、子供とおやつ食べてた。
で、結論から言うとこれはダメ。
バグが直っている、というのは、エンディアンの影響が無いように改善されたというだけで、古いバグ有ディスクも読めます、ということではないのだろう。
つまり、バグあり XFS を読むには、Windows の Raise Data Recovery for XFSを使うしかない。
…なに、この UNIX のバグの後始末を、 Windows でやらなくてはならない、という状況。
個人的には、Windows はお金を払えばいろんなことが解決できる場所で、Linux は技術と時間があれば解決できる場所だと思っている。
でも、XFS のバグを修復できる技術は僕にはない。
そして、Linux コミュニティーの誰にも、この問題をどうにかしようという人間はいないのだろう。
でも、問題を認識している人はいて、お金を払ってもらいやすい Windows 用のソフトを作った。
ただそれだけのことなのだけど、なにかもやもやとしたものが残る。
「壊れた XFS の修復」とかなら高度な技術が必要だから、金をとれる Windows で、となるのも仕方ないんだ。
実際、Raise Data Recovery はそういうソフトなんだし。
でも、今回の例で言えば、ファイルシステムは壊れていなくて、ただ古い既知のバグがあるドライバで作成されただけなんだ。
この問題を Linux コミュニティがほったらかしにしている、というのがどうも Linux コミュニティの弱点に思える。
Linux があれば Windows なんていらない、と言っている Linux エバンジェリストとか、Linux ハッカーとかは、もう少しこの問題を考えないといけないと思うよ。
＃この件に限らず、Linux ってそういうところばかりなのだけど。
＃Linux コミュニティの中でも、現実的に Windows は必要、と考えている人は、別にそれでいいです。
実際、Windows に Raise Data Recovery があるんだから、Linux 上で同じようなソフトを作るという「車輪の再発明」はする必要ないでしょう。
次の目標：
これで、データパーテションが消えても問題なくなったので、工場出荷状態に戻して再起動できるか試したい。
でも、仕事もしなくてはならないので、いつになるかは不明。
同じテーマの日記(最近の一覧)
関連ページ
ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】
ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】
デイビッド・パターソン 誕生日(1947)【日記 15/11/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【しんいち】 初めまして。 (2017-12-06 16:40:06) |