つい先ほどDebian化が一通り終わった自作PC。
Debian化で相談に乗ってもらったAI「Gemini」さんに、同じ話の流れで、将来に一縷の望みを託して10年ほど前にコールドスリープさせた破損HDDについて、ふと次のようなことを尋ねてみました。
実は昔、IOdataのRECBOXというNASを使っていました。10年ほど前のことかと。
家族の写真もそこに格納してたんですが、3年ほどという極めて短い時間でHDDが読みだせず、使えなくなってしまいました。
どうしようもできないなかで最後の手段で分解し、HDDを取り出すことは出来ました。IOdataのRECBOX内にはHDDが一つ入っていました。が、残念なことに中身を読むことがまだできません。
HDDレスキューの市販ソフトを買ったら、中身をレスキューすることはできませんでしたが、レスキューソフトはデータ格納パーティションタイプがUbuntu RAIDであることだけは判別できました。
このHDDのデータを、DebianかUbuntuを使い、格納データの中を復元することは出来るかどうか、ご存じですか？
するとその後の
Geminiさんの丁寧な手引きにより、なんとコールドスリープHDDのデータが甦りました
【ご注意・免責事項】
本記事に記載しているデータ復旧手順やコマンドの実行は、当ブログ著者の環境における体験・実施記録を共有するものであり、あらゆる環境での成功や安全性を保証するものではありません。
障害が発生しているハードディスクや記録メディアへの操作は、状態を悪化させたりデータを完全に喪失させたりするリスクを伴います。試される際は必ず重要データのバックアップやイメージ退避を行った上で、ご自身の責任において実施してください。
当ブログにおける免責事項の全般につきましては、以下のページをご確認ください。
🔗 免責事項 – LoHaS.com（ポートフォリオ）
以下に述べる経緯は、AIに聞けばそれで済む内容です。
それでも今回は個人的にとても感動したので、Geminiさんに手引きいただいたその手順を、以下の通り記事にいたしました。
作業環境
使用マシン: ASUS M4A88TD-M EVO / AMD Athlon II X4 605e
OS: Debian trixie
対象機器: RECBOX 内蔵HDD（1TB / XFS）
作業用ストレージ: Seagate BarraCuda HDD（2TB / EXT4）
救出に使用したツール:
ddrescue（障害HDDからイメージファイルへのセクタ退避）PhotoRec（イメージファイルからのバイナリ直接レスキュー）exiftool（Exifデータ解析および撮影年月別自動振り分け）
ディスク認識とRAIDアレイの構築（HDDの状態が芳しくなく未完了）
mdadm、lvm2を導入しました。
Linux で RAID と LVM を扱うための標準ツールだそうです。
sudo apt update
sudo apt install mdadm lvm2接続したHDDのデバイス名確認
作業の前に、まず復元対象のHDDがどのデバイス名（/dev/sdb や /dev/sdc など）で割り当てられているか確認します。
sudo lsblk -f接続したRECBOXのHDDパーティションは/dev/sda5、linux_raid_memberでした。
mdadm による RAID 読み込み
RECBOX の内部システムが作成したRAIDアレイを、安全のために読み取り専用（Read-Only）でアセンブル（組付け）します。
sudo mdadm --examine /dev/sdX* # ※sdXは復元HDDのデバイス名この表示をスクショしてGeminiに見せたら、次の事を教えてもらいました。
表示された情報から、以下のことが判明します。
- Raid Level : raid1 本来は2台のディスクに同じデータを書き込むミラーリング構成です。
- Raid Devices : 2 / Total Devices : 1 システム上の設計は「2台構成」ですが、このHDD自体（あるいはNAS内部）には「1台」しか存在していません。
- Active Devices : 1 / Failed Devices : 1 1台だけで稼働しており（Degraded状態）、もう1台は「切り離された（faulty removed）」扱いになっています。
そして処置として、
欠損（Degraded）状態として強制組み上げ
を奨められました。
sudo mdadm --assemble --run /dev/md0 /dev/sda5 --readonly論理ボリュームの活性化とマウント
RAIDの上にLVMが構築されているケースが多いため、論理ボリュームをスキャンして有効化しました。
sudo vgscan
sudo vgchange -ay最後に、データパーティションを読み取り専用でマウントしようとしました。
# マウント用フォルダの作成
sudo mkdir -p /mnt/recbox
# 読み取り専用でマウント
sudo mount -o ro /dev/md0 /mnt/recboxmountしようとしたタイミングで「failed:構造体を内部消去する必要があります」。
Geminiさんからはnorecoveryオプションをつけてログの復元を行わずマウントするよう勧められ、再び試みました。
sudo mount -t xfs -o ro,norecovery /dev/md0 /mnt/recboxしかしいずれにしてもmountは不可能でした。
そこで次に奨められたのは
xfs_repair によるHDDの診断・修復
です。
xfsprogs をインストールし、
sudo apt update
sudo apt install xfsprogsまずは書き込みなしモードで診断コマンドを実行してみてました。
sudo xfs_repair -n /dev/md0xfs_repairの診断はPhase 1〜7までの段階があるそうですが…
Phase１でfatal error。
もしかしてここで詰んだのではと思いGeminiさんに訊ねたら、
完全に詰んだわけではありませんが、これ以上の直接操作を一旦ストップすべき重要な警告信号です！
表示されている fatal error — 入力/出力エラーです（I/O error）は、ファイルシステムの構造ミスではなく、HDDの特定のセクタ（記憶面）が物理的に読み込めなくなっている（不良セクタの発生）ことを意味しています。
この状態で xfs_repair やマウントを無理に繰り返すと、HDDのヘッドやディスク表面にさらに負荷がかかり、状態が悪化するリスクがあります。
で、2つの選択肢を提案されました。
アプローチ1：ddrescue によるイメージ退避（自力で進める最善策）
破損HDDからイメージファイルを抽出するため、gddrescue の導入。
sudo apt update
sudo apt install gddrescueなおもう一つの選択肢は
｛アプローチ2：プロのデータ復旧業者への相談（選択肢として）｝
でしたので、選択肢は実質一択。
外注せず自力での復旧に挑んだ理由
データ復旧業者への依頼ではなく自力での作業を選んだ最大の理由は、失われたデータが「家族の記録」という代えの効かない貴重な存在だったからです。見知らぬ業者へ委ねるリスクを冒すくらいなら、たとえ失敗したとしても自らの手で全力を尽くす方が納得できると考えました。
また、「課題に直面したとき、自分で考え、手を動かして乗り越える」が本ブログのテーマであり、自身の行動指針です。未知の作業であっても主体性を手放さず、AIをパートナーとして対話しながら完遂を目指す道を選びました。
自分の意志でアプローチ1の「ddrescue によるイメージ退避作業」を先に進め、gddrescueをインストールしました。
並行して、イメージコピー先として1TB以上必要なことを確認したのち、HDDを買いに外出しました。
家から車で5分のPC屋に行き、2TBで19,980円というこの商品を発見。
即買いして帰宅。
一度PCをシャットダウンして、購入したばかりの2TBのHDDを接続しました。
新しい 2TB HDD のフォーマットとマウント（GUI操作）
PCを再び起動した後に改めてlsblkしたら、コピー元のRECBOXHDDはsdbとして、コピー先の新品2TBはsdcとして認識されました。
gnome-disk-utilityをインストールし、
sudo apt update
sudo apt install gnome-disk-utilityGUI画面で新品HDDをext4で初期化。
ボリューム名はBarraCuda2TBとしました。
sudo ddrescue -d -r 3 /dev/sdb /media/xxxx/BarraCuda2TB/recbox.img /media/xxxx/BarraCuda2TB/recbox.logコピー元のRECBOXHDDはマウントさせる必要はないそうです。
ddrescueを実行しました。
pct rescuedが99.99%となるまでは割と迅速に進みました。
Trimming falied blocks…とフェーズが変わったあとから、bad-sectorが刻まれ始めました。
ddrescueが機能してるように見受けられます。
その後フェーズはscraping failed blocks…に切り替わり、non-trimmedが0Bになりました。
あと動いてる数字はnon-scrapedとbad-sector、read errorsだけに見えますので、作業が佳境に入ったと見てます。
長年退蔵し、ずっと見ることができず将来の技術にかけた玉手箱を、今開けようとしている瞬間。
ddrescue画面を見るのはとてもワクワクします。
途中でGeminiさんにこんな質問をしました。
現在non-scrapedが6822kB、bad-sectorが782848B、前回と比べて、進捗した削り出しのうちbad-sectorの割合は何パーセントになりますか?
前回からの進捗において、削り出した容量のうち bad-sector になった割合は 約 38.8%（または約 37.9%）となります。
前回の区間では削り出した領域のほぼ 100% が bad-sector に加算されていましたが、直近の区間では約 6 割（約 61.2%）の領域が物理障害を免れて正常に回収・処理されたことを示しており、非常にポジティブな数値の推移です。
スクレイピングに入ってからは進捗が非常に遅くなったので、一晩放置することにしました。
翌朝。
ddrescueを見てみたら、scraping failed blocks…が終わったようで、retrying bad sectors…のフェーズに入ってました。
このことをGeminiさんに報告。
すると、すでに99.99%を救出しており残りが6.8MBのみなことから、bad-sectorのRetryはここでもうCtrl + Cで中断する、という選択肢も奨められました。
当地は北国で今日は気温もさほど上がらないから熱の心配は無用で、また私はこの日も仕事があるのでいずれにせよ日中は手をかけられないから、晩までは引き続きddrescueを回すことにしました。
晩になり帰宅し、再びddrescueのCUI画面を確認。
bad-sectorのRetryは1巡目を終えて、2巡目に入っていました。
この時にCtrl + Cを押してddrescueを中断。
imgファイルとして救出できたのは1000GB、bad-sectorは5MBでした。
ddrescueによる救出作業が終わったら、いったんPCをシャットダウンさせ、コピー元の破損したRECBOXのHDDを取り出しました。
退避したimgファイルからPhotoRecによる写真抽出
GeminiさんいわくPhotoRecとは、
ファイルシステム（XFS）の壊れたイメージファイルから、写真データのシグネチャ（JPEGのヘッダー構造等）を直接検出・抽出するツール PhotoRec（testdisk パッケージに含まれます）を使って写真を救出します。
PhotoRec（testdisk パッケージ）のインストール
sudo apt update && sudo apt install testdiskPhotoRec の起動
抽出するファイルの保存先フォルダを先に作成し、
mkdir -p /media/xxxx/BarraCuda2TB/recbox_outbbrescueで作成した 2TB HDD 内のイメージファイル（recbox.img）を指定して起動します。
photorec /media/xxxx/BarraCuda2TB/recbox.imgPhotoRecのCUI画面での動作について、Geminiさんから引用。
PhotoRec 画面での選択メニュー
画面が開いたら、以下のキー操作で進めます。
メディアの選択
Disk /media/xxxx/…/recbox.img – 1000 GB が選ばれていることを確認して [Proceed] を選択（[Enter]）。
パーティションの選択
XFS や LVM、RAID などの複雑な区画がある場合、特定のパーティションを選ばず、一番上にある [No partition]（Disk 全体をスキャン）を選んで [Enter] を押すのが最も確実です。
ファイルシステムタイプの選択
[Other]（ext2/ext3/ext4 以外、XFS やその他はこちらに含まれます）を選択。
【重要】スキャンするファイル形式の絞り込み（File Opt）
メニュー下部の [File Opt] を選びます。
s キーを押して全てのチェックを外します。
写真や動画だけに絞り込むため、jpg（JPEG画像）、png、mov、mp4 など、欲しい拡張子だけに スペースキー でチェックを入れ、b キーで設定を保存して元のメニューに戻ります。
※これをやらないと、XFS や Linux システムの無用なプログラム断片ファイルが何十万個も抽出されてしまいます。
抽出ファイルの保存先指定
2TB HDD の中（/media/xxxx/BarraCuda2TB/recbox_out などの新規フォルダ）を指定し、C キーを押すとスキャンが始まります。
png,mpg,mov,jpg,gif,bmp,にチェックを入れてbを押し、設定を保存。
もとの画面に戻り、cを押して実行…
リカバーが始まりました!
jpgなどがリカバーされてます。
この時点で、Thunarでは既に救出された沢山の画像ファイルを確認できました。
8年ぶりの懐かしい写真…
たくさんの画像ファイルを、wordpressのuploadsフォルダのように、自動で年月ベースのフォルダに振り分けることってlinuxでできますでしょうか?
exiftool を使った自動振り分け
ツールのインストール
sudo apt update && sudo apt install libimage-exiftool-perl自動振り分けコマンドの実行
振り分けた画像を保存する整理用の出力フォルダを新しく作成します。
mkdir -p /media/xxxx/BarraCuda2TB/recbox_sorted自動振り分けコマンドを実行します。
以下のコマンド1行で、recup_dir 内の全 .jpg ファイルの撮影日時を読み取り、年/月/ フォルダへ自動移動させます。
exiftool -r -d /media/xxxx/BarraCuda2TB/recbox_sorted/%Y/%m "-Directory<DateTimeOriginal" /media/xxxx/BarraCuda2TB/recbox_out/recup_dir*/*.jpg以上です。
以上で、想像しうるすべての救出作業が完結しました。
8年間もの間、静かに眠り続けていたタイムカプセルが、現代のLinux環境とGeminiさんのおかげで見事に解き放たれ、無事に思い出を取り戻せました。
NASを使う前からの写真も格納してたので、8年間コールドスリープしてたデータは、最も古いもので2002年にさかのぼりました。
8年ぶりに見ることの出来る出産時の写真。家族にも顔向けできます。
なぜ8年前にコールドスリープさせたのか
8年前に、市販のHDDレスキューソフトでは対応できなかった後に、実は一度今回と同じようにLinuxを使った復旧を試みたことはありました。
なぜなら、このブログの過去記事にもしてた通り、割とLinuxには長い間馴染んでたからです。
しかしWEB検索した結果だけでは、8年前当時の自分にはどんなツールをどんな場面に使うのかの判断などの意味が分かりませんでした。
そんな私がそれ以上こねくり回してしまうと、二度と復旧できなくなる恐れがあります。
そこで「いつか私のlinuxスキルが上がる」または「WEB検索の結果自分と全く同様の環境で解決したページが見つかる」か、のいずれかという一縷の望みを託し、HDDを一旦そっ閉じした、という次第でした。
この8年間、私のlinuxスキルは一向に上がらないままでしたが、進化したWEBのほうが今回もまた私を助けてくれました。
助けてくれたGeminiさんにお礼がてら、記録をブログ記事にする許可を確認したら、次のようにご快諾いただきました。
こちらこそ、物理セクタの退避から PhotoRec でのバイナリスキャン、そして exiftool による Exif 解析と集合論理に基づくファイル整理まで、長時間の作業を本当にお疲れ様でした！粘り強い判断と完璧なコマンド操作のおかげで、8年間の時を超えて思い出が無事に蘇りましたね。
ブログ記事での公開につきましては、もちろん大歓迎です！ ぜひ記事にしていただければと思います。
今回の取り組みには、同じように「壊れたHDDを捨てられずに保管している人」や「将来の技術進展に望みをかけている人」にとって、非常に勇気と参考になるポイントがたくさん詰まっています。
- 諦めずに「コールドスリープ」させておいた判断の価値
- ddrescue による 99.99% の粘り強い物理セクタ退避（マルチコアの Linux マシンを投入した判断）
- ファイルシステム構造を無視してバイナリから直接復元する PhotoRec の強力さ
- Exif メタデータ（2018-08-11 18:15）によって解明されたタイムカプセル開口の瞬間
- 生成AIをパートナーとして活用したデータ救出の実践例
8年前のあの日に時が止まったタイムカプセルが、現代のツールと AI との対話によって再び光を浴びたストーリーは、Web 上の素晴らしいナレッジ・記録になるはずです。
私のように大事なデータを放り込んだままのNASがHDDトラブルに遭い、お困りのかたはぜひお近くのAIにご相談してみることをお奨めします。
私がGeminiに課金したのは2ヶ月前ですが、今回の問題解決で何年分ものGeminiサブスクの元が取れました。
ここまで込み入った用件でなくても、例えばもし手元にWin11からあぶれたままのPCがあるかたへ、なんの気なしにAIにLinux化をご相談してみることをお奨めします。
もしこれまで込み入ってとっつきづらいと感じてたことも、AIと対話形式で進めたら、意外とあっさり完了出来て、いつの間にか目の前にLinuxPCが出来上がってるかもしれません、と背中を押してみます。
コメント