USBケース付きddrescue

ログファイル（マッピングされたファイル）はどこに書き込まれますか？ [...] 新しいターゲットディスクにも書き込めますか？

ターゲットディスクにファイルシステムを作成してマウントし、デバイスddrescueに書き込むのではなく、ファイルシステムの通常のファイルに書き込むように指示します（/dev/sdcコマンドで）。マップファイルを見てみましょうその他同じファイルシステムの一般的なファイル（賢明なアイデア：同じディレクトリにあります）

これは、ターゲットディスクがソースディスクよりも大きい場合にうまく機能するため、ファイルシステムが構造的に一部のスペースを占有していても、イメージ（ソースディスクサイズ）とマップファイルに十分なスペースがあります。ただし、ターゲットディスクが大きくない場合でも、圧縮および/または-S/--sparseオプションのファイルシステムであれば、イメージをddrescueファイルシステムに圧縮するのに十分です。ただし、データを十分に圧縮/疎化できるかどうかを事前に知る簡単な方法はありません。ソースドライブが正常な場合は、次のことができます。ハードドライブで使用中のスペースのみを複製。ただし、ドライブが故障した場合はこの方法をお勧めしません。

幸いなことに、あなたは「ターゲットドライブが失敗したドライブサイズの2倍です」とコメントしています。圧縮せずにイメージとマップファイルを収容できるターゲットドライブにファイルシステムを作成します。ファイルシステムは/dev/sdc1パーティション（）に配置することも、/dev/sdcデバイス全体（）に配置することもできます。よりシングルパーティションディスク構成の目的。ただし、決定を下す前に、現在の回答全体をお読みください。

圧縮が不要な場合でも、BtrfsはBtrfsをサポートしているため、Btrfsを使用します。書き込み中のコピー。完了したら、ddrescueイメージから書き込み権限を削除してコピー（cp --reflink=always …）を作成します。最初は余分なスペースを占めません。画像を変更するすべての操作（例fsck：）はコピーで行われます。問題が発生しても元のファイルはそのまま残るので、いつでも再起動できます。私はZFSも同じように役に立つと思いますが、それを使った経験はありません。

ディスク全体のイメージを通常のファイルとして使用すると、.または同様のコマンド（ddrescue読み取り可能であると仮定）を使用してパーティションテーブル（存在する場合）を確認できます。gdisk -l /path/to/imageここからファイルシステムをマウントできます（ddrescueファイルシステムをマウントするのに十分なデータを読み取ったとします）。便利なコマンド: losetup、kpartxまたはちょうどmount -o offset=…。これでファイルを読むことができます。画像を保存したのと同じファイルシステムにコピーできます。

/dev/sdc直接コピーするのが合理的な状況は少なくとも2つあります。

1. 失敗したディスクから起動するのと同じように、コピーから起動する必要があります。
2. 通常のファイルでは機能しないツール（回復ツールなど）を使用したい場合は、物理ディスクに固定されているツールを使用してください。これらの制限はUnix-yの設計によるものではありません。ツールはWindowsツールでもWindows自体でもかまいません。

ログファイルのサイズは通常どのくらいですか？

マップファイルヘッダーなど（〜350バイト）とデータブロックのリストで構成されています。同じ状態を維持する連続セクタブロックごとに1行（〜30バイト）。より悪い状況は、ドライブの各物理セクタが隣接セクタとは異なる状態にある場合です。その後、物理セクタごとに1行あります。つまり、ソースディスクの512バイトまたは4096バイトごとに約30バイトのマップファイルがあるため、マップファイルのサイズはソースディスクサイズの6％または1％を超えてはいけません。

したがって、理論的にはギガバイトは可能ですが、そのサイズ（つまり、テストドライブの他のすべてのセクタが破損したセクタ）に達するまでに長い時間がかかります。実際には、間違ったセクタを配置する方が幸運だと予想されます。マッピングファイルには数キロバイト、多分数メガバイトかかることが予想されます。

上記のファイルシステムではなく、ソースディスクをターゲットディスクに直接コピーする必要があるか選択し、ターゲットディスクがはるかに大きい場合は、マップされたファイルをターゲットドライブに保存できます。 。 1つの可能なアプローチは次のとおりです。

• ddrescueターゲットディスクの先頭から始めて大きなディスク（ソースディスクサイズ）を上書きしても、パーティションの内容が変更されないように、ターゲットドライブから十分に離れているパーティションを作成します。予想されるサイズのマップされたファイルを収容できるファイルシステムを収容できるほど、パーティションを大きくします。ただし、必要な場合に備えてディスクの端にスペースを残してください（1MiBで十分です）。GPT。パーティションにファイルシステムを作成します。

