HDDでファイルを誤削除、論理的or物理的に壊れた時の作業のまとめ

docker関連の事を書こうと思ってましたが全く違う内容になってしまいました、

プライベートで色々データ保存していたHDDが逝かれてしましました(22年11月末くらい)。大した事ないデータで良かった。
なんとか95%くらいのデータを復旧できたので自分のHDD故障事例からの備忘録として残しておきます。
HDDのエラー症状やら、やっちまった状況によって色々な復旧アプローチがあるので参考にしていただければと思います。

※以降の作業は基本的にUbuntu Linuxベースに作業手順を説明します。

間違ってゴミ箱から消しちゃった場合／rmコマンドで消しちゃった場合

photorecを使う事で復旧できる可能性があります。
photorecはパーティションの中身を全捜査してファイルと同じパターン(例えばJPEGヘッダを見つけたらJPEG候補として保存していく)を見つけたら復元ファイルの候補としてバックアップ指定ディレクトリに保存していくツールです。
ファイルを消した直後ならかなり高い確率で復旧できます。(ただphotorecの場合ファイル名が復旧できないです。)

UbuntuやDebianならtestdickパッケージに含まれますのでtestdiskでインストールできます。

インストール

sudo apt install testdisk

Windows版photorecもありますが、他にも似たソフトはそこそこあります。自分は古いツールですが「復元.exe」の無償版を良く使ってました。

論理的に壊れてるっぽい場合

パーティション情報の復元を試みる

パーティションを消しちゃったり読めなくなったりした場合、パーティションを正しい状態に復元する事で復旧する事が出来る可能性があります。
testdiskはパーティションテーブルを正しく修正したりするソフトです。
誤ってパーティションを消してしまったりしても復元可能性が高いです。

先述説明したphotorecのインストール時に指定したtestdiskに包含されてるので同じコマンドでインストールできます。

インストール

sudo apt install testdisk

ディスクイメージのバックアップ(ddrescueでディスクイメージをバックアップ)

そもそも復旧操作で壊す事もあるので、復旧操作を試してみる前にddコマンドにてバックアップイメージをとっておいて、そのイメージのコピーに色々試してみるとリスクは少ないです。
古くはddコマンドでイメージをとる事が多いですが、ddの場合バックアップ途中でエラーが発生するとそこで止まってしまい、バックアップが成功しない事があります。
ddrescueはバックアップ途中でエラーが出た場合、その場所を無視してバックアップを継続したり、バックアップ途中で中断(Ctrl+C)して別途再開とかする事ができるので、壊れかけのディスクのバックアップにはうってつけです。

インストール(正式名称がGNU ddrescueなのでgddrescue)

sudo apt install gddrescue

コマンド例

sudo ddrescue "バックアップ元デバイス 例 /dev/sdx" "バックアップ先デバイス/ファイル 例 /dev/sdx or imgfile.img" "ログファイル 例 dd_yyyymmdd.log"

ログファイルを指定すると、前回中断時に読み込んだところから再開したり、最後まで読み込んだ後にエラーで読み込めなかった部分を再度読み込んでみる、みたいなことが出来ます。(凄く便利ですね。)
当然バックアップ元よりも大きなサイズの作業用ストレージが必要になります。

ファイルシステムチェック

Windowsの場合だと接続時にディスクチェックしろとか促される奴です。Linuxだとfsck.xxxとかのコマンドの類です。
エラーが出たからと言って無作為にはやらないほうが良いです。この変更が最後の打撃になりHDDに致命傷を与えることがあるため、慎重に作業を進めるならdd/ddrescureでイメージを確実にとった後にやった方が良いです。

ここまでは論理的に壊れた場合になります。ここからは物理的に壊れた場合です。。

物理的に壊れてるっぽい場合

HDDを繋げて起動しても変な音が出てアクセスできなかったり、dmesgメッセージを見るとI/O errorみたいなログが出てる場合は物理的に壊れてる可能性があります。。
ディスク自体にアクセスできるならddrescueをかけてイメージの取得はしておきましょう。
とれなかったら泣きながら今後の対策を考えましょう。

(ポータブルHDDの場合)分解してSATA直で接続して改善するか試してみる

