使い方Alexaにはまりました。近いうちに記事を書きますね。昔からunix系にあるddコマンドはディスクコピーに重宝する強力なツールです。取り出した内蔵ハードディスクのデータをddコマンドを使って、コピーする方法についてまとめました。ddコマンドで落としたディスクイメージファイルをマウントする方法についても説明します。はじめに前回までの記事でdynabook内蔵の1TBのハードディスクを取り出しまでについて書きました。今回は、このハードディスクの中に入っているデータのコピーについて説明します。外付けディスクケース内蔵ハードディスクのままでは扱えませんので、外付けのディスクケースに入れて使用します。今回、用いた外付けのディスクケースは、玄人志向とCenturyの製品です。Centuryの製品は8年ぐらい前に購入した古いもの。最近は、玄人志向の製品を使うことが多いです。GW2.5OR-U3玄人志向2017年発売のUASP対応のディスクケース。HDTV等対応ELUTENG玄人志向ではないが、UASP対応のスケルトンケース。タイムセールで思わず衝動買いしてしまった。-->今回は、別のLinuxパソコンを使って、内蔵ハードディスクをディスクケースに入れて、外付けディスクとして取り扱いました。CD/USBなどを作って、元々のパソコンをLinuxマシンとして起動できれば、内蔵HDDを取り出さずに、外部デバイスにコピーできます。USBを作ってLinux上で作業した方が良かったかもしれません(が、わざわざマシンが壊れたときに作るのは面倒。余裕のあるときに予め作っておくのがよいのでしょうね)。Technology)の情報を調べました(SMARTの各項目の意味は、ウィキペディア参照)。画像は、gnome-disksの画面です。64個の不良セクターがあり、HDD障害が発生していることが分かります。まともに動作しないのも納得。gnome-disksあるいは、「アクセサリ」→「ディスク」から起動(lubuntuの場合)不良セクターが64個あります。使用可能となっていますが、不良セクターが64個もあれば、ディスクは即交換です。SMARTのセルフテストの結果。16セクタが代替処理ができずにいる。ディスクのコピーディスクのコピーにはいろいろやり方はありますので、いくつか紹介します。実際に行ったのは、4.1.1節で説明する丸ごとディスク内容を抜き出して、ファイルに落とす方法です。ディスク内容を丸ごとファイルに落とすddコマンドを使って、ディスクの内容をそのままファイルに落とします。全部をファイルに落とすので、その後は、壊れかけのディスクにアクセスせずに取り扱えるようになります。出力したファイルは、ハードディスクにディスク内容を書き戻し(4.1.3節)やファイルをディスクと見立てたマウント(4.2.2節)のために利用します。bs=1M出力ファイルは、容量1TBになります。file)には、1TB以上の空きが必要です。今回は、2TBハードディスクをバックアップ用に用意しました。bsオプション(ブロックサイズ)は、1M~16Mぐらいを指定すればよいと思います。以下では、bsオプションの記載は省略します。of=/dev/sdb出力先のディスク(ここでは、/dev/sdb)は、1TB以上の容量が必要です。丸ごとコピーするので、コピーしたディスクをそのままもとの筐体に戻せば、復旧するはずです(もしかしたら、BIOSや起動フラグなどの設定が必要かもしれません)。1TB以上の場合には、その後、パーティションを作成、あるいは、拡張することで、余った部分を有効利用できます。MQ02ABD100Hでしたので、SSDへ換装しないなら、同じハードディスクを使う方が安心です。並行輸入ToshibaDynabook内蔵のSSHD。丸ごとディスクコピーができます。ファイルからディスクへ丸ごとコピーする4.1.1節で説明したようにddコマンドでファイルに落としたディスク内容は、ddコマンドを使って、ハードディスクに書き出すことができます。of=/dev/sdbここでは、/dev/sdbが出力先のデバイスです。要するに、ddコマンドは、ファイルも、デバイスも同じように扱うことができるのです。パーティション単位でコピーするddを使えば、パーティション単位のコピーもできます。今回のディスクのパーティションは5つありますので、次のようにすれば、全てのパーティションをコピーできます。of=disk-part-5.imgこの場合、パーティションテーブルは保存されませんので、別途、gdiskを使って保存します。ディスク内容を個別にコピーするディスクをマウントして、それぞれのファイルを見られるようにすれば、必要なファイルを選択的にコピーすることができます。/mnt/tmpマウントポイント(/mnt/tmp)を作成し、そこへWindowsのユーザーが通常アクセスする3番目のパーティション(この例では、/dev/sdc3)をマウントします。その後は、通常のファイル・ディレクトリと同様に、cpコマンドやrsyncコマンドなどを用いて内容をコピーします(個人的にはrsyncの方が好みです)。ファイルをマウントするファイルシステムのマウントはディスクのみならず、4.1.1でディスク内容を丸ごと落としたファイルでも可能です。このファイルをマウントすることで、前節と同様にファイルをコピーできます*1。/dev/loop0しかし、この方法でのファイルの抜き出しで、少々、トラブルがありましたので、付録Aで説明します。まとめ昔からunix系にあるddコマンドを使って、ハードディスクのデータをコピーする方法についてまとめました。ddコマンドで落としたディスクイメージファイルをマウントする方法についても説明しまた。次の記事では、ダンプしたディスク内容のSSDへの書き戻しについて説明します。付録A:ディスクイメージがマウントできないddでコピーしたディスクイメージのloopデバイスを使ったマウントについて4.3.2節で説明しました。マウントできないというトラブルがありました。ここでは、そのトラブルと対処方法について説明します。partprobeでパーティションが認識できない4.3.2節では、ディスクイメージとloopデバイスをlosetupで関連付けた後、partprobeでディスクイメージのパーティションを認識させます。このときに、次のエラーが発生しました。partedでloopデバイスを調べるpartedでパーティションを調べると、partprobeと同じメッセージがでてきましたが、無視して調べると、GPTテーブルが壊れていると出てきます。それでも、一応は、パーティションを見ることができました。テーブルは壊れていますが、プライマリは問題ないようなので、そちらを使います。gdiskを使って修復gdiskを使って、loop0を見ようとすると、今度はディスクを修復するようにとのメッセージがでます。修復することにしましたが、ディスクイメージを破壊する可能性があるので、オリジナルのディスクイメージではなく、そのコピーに対して修復を行いました(バックアップ用の2TBでは、容量が足りないので、さらに2TBのディスクを用意しました)。パーティションテーブルの問題点や修復作業についてはわけがわからないまま、コマンドの指示に従って作業を進めました(笑)。長いですが、全部、引用しておきます。バックアップGPTヘッダ(第2GPTヘッダ)が壊れているので、修復するように言われました。recommended.****************************************************************************それでも、パーティション情報を出力すると、一見正しそうな情報を出力しました。disk)を実行すると、3つの問題点を指摘されました。problems!パーティションテーブルのレイアウトが分からないと、何をいっているか、チンプンカンプンです。ウィキペディアによれば、パーティションテーブルは、以下の図のように配置されています。パーティションテーブルのレイアウト。(wikipediaより引用)各LBAは512バイト、各エントリは128バイト。small)は、ディスクサイズが1セクタ足りないとの指摘です。ディスクの最後の1セクタ(512バイト)がディスクイメージのファイルに保存されていないことが原因と考えられます。ダンプされたディスクイメージのファイルサイズは、1,000,204,885,504バイト(=1,953,525,167セクタ×512バイト)です。パーティションテーブルには、それよりも1つ多い1,953,525,168セクタあると、書いてあるのではないかと思います。第2ヘッダーの位置は、ディスクの最後と決まっているので、最後の1セクタがダンプされていないと、第2ヘッダーに書かれている位置と、ディスクイメージの最後から数えたヘッダの位置に不整合が発生します。これが第1の問題である第2ヘッダの自己ポインタが変だという検査結果となり、第2GPTヘッダは、壊れていると判断されます。第2GPTヘッダは壊れていますので、パーティション構成の解釈は、MBRによってなされます。MBRに記録されているセクタ数がダンプしたファイルのセクタ数よりも大きくなっているので、第3の問題点(MBRのパーティションが大きすぎる)を指摘されます。menuに入って、eオプションを実行。disk」という処理です。意味をよく理解していませんが、第2GPTヘッダをディスクの最後に配置しなおす(前にずらす)ということだと思います。"1,953,525,134"から1,953,525,133に一つ減りました。disk)を行うと、問題点は1つなりました。table)を使ってパーティションテーブルサイズを4つ減らせとのこと。第2ヘッダを1セクタ前にずらしていますので、パーティション5の最後の1セクタと第2GPTエントリーの1セクタが重複します。この重複を解消するために、1セクタ(512バイト)の大きさ分の4エントリ(4エントリ×128バイト=512バイト)を減らす必要があるということかと思います。sizeを128から124に減らすと、今度はエントリーが少なすぎると警告される。sizeを124,128,132と変更してみた。sizeを124にすれば、エントリーが足らないと注意され、128以上にすると、第2パーティションテーブルが、最終パーティションとオーバーラップすると注意されます。使えるセクターが一つ減った影響で、パーティションテーブルがオーバーラップするか、パーティションテーブルを小さくするかの選択を迫っているということのようです。最終的には、パーティションテーブルサイズを124としました。エントリー数が減る影響をよく理解していませんが、大量にパーティションを切らない限り影響はないのではないかと思っています。it.expertメニューからメインメニューに戻り、再度、検証(v)し、パーティションテーブルの修正結果の書込み(w)を行いました。最終的に次のようなパーティションテーブルとなりました。GPTパーティションテーブルも"present"と正常になりました。partition修復前から変化した点は、次の通りです。第2ヘッダのサイズが小さくなった影響を受けて、第1ヘッダのサイズも小さくなり、利用できるセクターが1セクタ増えたということのようです。/dev/loop0も正常動作するようになり、パーティションを正しく認識するようになりました。パーティションテーブルのダンプと修正gdiskの修復メッセージから類推すると、以下の図に示すような現象が起こっていたと思われます。ddによるダンプによって、1セクタのコピー漏れが発生し、第2GPTヘッダが消失します。その第2GPTヘッダを新規作成するために、エントリー配列の大きさを128から124に減らし、1セクタ分小さくします。これに伴って、第1GPTエントリ配列も124エントリとなり、第1エントリ配列の直後の1セクタが新規に空き領域となります。dynabookの壊れかけている内蔵ディスク/dev/sdcを直接gdiskコマンドで、調べたところ、ddでダンプしたディスクイメージと全く同じように第2GPTヘッダが壊れていました。ddが書き漏らしたのではなく、最初からディスク末尾の1セクタ(512バイト)が欠けていたのかもしれません。Windowsでは、パーティションテーブルを正しく書いていない、という可能性もありますが、よく分かりません。(追記:2018/9/21)この現象は、外付けハードディスクによって、読み取ることができるセクター数が異なることが原因と判明しました。本稿でハードディスクのddダンプで用いたのは、Centuryの製品です。作業用に用いていたのは、玄人志向の製品です。読み取ることはできず、欠損が生じます。実際、1TBのハードディスクの末尾の1セクタをELUTENGのディスクケースを使って読み込んで、Centuryのディスクケースでddダンプしたファイルの末尾に追加すると、gdiskは正常にGPTテーブルを解釈します。CSS25U2BKセンチュリーUSB2.0接続の古い製品です。GW2.5CR-U3玄人志向2014年発売でUSB3.0対応。HDTV等対応ELUTENG先月購入したスケルトンケース。アクセスランプが綺麗。したら、ディスクイメージの末尾に512バイト追加すればよかったのかも...パーティションの修復が必要なのは、ディスクイメージが1セクタ分欠けていることが原因と考えられます。gdiskを使った修復では、パーティションテーブルのサイズを128エントリから124エントリに減らしましたが、それだと、GPTヘッダの仕様で要求される128エントリを確保できません。あれば、次のような方法で、ディスクイメージに512バイト追加すれば、128エントリーを確保できるのではないかと思います。ddでダンプする際に必要なセクタ数を明示的に指定してコピーする。count=1953525168もしかしたら、オリジナルのディスクの第2ヘッダの情報が正しくコピーされるかもしれません。あれば、partprobeも問題なく通過するでしょう。disk.imgdynabookに入っていた壊れかけたハードディスクの全データをダンプするのは大変です。この方法では、最後の1セクタだけを読み出して、既にダンプしたファイルに追加します。skip=1953525166まではスキップできましたが、1つ増やして1953525167とすると、エラーとなりました。1953525168番目のセクタは読みだせないようです。disk.imgこの方法では、第2GPTヘッダを修復する必要はあります。実際に試したところ、128エントリーを保ったままパーティションテーブルを修復することができました(付録B参照)。付録B:ファイルに1セクタ追加して、GPTヘッダを修復ddコマンドでダンプしたディスクイメージは、1セクタ(512バイト)欠けているようでした。使って、パーティションテーブルを修復しました。これによって、エントリー数を削減することなく、仕様通りのGPTヘッダを作ることができます。エラーメッセージがでますが、マウントできて、ディスク内のファイルも参照できます。テーブルは壊れていますが、プライマリは問題ないようなので、そちらを使います。GoogleDrive/(略)バックアップGPTテーブルは、壊れていると言われますが、マウントできました(read-onlyとなるのは、Windowsでのシャットダウンで完全シャットダウンを行っていないため)。ファイルも見ることができます。パーティションテーブルの修復gdiskを使って第2GPTヘッダを修復しました。第1GPTヘッダを使って修復するコマンドが分からなかったので、一旦、パーティションテーブルを124エントリに縮小し、128エントリに戻すことで、第2GPTヘッダを作っています。試してみましたが、期待した通りの結果は得られませんでした。コマンドとしては、次の順序で行っています。作業にあたっての注意点としては、次の点が挙げられます。パーティションテーブルのバックアップを取ることパーティションテーブルを破壊してしまったときに役立つはずです。パーティション内容をよく確認すること特に、編集したパーティションテーブルをディスクに書き込む前には、v(検証)だけでなく、p(プリント)も出力して内容をよく確認します。両方ともに、さぼったので、実際に、操作を間違えて、パーティションテーブルを破壊し、ディスクイメージを使いものにならなくしてしまいました!(オリジナルコピーからやり直し)なお、実際のログは、以下に示す通りです。楽天ROOMにガジェットをまとめてます。グレイテスト・ショーマン心温まるミュージカル。