パーティションを編集する必要があることを知って、「dd」を使用してより小さいHDDにクローンを作成できますか？

私はddこのようなディスクのクローンを作成するために使用しました：

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

そして、それは常にうまく機能しています。「dd」に関するすべてのドキュメントは、ターゲットディスクがソースと同じサイズまたはそれ以上でなければならないことを思い出させるために苦労します。それは絶対に真実でなければなりませんか？

今、私は、より小さなディスクにクローンを作成する場合 、ターゲット上で部分的に「境界外」にあるパーティションが無傷であることを期待できないことを非常に理解しています。

ただし、ターゲットのパーティションを後で編集し、「境界外」のパーティションを削除する必要があることを十分に知っているので、「dd」を使用してソースのブルートフォースコピーを作成して、ターゲットの物理サイズ？または、そのサイズの限界に達したときに、ターゲットを残骸の喫煙の山に「dd」で縮小します;-)

ところで、これを調査して、bs=からbs=1024までのすべての推奨値を見てきましたbs=32M。

物理ドライブは少なくとも喫煙を開始すべきではありませんが、ファイルシステムが動作しなくなる可能性は非常に高くなります（つまり、ターゲットのファイルシステムです。 ）。パーティション内のデータは、必ずしも昇順で割り当てられるとは限りません。パーティションがいっぱいではない場合でも、パーティションの最後にある場合があります（実際、これは特定のファイルシステムで決定論的に発生すると思いますが、詳細を知るのに十分ではありません）。そこにあるデータは、ファイルシステムの整合性に不可欠な場合があります。したがって、このようなコピーに依存しないことを強くお勧めします。

このコピーを行うには、まず内部構造を認識し、すべてを適切な順序で小さなパーティションに再マッピングできるツールを使用して、パーティションを縮小する必要があります。その後、コピーを実行できます。gpartedこの種のことを行うには良いGUIインターフェースです。

bs値については、通常、最良のアイデアは、実際のコピーを開始する前にいくつかのテストを行うことです。このチェックの自動化に役立つツールがいくつかありますが、名前は覚えていません。私の経験では、最適な範囲は通常4M〜16Mです。それよりも高くなるともう稼ぐことはできません。しかし、ディスク自体を含む多くのことに依存しています。たとえば、実際のハイエンドディスクを使用することはめったにありませんでした。これは、速度とキャッシュサイズが大きいため、高い値に適している場合があります。

編集パーティションが完全にコピーされている場合、問題なく使用できます。ただし、他の人が下線を引いているように、パーティションテーブル（少なくとも、関連するエントリ）が損なわれていないことも確認する必要があります。MBRの4つのプライマリパーティションでは、ディスクの最初の512バイトに記述されているため、問題はありません。論理パーティションは拡張パーティション全体で記述されるため、エントリが失われる可能性があります（ただし、失われるパーティションは記述されます）。GPTでは、ディスクの最初と最後の両方にパーティションテーブルのコピーがあります。2番目のものは失われますが、最初のものから再構築できます。もちろん、できるだけ早くそれを行うことをお勧めします。他の答えはそれに関してより正確でした。

最初に提案された「チャレンジ」は難しいように見えるかもしれませんが、実行可能ではないか、一部の人がコメントしているように単純ではありませんが、そうではありません。ddを使用してより大きなディスクからより小さなディスクに移行することの背後にある主なアイデアは、完全に問題なく、データの移行に利点があります。もちろん、占有データが宛先ディスクに収まるように十分な空き領域を確保することは必要な要件です。

アイデアは、最初に提案されたように、一度にディスク全体ではなく、各パーティションを個別にdd'dすることです。さらに多くのことを達成できます：切り捨てられるパーティションは、ファイルシステムのサイズ変更ツールを少し助けて安全に移行することもできます。実際、そのような種類の移行は、ファイルシステム層ではなくファイルシステム層で動作するcp、rsync、paxなどのツールでは簡単にコピーできないファイルシステムmatadataおよび拡張ファイル属性を保持するために興味深いものです。ddを使用すると、SELinuxの問題を回避するために、OSを再インストールしたり、FSのラベルを付け直したりする必要がなくなります。

以下は、同様のタスクを達成するために私が通常行うことです。

1）最初に、影響を受けるパーティション内の切り捨てられるファイルシステムを減らします。これには、resize2fsツールを使用します（ext2 / ext3 / ext4 fsについて話していると仮定します-他の最新のFSにも同じ目的でサイズ変更ツールがあります）。-明らかな理由で-ファイルシステムは、それが存在するパーティションより大きくすることはできませんが、安全に小さくできることに注意してください。ここでの安全上の秘Theは、「必要以上」を減らすことです。たとえば、500ギガバイトのドライブに移行したい1TBのファイルシステムがあるとします。この場合、fsを450ギガバイトに減らすことをお勧めします（もちろん、これに十分な空き領域が必要です。つまり、このファイルシステムで現在占有されている領域は450ギガバイトを超えることはできません）。明らかに無駄になった50ギガのスペースは、データ移行後に修正されます。

