2020年3月12日木曜日

HDDの論理障害が発生したのでデータを復旧した話

普段使っている、ウェスタンデジタルのHDD(WD20EZRZ)がある日突然論理障害を起こしてアクセスできなくなったので、自分でデータ復旧を行った話を軽く時系列順にまとめました。

■おやくそく
データ復旧作業には、データ全喪失の危険性が常に付きまとう。
「HDDから異音がするなど、明らかな物理障害の兆候が見られる場合」や「喪失が許されないデータや、仕事で使うデータが入っている」ような場合は、絶対に個人でのデータ復旧を試みてはならない。
個人でのデータ復旧作業はあくまでも実験や遊びと同程度のものであると考え、完全な自己責任の下で行うべきである。
また、この記事はあくまでも日記であり、データ復旧の方法を紹介するものではなく、この記事を参考にして行ったデータ復旧によって損害が起きた場合も一切の責任を負わない。

■今回の作業環境について
・PC: 富士通 LIFEBOOK SH75/C3, Windows 10 Pro 64bit
・内蔵ストレージ: Sandisk SD9SN8W-256G-1016 (M.2 SATA 256GB)

・復旧対象のHDD: WD20EZRZ(3.5インチSATA 2TB)
→元々デスクトップPCで使っていたデータドライブ。PCを入れ替えた後も外付けキットを介して上記PCに接続。ファイルシステムはNTFS、パーティションはGPT。

・作業用ストレージ1: Intel SSDSC2KW256G8 (2.5インチSATA 256GB)
・作業用ストレージ2: SanDisk 64GB SDXCカード(並行輸入品のよくわからんやつ)
→PCの内蔵ストレージの空きがないため、データ移行の際に補助的に利用(そして作業に手間取った要因でもある)。

・外付けキット: フリーダム社のこの製品(SATA 1.5Gbps ⇔ USB2.0)
→上記のHDDや作業用SSDにPCからアクセスする際に使用。速度が非常に遅く、私の環境では最高でも30MB/s前後の速度しか出ない。その代わりに非常に安定した読み書きができるので、信頼して使用している。

・今回の復旧作業の立役者: Ubuntu 18.04.3 LTS (Live USB)
→Testdiskを叩いたり、辛うじて読み出せるようになったHDDからデータを引き抜いたりするのに大活躍。

■障害の発覚と状況の切り分け(時刻はJST)
・3/10 18時頃
いつものようにHDDをWindowsにつないでも認識されない(Dドライブをフォーマットしますか?の表示すら出ない)。
Adminでログインし、ディスクの管理画面からHDDを見てみても、パーティションがNTFSであるともRAWであるとも書かれておらず、ディスクの容量も16384GBと、明らかにおかしな表示。そのうえ、ドライブレターが消えている。これではchkdskコマンドを叩けないため、Windowsでの対処は困難と判断。
HDDからの異音もなく、CrystalDiskInfoからのSMART情報の読み込みも成功。不良セクタ等の表示にも異常が無いことから、論理障害を疑う。

・3/10 22時頃
作業用SSDにUbuntu起動イメージとRufasをダウンロードし、LiveUSBの作成完了。これ以降はUbuntuを主に使用して作業を進めていく。

・3/10 23時以降
gparted、ntfsfixなどを試したがパーティションが読み込めない。
sudoでapt updateとapt install testdiskを叩き、testdiskからEFI GPTを選択してクイックスキャン。
希望するファイルやフォルダがずらっと並んでいることを確認した。

■障害からデータを救出する作業
・3/10 23時以降
testdiskで発見したパーティションの痕跡が正常っぽかったため、そのままWrite。
結果、Ubuntuからはファイルが正常に読み出せる状態に。

・3/11 0:30頃
Windowsからファイルが読み出せるか試行も、「ファイルシステムがRAWである」と表示され、フォーマットを促される(怖いからやめてくれ!)。ドライブレターが復活するも、この状態ではchkdskでのファイルシステム修復も出来ない。
再度testdiskでの復旧を検討しつつ、パーティションの復旧方法を模索する。

・3/11 1:00頃
再度Ubuntuに入り、最低限必要なデータを退避させる作業に入る。
この際、Ubuntuから作業用のSDカードにデータを一旦移動し、その後Windows上から作業用のSSDにデータを移行してSDカードの残量を空けるという方法をとったため、非常に手間取ってしまった(作業用SSDの都合上Ubuntuから書けないことや、作業環境の貧弱さなどが関係した)。

・3/11 2:00頃
作業を一時中断。

・3/12 0:00頃
データ退避作業の再開。この時点では最低限必要なデータのみを作業用SSDへ退避させている。

・3/12 3:00頃
データを退避させたため、testdiskから再びWriteを試みる。
相変わらずUbuntuからはファイルが読めるも、WindowsではRAWと認識されてフォーマットを促される(chkdsk叩けない)。
HDDの状況がこれ以上良くならないことを確信。

■最終的な復旧方針
・必要なデータはHDDから作業用SSDやSDカードにすべて待避。
→完了。不要なデータもHDDに多く存在したが、今回はすべて見捨てることにした。

・HDDは一度フォーマットし、パーティションやファイルシステムを消して書き直す。
→完了。

・HDDに試験的に少量のデータを書き込み、問題なければ待避させたデータを戻して復旧完了。
→HDDの健全性を確認したため、データを書き戻す作業を継続中。
→完了(3/13)。現状ではHDDや保存したデータに異常は見られない。


■今回の障害の原因は?
・以前「HDD用の外付けケース」を2台ほど試したことがあるが、2台とも連続読み書き中にフリーズするという粗悪品であった(変換基板の熱暴走っぽい)。
・HDD外付けケースに内蔵した当該HDDへのデータの書き込み中に、Windowsを巻き込んでフリーズし、そのたびに外付けケースの電源を途中で落としたり、USBを引っこ抜いたりしていたので、ファイルシステムが破損してしまった可能性がある。
・あくまでも推測であり、詳しい原因は分からない。

■今回の障害における学習ポイント
・HDDの障害原因は必ずしも物理障害や不良セクタが原因とは限らず、今回のような論理障害も起きうる。
・HDDに限らず、大容量ストレージに保存したデータはいつ喪失するかわからない。
・NTFSが壊れるとWindowsからは読めなくなることがあり、Linuxからは読めても修復作業までは困難になる。
・バックアップは重要である。

■今回の障害対応で気をつけたこと
・障害が起きたHDDへの書き込みはあくまでも最小限(testdiskでのWrite)にとどめ、ファイルを移動したり書き込んだり削除する操作は行わず、読み出すだけに留めた。

■感想
作業環境が貧弱で苦労したのと、論理障害からの復旧作業は初めてなので手探りで復旧するのが大変でした。
データを全ロストする恐怖が付きまとう中でこんな面倒な作業の繰り返しをやらされる大変さを考えれば、データ復旧業者の作業費用は決して高いものではないなと感じます。

0 件のコメント:

コメントを投稿

ATmega328P-PUを最小構成で動かす

最近、空き時間にAVRマイコンで遊んでいるのですが、Arduinoボードのように周辺機器や回路を満載せず、最小構成で動かしたいと感じることがあります。 Arduinoボードには、USB-シリアル変換インターフェース、5Vおよび3.3V定電圧電源、水晶発振子やセラミック発振子、電源...