見出し画像

NASのHDDが壊れてデータを復旧しようと思ったら、思いの外大変だった話

HDDが壊れました。それはもう、突然に・・・・・・。

正確には、SynologyのNAS(DS720+)で使用していた2機のHDDのうち片方で、『重大』エラーを突然吐き、エラーを知らせるメールが届きました。

正直寝耳に水でではありましたが、出てしまったものは仕方ありません。日頃からバックアップは取っていたので、HDDを買ってきて、バックアップからデータを取れば良いだろと楽観的に考えていました。

ところがふたを開けてみると、そう簡単には行かない細かな問題がいくつも隠れていました。今回は、そんな話を書きたいと思います。


1. 唐突に壊れたHDD

これまでにもパソコンのHDDが壊れた事はありましたが、前兆というものがありました。ファイルアクセスが遅いとか、カキンという金属音がするとか、ガリガリ音がするとか。

ところが今回はまったく何の前触れもなく壊れました。

NASのトップページ(DSM)に突如表示された『重大』の文字。焦りました。

まあまあ、まだ慌てる時間ではありません。見たところまだデータにはアクセス出来ていますし、NASの管理画面もまだ正常に動いています。誤検知の可能性もあるので、まずはエラーチェックです。

S.M.A.R.T.テストを実行するも1秒で弾かれる始末

HDDにはS.M.A.R.T.というHDDの故障診断が出来る仕組みがありますので、まずはそれを調べます。

SynologyのNASの場合は、メインメニューからストレージマネージャを開き、HDD/SSDからエラーの出ているHDDをクリックして[健康状態]ボタンをクリック、SMARTタブからテストを行う事が出来ます。

通常であれば検査が行われますが、私の場合は開始1秒で終了。上図のように即エラーだと判定されました。

その他にも再起動してみるとか、一応いろいろ試しましたが、まったく回復する事がなかった為、諦めて交換に向けて作業を開始する事としました。

※ 大事な注意点 ※
HDD故障が疑われる際は、まずはデータの待避を最優先して下さい。
不用意に電源を落としたり、『ディスクスキャン・ディスクチェック・エラーチェック』と呼ばれる機能を実行しないで下さい。
起動システムが壊れていて、再起動出来ない事があります。また、スキャンディスク系はHDDを物理的に酷使するので、物理的な要因で壊れたHDDにトドメを刺す事になります。
今回私はバックアップを事前に取っていたので、その手順をすっ飛ばしてエラー判定を行っているだけです。その点充分にご注意下さい。

画面右上のストレージマネージャアプリを開く
交換後なので『正常』と書かれているが、故障時は『重大』と書かれていた

2. クラウドからの復旧

写真などNASに保存されているデータは、日々クラウドにバックアップしています。私はOneDrive for Business(1TB)を個人で契約しているので、Cloud Syncというアプリを使って、毎晩差分コピーをして同期しています。

また、クラウドに上げたくない個人情報や権利もののデータについては、不定期でUSBのHDDにコピーしています。

今回故障したHDDは写真やテキストデータが入っている領域で、その大部分はクラウドに同期してあるものでした。幸いな事に、その日はまったくファイルを編集していなかったため、データの同期も取れています。

それ以外のクラウドにアップロードしていないデータについては、急ぎもう1機のHDDにコピーを行いました。相変わらず『重大』エラーから回復する様子はありませんが、コピー自体は特に止まる事なく順調に進みました。

【余談】
詳しい方はこの辺りでおやっ?と思うかもしれませんが、お察しの通り、私はRAIDを組んでいません。
普通NASを運用される方はRAIDと言って複数台のHDDを繋いでエラー耐久性を上げたり、速度向上を行ったりするのが一般的です。
ですが私は、2機のHDDの利用目的の関係でデータ書き込みの頻度が異なる事、容量の上限をHDD事に物理的に制限しておきたかったので、あえてRAIDにはせず、『BASIC』という構成にしていました。

取り急ぎのバックアップは終わったので、後は新しいHDDにバックアップデータを戻すだけです。そそくさとHDDを購入してきた私は、DSM上でCloud Syncを起動し、データのアップロードではなくダウンロードが出来るよう、設定を行いました。

ところがここで1つ問題です。Cloud Syncは1つのクラウドサービスに対し、アップロードかダウンロードのどちらかしか設定が出来ないようです。その為、これまでバックアップ用に使っていた設定をすべて削除し、ダウンロードするための設定へすべて書き換える必要があります。これでは復旧後、また一から設定を戻す必要があり、正直手間です。ここはもう少し融通を利かせて欲しかったです。

という訳で設定をすべて書き換え、クラウドからのダウンロードを開始。と、ここまでは順調だったのですが、結局この後230GBのダウンロードに、20時間近く掛かってしまいました。恐らくOneDrive側の混雑回避策だと思うのですが、数10ファイルをダウンロードする度に、数10秒から1分程度インターバルが発生する為、ファイルサイズではなくファイル数が多ければ多いほど余計に時間が掛かるような印象でした。

Cloud Syncでデータをひたすらダウンロードしている様子。
NASなので、PCなしで夜間も放置しておけるのがメリット。
ダウンロード中の負荷はそれ程高くない模様。
右上のネットワークグラフが、数10ファイルごとに0KBになってしまう。

さてさて、クラウドからのダウンロードも終わり、もう1機のHDDに待避した残りのデータも戻せば復旧終了。時間は掛かったけど、カンタンカンタン。・・・・・・となるはずだったのですが、復旧作業を終わらせて2日後、異変に気付きました。

3. データ喪失とHDDマウント

データがない・・・・・・。

