GPTテーブルの回復

Question

私は自分のものを読んだり壊したりすることができないユーザーの仲間入りをしました。

先週の日曜日、大きなWindows 7 NTFSパーティションを小さなパーティションにコピーしようとしたときに、3TBHDDのパーティションテーブルと思われるものを吹き飛ばしました。コンテキストの場合：

sdb (3TB drive/partition) sdh2 (1.57 TB partition)(2TB drive)

私はPartedMagic2018を実行していました（そして今もそうです）。次のように入力しました。

sgdisk -R /dev/sdb /dev/sdh2

Gpartedを開いたときに、コマンドを間違って入力したことに気づきました。これは、大きなパーティションを小さなパーティションに移動することに関連する問題を修正するための回答として、SEの質問に記載されていました。 answer は次のように入力されました：

sgdisk -R /dev/sdY /dev/sdX where: sdX = Disk A sdY = Disk B

ボーンヘッドは脇に移動し、私は現在ダメージコントロール中です。私はこれに従い始めました buntuフォーラムガイドそして現在、ドライブ全体を回復できるように、パーティションヘッダーのドライブのスキャンを開始しました。

これまでに次のコマンドを入力しました：gpart /dev/sdb。ドライブを約4日20時間スキャンしています。

ここでの手順に関していくつか質問があります。

これにはどのくらい時間がかかりますか？私の最善の見積もりは、HDDアクティビティライトを見て、1秒あたり最大1回の点滅を数えることでした。 1回の点滅は1つのセクターの読み取りであり、各セクターは4096（フラッシュドライブ上にある）であると想定しました。毎秒4MBの読み取り時間で3TBドライブに2,720,000MBを使用すると、約7。87日かかります。最短時間はその2倍の速度になり、今では完了しています。最後の「可能なパーティション」出力は2日前で、1421742mbのオフセットを提供しましたが、最初の可能な出力はオフセット1mbでした。私はどこかでセクターサイズがもっと小さいかもしれないのを見ました。私は近いですか？
ドライブを救助するための適切な措置を講じていますか？ Ubuntuフォーラムガイドは健全で非常に関連性があるようです。ドライブにあるパーティションは1つだけで、以前はもっとありましたが、それをワイプして1つだけでやり直しました。それは事故の前にリストされた唯一のパーティションであり、私が覚えているようにドライブ全体を使用していました。それらのいくつかのMB未使用セクションの1つがあったかどうかはわかりません（パーティションを作成するときにGPartedで時々行われるこの奇妙な空白のパーティション化されていないスポットは、1mib未使用で始まります）。
partedを使用してパーティションを復元し、すべてのセクターを追加しない場合、または追加しすぎる場合、データは引き続きそのパーティションに表示されますか？ガイドには、セクターの単位を使用してパーティションテーブルを再構築するように書かれています。使用するユニットが少なすぎたり多すぎたりしても、ドライブをマウントして読み取ったときにデータが表示されますか？
プライマリパーティションテーブルとセカンダリパーティションテーブルなどがあることを読みましたが、それらは存在しますか？コピーできますか？どのように表示して、どちらをリカバリするかを確認できますか？

専門サービスに送る以外に、2つ目の損傷制御オプションが必要です。これはビジネスコンピュータではありませんが、回復すべき重要なことがいくつかあります。

最終目標：3TBドライブの単一パーティションを回復します。

更新：gpartスキャン後

参考写真に見られるように、スキャンはドライブの終わり近くで失敗しました。それ以来、ドライブをTestDiskを実行した新しいコンピューターに配置しました。クイックスキャンでは、gpartが見たものの一部が見つかりましたが、私が知っているものは見つかりませんでした。 Big Mongoという名前の問題のパーティションを数分以内に検出するDeeperScanオプションを使用しました。これは私がWindowsでドライブに名前を付けたものです。

更新2：テストディスクスキャン後

TestDiskが完了し（追加の参照写真を参照）、不足しているパーティションを特定しました。プログラム内のファイルを一覧表示させることができます。完了したスキャンの下部にあるサイズに注意してください。スキャンは、gpartから8日に対して10時間で完了しました。

結論：心を問うために

TestDiskを実行した後、パーティションが見つかりましたが、テーブルが正しく作成されなかったため、gdiskを実行し、開始として2048を使用し、終了として最大サイズを使用して再構築しました（マークされた回答を参照）。休止状態で、問題なく起動しました。