ポータブルHDDでも内部はSATAのHDDであり、USB3.0→SATA変換基板を内蔵している場合が殆どです。
USB3.0→SATA変換基板が壊れているだけで、HDD自体は問題ない場合、分解してSATA直で繋ぐことでアクセスできることもあるので試してみます。

ウォームアップしてからファイルアクセス／ディスクアクセスしてみる

電源直後のディスクが回転し始めたばっかりのときはエラーが出る場合でも、暫く回転させ続けて少し暖かくなった状態でアクセスするとアクセスに成功する様になる場合もあります。アクセスが安定するならばその状態でコピーなど何か出来ないか試してみましょう。

制御基板を新品に交換してアクセスを試みる(高難易度)

HDDの裏にある制御基板にダメージがあり、円盤の部分が無傷な場合に復旧の可能性があります。
下記リンクにあるような方法でドナー用のHDDを持ってきて制御基板を交換(古いHDDからEEPROMのみ付け替える)みたいな事をすることで復活する事もあるそうです。(自分はやった事ないので参考までに)

■壊れたHDDを基板交換して修理
https://www.cocoa.ne.jp/archives/6598

自分の場合どうだったか？

• 自分はADATA製のポータブルUSB-HDD(2TB)を使ってたのですが、USBで接続しても中々認識できず、暫くマウントしてると自然に切れてしまう症状に見舞われました。トップにあるディレクトリにアクセスすると1段深い場所のファイルリストが見えずエラーで切れる。。
• こりゃやべぇ物理障害っぽい、と思いこれからどうしようかと考え、とりあえずddrescueでddが出来ないかトライする事にしました。(イメージ吸出しの為、2TBより大きなHDDが必要)
• 認識している間にddrescueで少しづつバックアップしていくも速度が出ない。100KB/sくらい、遅すぎ、100日以上かかる予定とか、、無理でしょ、、
• USB-SATAの変換基板が悪さしてるのかな？と思い筐体を分解。デスクトップPCにSATA直で接続してUbuntuからアクセスしてみるも、そもそも認識すらしない。SATA変換基板ありだと認識する。なんだそれ？
• HDD裏の制御基板が逝かれてるのかなーと思い、制御基板を交換する手順を見つけるも、これで治らなかったらショックだなと思い、躊躇(まあそこまでするデータでもないし、)
• とりあえず3日くらいddrescueし続けてみるも(速度は依然100KB/s程度)、なんか最近は切断されなくなったな、と思い、ファイラから直接コピー。
• そこそこの速度(40～80MB/s)でコピーできてる。コピー元とコピー先のデータを比較してみるも、ファイル総サイズがなんかおかしい(マイナス10GBくらい足りない)。
• まあこれが復旧できる限界だったのだろう。ここで諦めよう。

故障しないための予防策？対策？

• 信頼できるメーカのHDDを使う。
  →自分の場合はADATA製の安いポータブルHDDが逝かれてしまいました。分解すれば分かるのですがHDD本体は有名どころのSeagate製だったりするのですが、SATA-USB変換基板はADATA製なのでそこがネックで壊れ易い可能性もあると思います。やはり信頼できる大手メーカ製を使った方が良いと思います。
• 2.5インチのものより3.5インチのもの
  →基本的に3.5インチの方が長寿命(ただ衝撃性は3.5インチの方が弱い可能性がある)
• 大事なデータは別のHDDにミラーリングしとく。
  →RAID構成のNASとかかなぁ、皆様も全ファイルの保存にそこまで対策してるのかな？
• クラウドストレージに移行？
  →ランニングコストが、、そもそもクラウドに上げたくないデータもあるしなぁ

(最後に)HDD壊れたら分解しちゃいますよね？

参照にしたURL

■「PhotoRec」の使い方 - パソコントラブル解決 PCと解
https://pctrouble.net/software/photorec.html

■「TestDisk」の使い方 - パソコントラブル解決 PCと解
https://pctrouble.net/software/testdisk.html

■「ddrescue」の使い方 - パソコントラブル解決 PCと解
https://pctrouble.net/software/ddrescue.html

■壊れたHDDを基板交換して修理
https://www.cocoa.ne.jp/archives/6598