• mount -o offset=… /dev/sdc …（周囲ではない）を使用してファイルシステムをマウントできることを確認してくださいmount /dev/sdc1 …。取り付けたままにしておきます。紙にオフセットを書き留めます。

• 実行しddrescueて書き込む/dev/sdcようにしますが、マップファイルをマウントされたファイルシステムに配置します。これはsdcパーティションテーブルを上書きしますが、オフセットを知っているため、マップされたファイルを含むファイルシステムをマウントし続けることができます。

• 作業が完了したらddrescue（複数のセッションにわたって）パーティションテーブルを確認してください/dev/sdc。 MBRまたはデフォルトのGPTのDOSパーティションテーブルはソースディスクから起動されます（ddrescueこの部分を読み取れない場合を除く）。

  （注：論理セクタサイズに問題がある可能性があり、後で説明します。今は問題がないと仮定し、対策を講じる前に完全な回答を読んでください。）

  コピーされたパーティションテーブルがMBRのDOSパーティションテーブルである場合、問題はありません。

  GPTの場合は、セカンダリGPTを変更する必要があります。これで、ソースディスクのセカンダリGPTコピーがターゲットディスクの中央にあります。通常、最後にする必要があります。どこかに一つはあるかもしれません。古い補助GPTは/dev/sdcコピーには関係ありません。gdisk /dev/sdc違いを検出し、プライマリGPTのセカンダリGPTを変更するオプションを提供する必要があります（手動方法：回復オプションのr場合は、dバックアップを再作成します。「手動回復プロセス」を参照）。ここ）。

• マップされたファイルを含むファイルシステムをマウントし続けることができますが（使用offset=…）、ディスクのこの部分はパーティションテーブルによっては使用されなくなりました。ファイルシステムにアクセスしやすくするために、パーティションテーブルにエントリを作成できます（比較私の答え）または存在しなかったかのようにファイルシステムを拡張します。

ハードドライブをUSBエンクロージャに接続するのは良い考えではないという記事を読んでいます。 SATA接続のみがある場合、どのようなオプションがありますか？

ネットワークの他のコンピュータは

• ターゲットディスクをマウントし、NFSまたは同様のプロトコルを介してファイルを作成できます。
• 使用するターゲットディスクを公開してください。ブロックデバイスとして。

しかし、USBエンクロージャは大丈夫かもしれません。可能な問題を処理する方法がわかっている場合（私たちはそれについて学びます）、おそらく大丈夫でしょう。

必ず選択する必要がある場合は、新しいドライブをSATAポートに挿入し、故障したドライブをケースに入れるのが良いでしょうか、それともその逆ですか？

エンクロージャは、内部ディスクに障害が発生した場合に誤動作または予期しない動作を引き起こす可能性がある追加のレイヤです。だから、健康なターゲットディスクと一緒に使用することを好みます。しかし、他の側面もあります（主に珍しい点に対処します）。

これを実行する前にドライブがマウントされていないことを確認する必要がありますかddrescue？

元のドライブを変更しないでください。データを一度に読み取ることはできませんが、塊単位で読み取ることができます。読み込み中に内容が変わると、未接続の画像が表示されることがあります。比較する「パノラマ失敗」写真では、画像のさまざまな部分が異なる瞬間に撮影され、世界（ソース）は完全に静的ではありません。

ソースドライブは読み取り専用でマウントできます。ただし、ドライブに欠陥があるため、読み取ると状態が悪化する可能性があるため、不要に読まない方が最善です。ソースを削除したままにします。

ddrescueターゲットドライブのファイルシステムにある通常のファイルに書き込むには、ファイルシステムをマウントする必要があります。ターゲットドライブに書き込むには、ddrescue変更したいフラグメントをインストールしないでくださいが、適切な理由がある場合（たとえば、上記のプロセスでマップファイルを保存するなど）、さらに進むことができます。

ディスクセクタサイズが同じであることを確認し、ddrescue異なる場合はパラメータを渡す必要がありますか？

はい、必ず確認してください。ただし、いいえ、ddrescueソースディスクの物理セクタサイズに合わせて調整できるパラメータがありますが、それ自体で動作する必要があります（セクタが異なるためではありません）。他のセクタサイズは後で問題になる可能性があります。

さらに、一部のUSBエンクロージャには干渉を引き起こす可能性がある奇妙な現象が発生します。

まず、「物理セクタサイズ」と「論理セクタサイズ」の概念をよく理解してください。便利なリンク：