参考写真
gdisk -l for comment https://i.stack.imgur.com/9znYj.jpg
gpart scan 1/2 https://i.stack.imgur.com/rWxuC.jpg
gpart scan 2/2 https://i.stack.imgur.com/HQYJ8.jpg

TestDiskクイックスキャン

TestDiskディープスキャン予備

TestDiskの完了

Kamil Maciorowski · Accepted Answer

分析

使用したコマンド

_sgdisk -R /dev/sdb /dev/sdh2 _

GUIDパーティションテーブル（GPT）を_/dev/sdh2_から_/dev/sdb_にコピーしました。

1つの問題は、_/dev/sdh2_がパーティションであるということです。どのパーティションにも意味のあるパーティションテーブルはありません。または少なくともそれすべきではない持っている。パーティション内に意味のあるパーティションテーブルを想像することはできますが（そしてそれをちょっと機能させることさえできます）、これは面倒でエキゾチックで、あまり役に立ちません。

結果のコピーは空のGPTです。これは、_/dev/sdh2_内の関連する（まだ意味のない）値がそのようなテーブルになっているためです。これは実際には問題ではありません。

重要なのは、_/dev/sdb_の元のGPTを上書きしたことです。使用したコマンドはパーティションテーブルのみを変更しました。他のすべての構造はまだ存在していると予想されます。ファイルシステム自体は問題ないはずです（後で回復しようとしたときに、ファイルシステムが破損するほど不幸な場合を除きます）。ファイルシステムにアクセスするための便利な方法を失っただけです。私のこの答えを読んでください、その最初の部分はパーティションとファイルシステムの違いを要約しています。

ここでの目標は、元のGPTを何らかの方法で復元することです。あなたの状況は、あなたが言及された答えで説明された手順の真っ只中にいるかのようであることに注意してください：あなたはパーティションテーブルエントリを破壊しましたが、まだ新しいものを作成していません。違いは、必ずしも大きなパーティションを作成する必要はなく、パーティションを開始するオフセット（開始セクター）がわからないことです。

GPTは、プライマリテーブルとセカンダリ（バックアップ）テーブルで構成されます。 _sgdisk -R_は、GPT全体を一貫した状態のままにするために両方のテーブルを変更したため、セカンダリテーブルは古い状態の復元に役立ちません。

オフセットを見つける

ディスクをスキャンし、ファイルシステムの署名を見つけ、署名からファイルシステムのサイズを読み取り、ファイルシステムを新しく定義されたパーティションに適切に埋め込むパーティションテーブルエントリを提案できるツールがあります。これにより、簡単にマウントできます。そのようなツールの1つはtestdiskです。古いパーティションテーブルのみが消去された場合、testdiskはファイルシステムを見つけて、正常なGPTを作成できるはずです。スキャンには時間がかかる場合があります。

または、正しいオフセットを推測してみてください。パーティションが1つしかないという事実は利点です。

これは私の別の答えですを読んでください。あなたの場合（論理セクターサイズ_512_）、最も可能性の高い開始セクターは_2048_であり、機能する可能性のあるコマンドは次のとおりです。

_mount -o ro,offset=$((512*2048)) /dev/sdb /some/mountpoint/ _

読み取り専用をマウントしても、これまでに残ったデータには影響しないため、安全に試すことができます。コマンドが成功し、ファイルとディレクトリが_/some/mountpoint/_の下に表示されていることを確認した場合は、オフセットが正しいことを意味します。

_512*2048_は正確に1MiBであることに注意してください。あなたが持っているスクリーンショットの1つ：

_Possible partition … offset(1mb) _

これだと思います。このツールを使用した場合、testdiskによっても検出される可能性があります。

パーティションテーブルエントリを手動で作成する

testdisk（または同様のもの）を使用しないことを選択し、正しいと思われるオフセットを見つけた場合は、手動で（gdisk、sgdiskを使用して）正常なエントリを持つパーティションテーブルを作成できます。またはこれを行うことができる任意のツール）。次のヒントに従ってください。