2）スペースの制約を考慮して、適切なジオメトリで宛先ディスクをパーティション分割します。

3）ディスクデバイスではなくパーティションデバイスを使用してデータをddします（つまり、を使用するdd if=/dev/sda# of=/dev/sdb#代わりに各パーティションに使用しますif=/dev/sda of=/dev/sdb）。注：ここでのsdaとsdbは単なる例です。重要な注意：大きいパーティションデバイスから小さいパーティションデバイスにdd 'するとき、ddはブロックデバイスの最後にポストを書き込もうとすると文句を言います。ファイルシステムデータはそのポイントに到達する前に完全にコピーされるので大丈夫です。このようなエラーメッセージを回避するには、縮小ファイルシステムのサイズに一致するようにbs=とcount=パラメータを使用してコピーのサイズを指定できますが、これにはある程度の（単純な）計算が必要ですが、誤って行うとデータが危険にさらされる可能性があります。

4）データをdd 'した後、resize2fsを使用して、宛先パーティション内の各ファイルシステムのサイズを再度変更します。今回は、新しいファイルシステムのサイズを指定しないでください。サイズを指定せずに実行すると、resize2fsはファイルシステムを拡張して最大許容サイズを占有するため、この場合、450 Gigファイルシステムは再び成長して500 Gigパーティション全体を占有し、バイトは無駄になりません。（「必要以上に削減する」アプローチにより、誤ってサイズを誤って指定してデータを危険にさらすことを回避できます。GBとGiBの単位は注意が必要です。）

より複雑な操作に関する注意：一緒にコピーするブートマネージャーがある場合（これがよくあるケースです）、パーティションデバイスの代わりにディスクデバイスを使用して、ディスクの最初の数KBをddできます（ dd if=/dev/sda of=/dev/sdb bs=4096 count=5）、次に/ dev / sdbのジオメトリを再構成します（これには、一時的に新しいドライブの無効なジオメトリが含まれますが、完全で有効なブートマネージャが含まれます）。最後に、パーティションを一度にdd 'するために上記のパーティションデバイスを使用して続行します。このような操作を何度も行いました。ごく最近、MacMini6,2でMacOSXとLinuxのインストールが混在するHDDから小さなSDDにアップグレードするときに、複雑な移行を正常に実行しました。この場合、外部ドライブからLinuxをブートし、ブートマネージャーをddし、gdiskを実行して新しいディスクのGPTを修正し、最後に縮小したファイルシステムを含む各パーティションをddしなければなりませんでした。（GPTパーティションスキームは、パーティションテーブルの2つのコピーを保持します。1つはディスクの最初に、もう1つはディスクの最後にあります。gdiskは、PTの2番目のコピーを見つけることができず、パーティションがディスクサイズを超えるため、多くの苦情を訴えますが、ディスクジオメトリを再定義した後、PTコピーの問題を正しく修正します。これははるかに複雑なケースでしたが、この種の操作も完全に実行可能であることを示すため、言及する価値があります。

幸運を！...そして最も重要なことは、この種の操作の前にすべての重要なデータをバックアップすることを忘れないでください。間違いとあなたは間違いなくあなたのデータを回復不能に損傷する可能性があります。

念のため、移行前にデータをバックアップしてください。:)

車よりも20cm狭い通路に車を入れて、車の左20cmを切ったとしても、車は機能しますか？おそらくない。

ディスクの先頭を別のディスクにコピーし、コピー先のディスクが小さいためコピーを短くすると、結果は機能しません。ターゲットディスク上のすべてのファイルを収めるのに十分なスペースがある場合でも、ディスクの先頭からNバイトをカットしても、作業中のファイルシステムは得られません。

ディスクがPCスタイルのパーティション（GPTまたはMBR）に分割されている場合、ターゲットに完全に適合するすべてのパーティションが機能します。例外が1つあります。MBRパーティションでは、論理パーティションにディスク順に番号が付けられていない場合、チェーンがターゲット領域を離れるとすぐに、パーティションがリストされなくなります。（これを理解していない場合、それは部分的なディスクコピーを行わないもう1つの理由です。）最初からコピーし、適切なもので終わるのではなく、保持するパーティションをコピーする方がはるかに理にかなっています。 。最後に部分的にコピーされたパーティションは使用できません。

ディスクまたは部分パーティションがLVM物理ボリュームであり、その物理ボリュームの部分コピーを作成した場合、結果から有用なデータを取得することもできません。

一部のデータのみを大きなディスクから小さなディスクにコピーする場合は、小さなディスクにパーティションを作成します。パーティションを同じサイズのパーティションにコピーする場合は、を使用して実行できますcat。パーティションを小さなパーティションにコピーする場合は、ターゲットパーティションにファイルシステムを作成し、cp -aまたはなどのファイルレベルのコピーを実行しますpax -rw -pe -t。