とあるフォルダを開いたところ、フォルダ構成は残っているのに中身のファイルだけがなく、もぬけの殻になっている事に気がつきました。

特に削除した記憶はないので、操作間違いかなぁと思いつつも、1つ上のフォルダへ行き、別のフォルダを開いて確かめてみる事に。

結果、一部のフォルダでフォルダ構成のみ残って、ファイルがまったく存在しないという現象が確認されました。一方ですぐ隣のフォルダはすべてデータが残っていたりしていて意味不明です。

ただこのフォルダ、先日のデータリカバリでもう1機のHDDにいったん待避させたフォルダだったので、コピーミスを疑いました。

ですが手元にはバックアップが残っていません。消えているのは購入した音楽データだったので、クラウドから落とし直せば復活は出来るのですが、数10ファイルをダウンロードしてきてフォルダ分けするのは非常に面倒です。となるとやはり元々保存されていたHDDからデータを吸い上げるのが一番手っ取り早いです。

HDDをパソコンに繋いでみると、幸いな事にディスク自体は反応してくれます。ですが、フォーマットがext4だったため、Windowsではそのまま開く事が出来ません。

そこで私が試したのが、WSL(Windows Subsystem for Linux)です。これはWindows上でLinuxを使う仕組みで、Windows10以降であれば標準装備されている機能です。ext4はLinuxで使われているフォーマットなので、これであれば読めるだろう。とマウント(HDDを読み込む処理)を進めてみました。

結果、惨敗でした。

どうやらLVM(Logical Volume Manager)という仕組みでパーティションが構成されている為、マウントするのには少し工夫が必要なようです。LVMでのマウント方法については、ネットにいくつか記載があったので試してみたのですが、何故かこのように「デバイスが存在しません」となってしまいました。どのサイトを見ても、ここまで来ればマウント出来ると書いてあったので、不可解です。

WSLのUbuntu上でLVMボリュームをマウントする為の操作を実行。
/dev配下にcdしてもvg2が生成されておらず、マウントも出来ずじまい。

HDDが壊れているのか、WSLだから出来ないのか。いずれにせよ、これ以上出来る事がなくなってしまったので、この日は諦める事にしました。

4. HDDマウント(再)とデータサルベージ

次の日もマウントが出来なかった事を延々考えていたのですが、ふとある事に気がつきました。

マウントするだけなら、Windowsのフリーソフトあるんじゃね?

ありました。すぐに見つかりました。知っている手法にばかり囚われてはいけませんね。世の中は日々進歩している事を痛感しました。

さて、そのソフトはLinux Reader (https://www.diskinternals.com/linux-reader/) というフリーソフトなのですが、ext4であれば無料でデータの取得が可能です。因みにPro版もあるのですが、ZFSやXFSといったビジネス寄りのフォーマットやBitLockerで暗号化されたHDDをマウントしたい場合でない限り無料版で充分です。太っ腹な開発者様に感謝です。

操作も簡単。ソフトをインストールして、HDDをパソコンにUSB接続したらソフトを開くだけです。

見た目はこんな感じ。シンプルですね。赤線の部分がすべて同じHDDなのですが、Volumesの/volume2_2だけ、問題なく動きました。仕組みはよく分かりません。

Linux Readerの画面。パソコン自体のHDDと今回繋いだHDDの両方が見える。
NASのHDDはLVM構成の中身がすべて見えていて、とてもおもしろい。

Volumesの/volume2_2をダブルクリックすると、普通にフォルダ構成がこのソフト上でみる事が出来ました。

操作感は普通の昔ながらのエクスプローラと同じなので、目的のフォルダまでダブルクリックを繰り返して行くと、目的のファイルが保存されている事を確認しました。

そこからフォルダでもファイルでも構いませんので、右クリックしてExportと押す事で、このように保存するか、ドライブ自体をマウントするかの選択肢が出てきます。どうなるのか分からなかったので、ファイルを保存を選択したところ、デスクトップに保存する事が出来ました。(保存する先の指定もきちんと訊いてくれます)

Linux RederでExportを選択すると、保存・マウント・FTPに
アップロードの3種類から選ぶ事が出来る。

ところが保存されたフォルダを開いてみると、バックアップと同様、フォルダ構成だけきちんと残っていて、ファイルだけがまったくない状態に。

同じように別のフォルダもいくつか開いてみましたが、バックアップと同様、ファイルが保存されているフォルダは問題なく、ダメなフォルダはフォルダ構成だけしっかり残っていて、もぬけの殻という状態でした。

どうやらNASが知らせてくれたエラーというのはこれだったようです。HDD自体は普通に動いていたので謎でしたが、一部のデータが吹っ飛んでいたようです。

という訳で、諦めて購入したサイトから1つ1つ頑張ってダウンロードし、フォルダに格納するという、楽しい作業が始まるのでした。

5. まとめ

以上、NASのHDD故障からデータサルベージまでの流れについて書いてみました。

今回のことからの教訓としては、

  1. データのバックアップ場所は復旧のしやすさも考えて決めよう

  2. 復旧に手間を掛けたくなければ、バックアップは全ファイル対象にしよう

  3. 世の中の開発者様に敬意を払いつつ、ラクな方法でサルベージしよう 

といった感じでしょうか。NASが突然壊れてデータサルベージの為に、まさに検索を掛けている方は、とりあえず4章だけ読めばOKです。

データバックアップにご興味のある方は、よろしければ全部読んで下さい。

技術が大好きな凄腕エンジニア様は、3章の答えを教えて下さい (笑)

そんな感じで、皆さんは私を真似る事なく、日々のバックアップを怠らずに楽しくラクなNAS運用を行って下さいね。

この記事が気に入ったらサポートをしてみませんか?