ファイルシステムがマウントされている場合（例：前の段落の_mount -o ro,offset=… …_）、umount。
GPTのままにします。論理セクターサイズが正しい場合、それは非常にありそうもない元々MBRにDOSパーティションテーブルがありました。たとえあったとしても、セクター_2048_で始まるパーティションがディスクの終わりに到達することは不可能です。したがって、元々何もなかったとしても、ディスクの最後にセカンダリGPTを作成しても安全です（とにかく_sgdisk -R_がすでに書き込みを行っていることを除けば、悪化させることはできません）。ただし、念のため、この回答の後半にある「考えられる問題」のセクションを参照してください。
これは見つけたオフセットであるため、開始セクターは_2048_である必要があります。
サイズは、ファイルシステムのサイズ以上である必要があります。今のところ、あなたが持っている唯一のヒントはsize(764432mb)です。ここで、mbが MBまたはMiB を意味するのか、それとも完全に間違っているのかはわかりません。最も安全なアプローチは、（一時的に）終了セクターに可能な最大値を使用することです。別のスクリーンショットでは、終了セクターの最大値は_5860533134_であると思います。
[パーティションタイプGUID]は NTFSの場合は正しい：_EBD0A0A2-B9E5-4433-87C0-68B6B72699C7_である必要があります。 gdiskでは、これに_0700_のショートコードを使用できることに注意してください。
ツールはファイルシステムに触れてはいけません。パーティションテーブルにのみ影響します。「新しい」パーティションをフォーマット（mkfs）するか、ワイプ（wipefs）しようとする場合、それは適切なツールではありません。 gdiskは安全だと思います。 GUIオールインワンパーティショニングツール（Windowsネイティブツールを含む）には細心の注意を払っています。率直に言って、この場合「非常に注意深い」とは、私がそれらをまったく使用しないことを意味します。

適切なエントリを作成し、新しいパーティションテーブルをデバイスに書き込むと、_/dev/sdb1_が表示されます。表示されない場合は、partprobeを呼び出します。

_/dev/sdb1_をマウントできることを確認します。

サイズ調整

これで、使用可能な_/dev/sdb1_がある場合、ファイルシステムにそのサイズを簡単に照会できます。私はファイルシステムがそのサイズを知っていることを意味します。一般に、これは対応するパーティションのサイズとは異なります。使用できるツールは少なくとも2つあります。

```
_file -s /dev/sdb1 _
```
_sectors NNNNNN_と書かれている場所に興味があります。 _hidden sectors_について心配する必要はありません（比較 FATについても同様の疑い）。
```
_ntfsresize --info /dev/sdb1 _
```
「現在のボリュームサイズ」に関心があります。 512バイトのセクターで表現します（つまり、512で割ります）。

ntfsresizeの出力から計算された数値は、fileの数値と少し異なる場合があります。これはクラスターサイズと関係があると思います。私のテストでは、_mkfs.ntfs_がパーティション全体を使用するように求められた後、fileはパーティション内のセクター数よりも1セクター少ないと報告しているようです。したがって、fileではなくntfsresizeを使用し、_sectors NNNNNN_を識別して、1つ追加します。これは、パーティションの大きさが必要な大きさです。疑問がある場合は、_2048_セクターを追加してください。それはやり過ぎですが、無駄なスペースは1 MiBだけで、それほど多くはありません。それはあなたを確実に安全に保つでしょう。

パーティション（前の段落で作成）が大きい場合は、縮小することをお勧めします。最終的な目標は、ファイルシステムをより小さなディスクにコピーすることでした。スクリーンショットの1つにこのPossible partition … size(764432mb) …があります。これにより、ファイルシステムは実際に新しいパーティションよりも小さいと思います。これ自体は問題ではありませんが、ファイルシステムの終了後に別のパーティションを作成する場合、またはセットアップをより小さなディスクにコピーする場合は、パーティションを縮小することをお勧めします。

手順：

umountマウントされている場合はファイルシステム。
パーティションテーブルからエントリを削除します。
前の段落のように新しいエントリを作成しますが、今回は計算したばかりのセクターの数を指定します。エンドセクターではなく、新しいパーティションのサイズについて話していることに注意してください。エンドセクターを知る必要がある場合は、次の式を使用します：_start+size-1=end_。パーティションの端の配置は重要ではありませんが（最初は重要です）、ツールが端をディスクの端に向かってわずかに移動するように要求する場合は、それを許可します。
パーティションテーブルを保存し、念のためpartprobeを実行します。
_/dev/sdb1_がエラーなしでマウントされることを確認します。念のため、最初は読み取り専用（_mount -o ro …_）をマウントします。

