大学生でもできるDD

DDing:0 1em;”>WindowsUpdateによるディスク情報の破壊

今年最初のWindowsUpdateにより、私のメインPCのデータディスクがアクセス不能に陥りました。 メインHDDはOSのWin10、データ用HDDは2パーテションに分け、写真データ用と別にWindowsのバックアップ用としていました。 このデータ用HDDにWindowsのバックアップを設定したのが、私の失敗でした。

普通はOSからノンアクセスに見えたデータ用HDDに、今回のUpdate失敗（これはMicrosoft側の不適合なデータのせいです）の際に、再起動してはスキャンディスクを行っている様な表示がありました。 スキャンはOSの入ったメインHDDではなく、必ずデータ用HDDに対してだけ行われ、この時点で危険に気付くべきでした。

これはOSに無関係な写真データ用のパーテションを含めた、HDD全体に行われ、この数度の繰り返し（数日の経過）の後に、ディスクアクセスに異常を来したものです。

PCを扱って長く、スクラッチ音の出るディスクからデータを救出したり、HDDの焦げた基盤を同メーカーの別基盤に交換してデータ救出をした経験があり、「なんとでもなる」とたかを括ってデータバックアップが疎かになっていたところが反省点です。

問題のデータ用HDDは、今回ばかりは一般の人が入手できない特殊な業務用システムでないと、データにアクセスする事が不可能に思えてきました。

◎内蔵接続すると、BIOSにはディスクが認識されるが、このHDDの認識には異常に時間（数分）がかかる。

◎正常HDDとの違いは「S.M.A.R.T.  Capable but Command Failed」の表示。 物理的障害とは考え難く、重度論理障害と思われます。

◎内蔵接続すると、このHDDのアクセスランプが常時点灯し、正常なシステム動作の足を極端に引っ張る。 Win10は20分という超々鈍足で起動し、結果的にこのHDDを認識できない様子。（このHDDを切り離すとWin10は正常）

◎外着けUSBアダプターでWin10に接続すると、最初はHDDを認識、ドライブアイコンが出るが、OSのアクセスチェックが数分かけて行われ（黄緑のバー）、最後にアイコンが消え、デバイス画面のHDD表示も消える。

以上の状況から、USBアダプターで接続して、Windowsで使用可能な救出アプリ（フリー版）5～6社を試すが、「Win10が認識出来ないHDDには何もできない」というのが結論でした。

DDing:0 1em;”>Linux（Ubuntu）を試す

前置きが長くなりましたが、ここからが本題。 信頼できそうなHDD修復業者は 5～10万の修理価格を提示します。 これは最後の手段として、出来る限りの事はしたい。 それには、異なるOSでこのHDDにアクセスするしかないと考え、Linuxの門をたたきました。 Linuxは全く初心者ですが、調べるとDVDだけで起動出来るUbuntuのバージョンがある事が判りました。

このUbuntuの起動DVDを作ると、セットアップ途中で「インストールする」「試用する」の選択ができます。「試用する」の選択では専用のインストールドライブを作らずLinux環境が使え、文字通り試す価値ありと判断しました。

ネットに多くの情報があり、Win10上でUbuntu起動DVDの作成は簡単でした。 その手順については以下を参考にしてください。

　　UbuntuLinux 日本チームのページ。

そして、PCのBIOS設定でDVDドライブを第一起動ドライブに変更、DVDを入れPCを起動。 読み込みに時間が必要ですが、起動途中で「試用する」を選択し、少し経つとダークレッドのUbuntuのデスクトップが表示されました。

最初は何をどうすれば？の状態ですが、有難い事に左手のタスクバーにFirefoxアイコンが有ります。 漢字が表示され入力も可能で、判らない事はネットで調べながら先へ進めます。 何度かこのUbuntuを使い、簡単な扱いを覚えました。

DDing:0 1em;”>Linuxは問題のHDDを認識するか