あなたがマゾの場合のdd代わりに使用することができますcat。dd奇妙な構文があり、通常cat、適切なバッファサイズが見つからない場合よりも低速です。バッファサイズに最適な値はありません。ハードウェアの特性によって異なります。サイズが小さすぎると、dd多くの小さな転送を行うのに時間が無駄になります。サイズが大きすぎる場合、dd次のバッファの書き込みを開始する前に、1つのバッファを完全に読み取る時間を無駄にします。ディスクからディスクへの転送の最適なサイズは通常数メガバイトです（1024バイトはとてつもなく小さいです）。catあなたの側の努力なしでまともなサイズを選択します。

これが別の読者に役立つと思われる場合は、このトピックに関する私の経験を共有したいと思います。最近、DDRESCUEを使用して、故障したハードドライブからNTFSパーティションの最初の1/3を回復し、パーティションの回復したセグメントを小さなハードドライブに正常に再構築しました。以下は私がそうするために行ったステップです（間違いなくHACKSAWアプローチ!!） ...

ソースハードドライブは、MBRファイルテーブルでNTFSでフォーマットされた750GBで構成されていました。ファイルのバックアップに数回しか使用していなかったため、ほとんどのファイルはドライブの先頭にあり、約160GBに相当しました。家族がハードドライブ（外付け）を床にたたきつけました-その後、正常に機能しませんでした！ddrescueを使用して（苦労して）ドライブの最初の大部分を回復できました。物理的な損傷のため、プロセス全体で非常に頻繁にシャットダウンします...

150GB（外付け）の小型ラップトップハードドライブがあり、ddrescueデータを直接抽出しました。別の方法として、データをイメージファイルに抽出し、後でファイルをマウントすることもできますが、ハードドライブに直接データを書き込むのはもっと簡単だと思いました。

救助の鍵となるトリックは、救助用ハードドライブ上のMBRとNTFSブートセクターデータの両方を手動で編集することでした。そうしないと、ハードドライブはどのオペレーティングシステムでも認識されません。Linuxで適切なプログラムを見つけることができなかったため、Windowsを使用しました。Windowsサポートツールという便利なパッケージがありますが、メンテナンスはされていませんが、まだ便利です（以下のリンクを参照）。パーティションの編集に使用したツールはディスクプローブです。ハードドライブのエンドセクター値を確認してください（Ubuntuではfdisk -lを使用しました）

https://en.wikipedia.org/wiki/Windows_Support_Tools

優れた計算機と創造性を使用して、ハードドライブをWindowsのディスクプローブにロードしてマウントし、エンドセクターの値を編集しました。MBRでは、2つの値セット、つまりa）ハードドライブの終了セクターとb）NTFSパーティションの終了セクターを変更する必要がありました。NTFSブートセクターでは、パーティションの合計セクター値を変更する必要がありました。いずれの場合も、小さいハードドライブの「寸法」の減少に合わせて数値が減少しました（エンドセクターは750GBから150GBに変更されました）。[表示]タブをクリックして、これらの値を編集します。

NTFSブートセクターデータの編集中のディスクプローブの画像を次に示します。

前述のフィールドを編集すると、Windowsはパーティションが破損しているにもかかわらず有効なパーティションであると認識しました。コマンドプロンプトを入力し、破損したハードドライブ（chdsk D :)でWindowsプログラムChkdskを実行しました。ファイルごとにパーティションが復活するのを見るのはスリリングでした！プログラムはパーティションテーブルを再構築し、破損したハードドライブからコピーされたすべてのファイルを正常に再マップしました。範囲外（コピーされていない）のファイルは見つからなかったため、削除されました。

次の部分では、Windowsがファイルを含む150GBのハードドライブを正常に再構築したため、理由がわかりません。それにもかかわらず、Windowsはファイル表示用にハードドライブパーティションをネイティブに開くことができませんでした（何らかのエラーがありました）。しかし、Ubuntuが助けになります！Ubuntuを再起動し、外付けハードドライブをマウントしましたが、まったく問題なく、復元されたすべてのファイルが表示されました。

大きなハードドライブから小さなハードドライブにファイルを回復するこの弓の方法が、私以外の貧しい人々にとって役立つことを願っています。乾杯！

最初にソースのパーティションを縮小する（または範囲外のパーティションを削除する）必要があります。
よりddあなたはおそらく使用してパーティションテーブルを修復する必要がありますし、後にgdisk /dev/sd<target>
されたテーブルを修復するために、キーシーケンスをv r d w
、私はあなたが必要なより少し小さいパーティションをshringに提案し、後に戻ってターゲットディスクのフルサイズにそれらを展開します。
（この答えは、HDDをより小さなSSDにクローンしたときの個人的な経験に基づいています）