ファイルシステムが正常にマウントされれば、基本的には完了です。これで、パーティションテーブルは正常になりました。

考えられる問題

新しいパーティションには、新しい一意のパーティションGUIDがあります。一方、ファイルシステムに格納されている「UUID」は残ります。前者に依存するツール/ OSを再構成する必要がある場合があります（または、いくつかの構成から古い値を取得して新しいパーティションに適用すると、この1回の移動でそのようなすべての構成が再び有効になります）。 Windowsが以前にパーティション/ファイルシステムを見たことがあるかどうかを判断するために使用するIDがわかりません。
ディスクレポートの論理/物理セクターサイズが_512/4096_であることがわかります。この質問とそれに対する私の答えの説明を読んでください。少なくとも1つのUSBエンクロージャーが関係していて、ディスクが現在とは異なる方法で接続されていた場合（つまり、別のエンクロージャー内、またはSATA経由で、以前のエンクロージャー内、またはその逆）、_/dev/sdb1_は_sgdisk -R_を呼び出す前にマウントし、その後多分元の（失われた）パーティションテーブルは論理サイズ_4096_に対して有効でした。事故の前にパーティションをマウントしようとすると、リンクされた質問と同じ問題が発生します。私のポイントは、私の答えは、currentセットアップに有効なパーティションテーブルを作成するのに役立つということです。この問題が発生する場合は、元の設定でドライブを接続したときに発生します。次に、パーティションテーブルを再度調整する必要があります。リンクされた質問に対する私の答えが役に立ちます。
上記の箇条書きが当てはまり、size(764432mb)が間違っている場合は、ディスクの最後まで広がる1つの大きなパーティションを定義したMBR（GPTではない）のDOSパーティションテーブルがあった（および上書きされた）可能性があります。ファイルシステム自体は、（ほぼ）ディスクの最後まで広がっていました。このような場合、_sgdisk -R_は、ファイルシステムの一部があるべき場所の最後にセカンダリ（バックアップ）GPTを作成しました。ファイルシステムが正常にマウントされる場合、これはおそらく当てはまりません。一般的にはそうかもしれません。これは、実際にデータが失われた可能性があるシナリオです。修正しない限り、さらに失う可能性があります（必要に応じて別の質問をしてください）。

GPTを使用していることが確実な場合は、安全であることに注意してください（セカンダリテーブルが「常に」存在していたため）。そして、前の箇条書きが当てはまらないことが確実な場合は、安全です（論理セクターサイズが_512_で、MBRのDOSパーティションテーブルでは、セクター_2048_で始まるパーティションがあるためです。大きなディスクの最後まで拡張できませんでした）。

パーティションテーブルを修正した後は、おそらく元の計画を続行する必要があります。次に：

他のディスクの論理セクターサイズが異なる場合があります。（適切に使用された）_sgdisk -R_が異なるサイズのエントリを再計算するかどうかはわかりません。私はそれを期待しています。そうでない場合は、あなたは何をすべきか知っています。
しかしたぶん _/dev/sdb_（つまり、_/dev/sdb1_など）の唯一のパーティションを_/dev/sdh2_に複製したかった。保持したい_/dev/sdh1_があります。もしそうなら、_sgdisk -R_はnotあなたがやりたいことです。パーティションテーブルを_/dev/sdb_から_/dev/sdh2_（パーティション）にコピーしても、何も得られません。それを_/dev/sdh_にコピーすると、そこにある現在のパーティションテーブルが置き換えられ、現在の_/dev/sdh2_（および存在する場合は_/dev/sdh1_）が混乱します。 _sgdisk -R_は、ターゲットディスクに保持するデータが含まれていない場合にのみ使用してください。疑問がある場合は、_/dev/sdb_のパーティションテーブルを修正した後、別の質問をしてください。新しい質問には、両方のディスクの_gdisk -l_（または_fdisk -l_）の出力が含まれている必要があり、クローンを作成するパーティション、消費可能なパーティション、およびどのパーティションを明確に指定する必要があります。パーティションはそのままにしておく必要があります。