もはやWin10のシステムは不要で、PCから従来のメインHDDを外しました。 その代わり問題のデータ用HDDのみを内蔵接続で繋ぎ、DVDからUbuntuを起動。 このディスクでBIOSチェックに時間がかかりますが、後はWin10ほどの遅延がなくUbuntuが起動出来ました。

Ubuntuでディスクの状況を調べるには、一番左上のアイコンの検索から「gp」を検索し、アプリの「GParted」を起動します。 このアプリは2018年のUbuntuバージョンに標準装備されています。

GPartedは起動時にPC内蔵のHDDをチェックするので、問題のディスク情報が表示される(GPartedが操作可能になるまで）には10分程度の時間が必要でした。

しかし、Win10では全く認識出来なかったパーテションの状況も、問題がある事を示すマークが付いているが、容量まで表示されます。 やっと糸口を掴んだわけです。

ディスク情報を見るだけなら良いですが、GPertedはパーテション作成等を扱えるアプリで、間違って指示を出すと更なるデータ破壊に繋がり、注意が要ります。 また、Linux独特の「マウント指定の操作も注意」とネット上に書かれています。

DDing:0 1em;”>ディスクのクローン作成

ここから、色々と修復作業が可能な事は間違いありません。 たとえ、全くデータが取り出せなくても、諦めが付きます。 

修復の原則は「対象ディスクに不可侵」を貫く事です。 これの一線を超えると、データをより失い、業者委託しても超えた分は修復可能性が減ります。 そこで、HDDのクローン作成を最初に行う事にしました。 クローン作成は記録データ�
��物理的コピーですが、クローンが出来れば、それに修復を試みるわけです。

（但し、これは論理的障害だという確信に基づく選択です。 もし物理的障害があれば、クローン作成作業も対象ディスクをより修復困難にするでしょう。 その場合の高度な判断やアクセス技術は、もはや一般ユーザーの手の届かないものです）

クローン用に同容量（1TB）のHDDを入手しました。 今度は、問題のHDDと未フォーマットの新しいHDDをPCに内部接続し、再びDVDでUbuntuを起動、そしてGPertedで2個のHDDを確認しました。（GPertedの右上の枠にリストされます）

これ以降の指示を出すためには、Ubuntuに対してroot権限（Win10の管理者の権限）が必要になります。

❶「端末：コマンド入力窓」の表示

これは「 Ctrl＋Alt＋T 」のショートカットキーを打つのが早い。

❷ 端末で「su」とコマンドします。

su

➌ root権限者のパスワードの指定を要請されるので、簡単なパスワードを指定します。 これで端末のカーソルの手前に「#」が付けばroot権限の指示として扱われます。

この操作は一般のUbuntu環境ではセキュリティ上推奨されませんが、DVD起動の「試用」では、毎回内容は霧散し問題ないでしょう。（念のため、LANケーブルを外しておくと確実）

❹ 端末で「DD」のコマンドを入力し実行します。

これはクローン作製のコマンドですが、少し複雑なコマンドを正しく入力する必要があります。 どこかに清書して、スペースを含めて確実に入力しないと、とりかえしがつきません。（コピぺ入力は出来ませんでした）

DDコマンドは、マシンのHDD構成によって「sda」「sdb」「sdc」等の部分が変わります。 誤るとコピーしたいディスクを消してしまう事になりますから、下準備とパラメーター確認を何度も行い「Enter」を押します。

DDコマンドに関しては多くのページに説明がありますが、私は、以下を参考にしました。

　　archlinux.

実際に端末に指定したのは、以下のコードです。

DD if=/dev/sdX of=/dev/sdY bs=512 conv=noerror,sync status=progress

◎Xはコピー元 、Yはコピー先 のドライブのアルファベット。

◎大変な時間が必要で、早くて数時間、長ければ日をまたぐ数十時間の覚悟が必要です。サブPCが無いと困ります。 

◎status=progress は必須。 この指定がないとコピーの進行が確認できません。

◎LANケーブルは抜いておくとベター。

DDing:0 1em;”>現在クローンの制作中

512バイトずつのコピーは、PCのランニングテストの様です。 PCと電源事情に問題が生じない事を祈るのみ。 下は、途中の画面を写真に撮ったものです。

これは開始から約12時間後の様子で、5MB/sの速度で進行中、256GBがコピー終了した事を表示している様です。 速度は、読み込みエラーの多発部分では遅くなる様です。 1TBのディスク容量ですから、ざっと4倍として48時間が必要と予測されます。

今後、再コピーが必要なら、Ubuntu専用のHDDインストール環境を考えるかも知れません。 それで速度が稼げるかは疑問ですが。

また、クローン後にどういった修復が可能か、全くできないのか、これは先の話です。 とりあえず、Linux環境はWindowsよりも修復可能性がある事だけは、間違いない様です。

DDing:0 1em;”>追記に代えて 一応の報告を 2018.04

クローンは約2日でほぼ予定の通り完了しました。 正常なWin10環境に作成したクローンディスクを繋ぎ起動、全く正常にOSが起動します。 クローンディスクの内容を調べると、パーテションは有るがファイル・ディレクトリは全く失われ、焼野原の状態でした。 

ただ、Win10でパーテションが認識できるのは、最初と全く違います。 早速、データ復旧アプリを起動し、クローンディスクからファイルの掘り起こしを試しました。 使用したWin10のアプリは「EaseUS Data Recovery Wizard」という復旧アプリの試用版ですが、機能上でどのメーカーのアプリとて大差は無い様です。

取り戻したいのは写真画像データで、「画像」の属性指定で復旧を試みました。 上図は「クイックスキャン」では全く駄目で「ディープスキャン」に移り、およそ半時間経った状態です。 掘り起こしはこの後も延々続きますが（アプリは後2時間要の表示）、検出されたファイルはこの段階で6割ほどです。

全ての作業が終了した結果は、約18000ファイル、100GB弱の画像ファイルが復旧可能として検出されました。 作業はここからファイルの復旧先を指定して復旧を実行する必要がありますが（Free版では復旧容量制限があります）、検出リストから復旧可能なファイルが必要な画像かどうかを確認できます。 破損前のディスクには、パーテション容量「736.20GB」の半分位のデータが有った様に記憶しますが、この回収確率（1/3程度？）を良いと言って良いのか悪いのか？

〔参考〕

DDd;paDDing:0 1em;”>私の場合はとても残念な結果

私の場合は実に残念な結果です。 というのは、検出出来たのは大昔の撮影画像ばかりで、2年前の別のバックアップの中に、殆どが含まれていたのです。 そして、肝心の最近の撮影画像はことごとく在りません。 結局、大変な苦労をし
て数コマの最近のファイルが見つかっただけです。

ちなみにこのアプリでは、フォルダー（ディレクトリ）構造が上手く復活出来ませんでした。 その機能がある様ですが、フォルダー階層が整理の意味をなしません。 これは、元データの破壊状態にもよるのでしょうか。 画像ファイルにExif情報があれば、その撮影日付データを頼りに、復旧ファイルを整理しなおす必要があります。 探せば、これを助けてくれるアプリはあるでしょう。

ところで、私の結果が芳しくなかったのは、クローンのやり方の問題ではないと考えています。 おそらく最近のデータはパーテション後方に記録されていて、発掘が可能だったのはパーテションの前方ばかりの様なのです。 こういう運、不運は、必ず生じる事で、逆に「苦労して良かった、万々歳」という場合もあると思います。

DDd;paDDing:0 1em;”>暫く休憩 ^^;

結局、私はここで脱力したのですが、実は未だ選択肢が残されています。

　◎Linux環境で、Linux系のリカバリアプリをクローンディスクに試す。

　◎同様に、Linux系のリカバリアプリを破損した原本ディスクに試す。

後者はかなり危険が伴いますが、前者は試す価値があると思います。 その結果に光明があれば、後者も試して良いはず。 今度元気が出たら、これを試すつもりでいます。

以上、この記事を見に来てくれる方が多いので、現在までの結果報告を纏めました。 参考になれば幸いです。