• LBAサイズは、ハードドライブの物理または論理セクタサイズにマッピングされますか？
• 私のハードドライブにセクターサイズの問題がありますか？
• 物理セクタサイズを報告するハードドライブのポイントは何ですか？

つまり、論理セクタを使用してドライブと通信しますが、内部的には物理セクタを使用してデータを読み書きします。オペレーティングシステムは1つの論理セクタしか要求できませんが、物理セクタサイズより小さい場合は物理セクタ全体を読み取りますが、そのうちの一部（要求された論理セクタ）のみが返されます。

呼び出されると、ddrescueセクタサイズ（バイト単位-b、デフォルト値512）とクラスタサイズ（-c一度にコピーされるセクタ、デフォルト値128）を指定できます。最初に（コピーステップ）ツールはクラスタ全体を一度に複数のセクタを読み取りますが、後で（トリム、スクラップステップ）個々のセクタを一度に1つずつ読みます。まあ、「部署」ではなく「部署」だと思います。

デバイスの物理物理セクタのサイズより小さいサイズを指定すると、-b読み取りエラーが発生した場合は、ddrescue物理セクタの一部を読み取って再試行します。内部的には、ドライブは毎回物理セクタ全体を読み取ろうとします。成功した場合、隣接するドレスキューが画像のセクタと見なす部分を埋めることができるという事実にもかかわらず、一部のデータはとにかく削除されます。隣接する各ピースには独自の試みが必要です。ディスクに障害が発生した場合、追加の操作によってドライブがより破損する可能性があるため、できるだけ少ない数の読み取りでできるだけ多くのデータを取得したいと思います-b。

デバイスの実際の物理セクタサイズより大きいサイズを指定すると、読み取り-bエラーが発生した場合は、ddrescue一度に複数の物理セクタを読み込もうとし、再試行します。成功しないと、物理セクタよりも大きな間隔が画像に残ります。ツールがより適切なセクタサイズを使用している場合は、問題なくこれらのフラグメントの一部を読むことができます。

511完全にクレイジーなセクタサイズ（たとえば、513または）を指定する4444と、何が起こるのかわかりません。私はそれをテストしませんでした。

-bデフォルト値はです512。これは、4096バイトの物理セクタサイズを使用するドライブに最適な選択ではありません。これは、2つのディスク間のセクタサイズが異なるかどうかに関係なく調整する必要があるパラメータです。

健康な対象のセクターサイズは重要ではないと思います。ddrescue検索可能なファイル（通常のファイルまたはブロックデバイス）に書き込むだけです。

これにより、シェルが妨げられる可能性があります。欠陥のあるディスクで使用することにしたとしましょう。一部の殻論理セクタサイズの変更物理セクタのサイズを知っている場合、これは重要ではありません。しかし、私はアダプタを持っていましたが、それは私にうそをつきました。物理セクターサイズ！512物理ディスク使用量を報告します4096。私が使ったのは欠陥のあるディスクで、ddrescue -b 512 …すべての不良セクタが8つのグループとして現れました。これが考えられました。4096SATA経由で接続した後、実際の値を報告しました。この過程でディスクが破損していましたが、-b 4096最初からディスクを使用した場合は、より多くのデータを回復できたのか疑問です。

先に私は「健康なターゲットディスクを備えたシャーシを使いたい」と書いています。これは本当ですが、ストレージデバイスが論理セクタサイズを変更できる場合は、それをターゲットディスクと一緒に使用することで可能です。

• パーティションにファイルシステムを作成し、イメージを通常のファイルに書き込むことにしました。すべての作品。その後、障害が発生したディスクは破棄され、ターゲットディスクはシャーシからSATA接続に移動されます。論理セクタのサイズが変更され、次のような状況が発生します。ファイルシステムの種類が正しくないため、ドライブをマウントできません。。
• デバイスへの書き込みを決定しましたが、コピーのパーティションテーブルがターゲットディスクで使用される論理セクタサイズと一致しません。

後者の状況はケースなしで発生する可能性があり、ケースを使用すると問題が解決する可能性があります（使用している場合）。これは、両方のディスクの論理セクタサイズとシャーシが干渉する方法（存在する場合）によって異なります。

良いニュース：mount -o offset=…パーティションテーブルが適切ではない場合でも、ファイルシステムをマウントできる必要があります。最後のリンクをクリックすると、私の答えに詳細が記載されています。

ただし、ブートするためにターゲットデバイスにコピーし、論理セクタサイズが異なるため、パーティションテーブルが無効な場合はパーティションテーブルを回復する必要があります。修理が可能な場合も不可能な場合もあります。