パーティションを編集する必要があることを知り、「dd」を使用して小さなハードドライブに複製できますか？

他の人がここで述べたように、ddGPTテーブルのコピーはディスクの末尾に配置されているため、使用すると機能しません。

次の方法を使用して、より小さいドライブに正常に移行しました。

まず、選択したliveCDディストリビューションから起動します。

gparted小さいドライブの制約（使用量など）に合わせてソースドライブパーティションのサイズを変更します。それからsdaソースディスクであると仮定し、sgdisk安全のために最初にソースドライブからGPTテーブルのバックアップを作成します。

    sgdisk -b=gpt.bak.bin /dev/sda

ターゲットを想定し、ソースsdbドライブのテーブルをターゲットにコピーします。

    sgdisk -R=/dev/sdb /dev/sda

sgdiskこれで、ターゲットディスクの境界の外側にヘッダーコピーを配置しようとしましたが、再度ターゲットディスクの上限にヘッダーを正しく配置すると不平を言います。

gparted選択したツール（例）を使用して、ターゲットドライブに正しいパーティションテーブルレプリケーションが作成されていることを確認してください。

以下を使用して、ddソースドライブの各パーティションをターゲットドライブにコピーします。

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

ddもちろん、バックアップなしでGPTパーティションテーブルをコピーしたり、内容を読み取ったりするときにドライブ名を難読化すると、内容とは別にすることができます:)

少なくとも物理ドライブは延期しないはずですが、ファイルシステムは動作しなくなる可能性があります（ターゲットファイルシステムを意味します。コピーしてソースに何も触れていない場合は、ソース自体は問題ありません）。パーティション内のデータが必ずしも昇順で配布されるわけではありません。そのうちのいくつかは、パーティションがいっぱいになっていない場合でもパーティションの最後にあるかもしれません（実際には、いくつかのファイルシステムではこれが決定的に起こると思いますが、それほど詳細はわかりません）。そのデータはファイルシステムの整合性にとって非常に重要です。したがって、そのようなコピーに頼らないことを強くお勧めします。

このコピーを実行するには、まず内部構造を理解し、すべてを正しい順序でより小さいパーティションに再マップできるいくつかのツールを使用してパーティションを縮小する必要があります。その後、コピーを作成できます。gpartedこの種のタスクを実行するための素晴らしいGUIインターフェースです。

価値の面でbs最良のアイデアは、実際のコピーを開始する前にいくつかのテストを実行することです。この検証を自動化するのに役立つツールがありますが、名前は覚えていません。私の経験では、最適な範囲は通常4Mから16Mの間です。その数以上ではお金をたくさん稼ぐことはできません。ただし、これはディスク自体を含むいくつかの要因によって異なります。たとえば、速度とキャッシュサイズが大きいため、より高い値に適している可能性がある高度なディスクをほとんど使用しません。

編集するパーティションが完全にコピーされると、問題なく使用できます。ただし、他の人が強調したように、パーティションテーブルが破損していないことを確認する必要があります（少なくとも関連項目）。 MBRの4つの基本パーティションは、ディスクの最初の512バイトで説明されているため、問題はありません。論理区画は拡張区画全体にわたって記述されるため、項目が失われる可能性があります（ただし、いずれにしても失われる区画を説明します）。 GPTでは、ディスクの先頭と末尾にパーティションテーブルのコピーがあります。二度目を失っても最初から作り直すことができます。もちろん、できるだけ早くこれを行うことをお勧めします。これについては、他の答えがより正確です。

提起された初期の「挑戦」は困難で実行不可能に見えるかもしれませんが、一部の人が言及したように素朴に見えるかもしれませんが、そうではありません。 dd を使用してより大きなディスクからより小さいディスクに移行する主なアイデアは、非常に良いものであり、データの移行に最適です。もちろん、占有データがターゲットディスクに収まるように十分な空き容量を確保することは必須です。

アイデアは、元の提案どおりにディスク全体を一度に追加するのではなく、各パーティションを個別に追加することを検討することです。より多くのことができます。ファイルシステムのサイズ変更ツールの助けを借りて、切り捨てるパーティションも安全に移行できます。実際、この移行は、ブロックデバイス層ではなく、ファイルシステム層で動作するcp、rsync、paxなどのツールを使用して簡単に再現できないファイルシステムメタデータと拡張ファイル属性を保存するという点で興味深いものです。 dd を使用すると、SELinux の問題を回避するためにオペレーティングシステムを再インストールしたり、FS ラベルを再指定したりする必要はありません。

似たようなことをするために私が一般的に行うことは次のとおりです。

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

2) ターゲットディスクのスペース制限を考慮して、適切な構造を使用してターゲットディスクを分割します。

3）ディスクデバイスの代わりにパーティションデバイスを使用してデータを追加します（例：注：dd if=/dev/sda# of=/dev/sdb#ここif=/dev/sda of=/dev/sdbにあるsdaとsdbは単なる例です）重要な注意：より大きなパーティションデバイスからより小さいパーティションデバイスに書き込むとき、ddはブロックデバイスです。の終わりに投稿を書こうとすることについて不平を言うでしょう。これはファイルのために問題ありませんbs=。一致するようにコピーサイズを指定できますが、count=この場合はいくつかの（簡単な）計算が必要ですが、誤って実行するとデータが破損する可能性があります。

4）データを追加したら、resize2fsを使用してターゲットパーティションの対応するファイルシステムのサイズを変更します。今回は新しいファイルシステムサイズを指定しません。サイズを指定せずに実行すると、resize2fsは最大許容サイズを占めるようにファイルシステムを拡張するため、この場合、450Gigファイルシステムは500Gigパーティション全体を再び大きくし、バイトを無駄にしません。 （「必要以上に減らす」アプローチは、誤って誤ったサイズを指定し、データを危険にさらすのを防ぎます。GBとGiBユニットは難しいかもしれません。）

より複雑な作業の場合は、以下を参照してください。ブートマネージャを複製する場合（ほとんどの場合）、パーティションデバイスの代わりにディスクデバイスを使用してディスクの最初の数KB（たとえばdd if=/dev/sda of=/dev/sdb bs=4096 count=5）を追加し、/ dev / sdbの構造を再構成します（新しいドライブの無効な構造一時的に含まれますが、完全かつ有効なブートマネージャは含まれています）。最後に、上記のようにパーティション化デバイスを使用して、一度に1つのパーティションを追加し続けます。私はこれを何度もやってきました。私は最近、MacOSXとLinuxインストールが混在したHDDをより小さなSDDにアップグレードしたときに、MacMini6,2で複雑な移行を成功させました。この場合、外部ドライブからLinuxを起動し、ブートマネージャを追加し、gdiskを実行して新しいディスクのGPTを変更し、最後に縮小したファイルシステムを含む各パーティションを追加する必要があります。 （GPTパーティション化スキームはパーティションテーブルの2つのコピーを保持します。1つはディスクの先頭に、もう1つは最後にあります。gdiskはPTの2番目のコピーを見つけることができず、パーティションが不足しているため、多くの苦情を表示ディスクのサイズを変更しましたが、ディスク構造をオーバーライドした後、PTレプリケーションの問題を正しく解決しました。

頑張ってください！ ...最も重要なことは、このようなタスクを実行する前に重要なデータをすべてバックアップすることを覚えておくことです。 1回の間違いは、データが回復できないほど破損する可能性があります。

いくら強調しても過度ではない場合に備えて、移行する前にデータをバックアップしてください。 :)

このトピックに関する私の経験が他の読者にも役立つ場合は、共有したいと思いました。最近私はDDR構造故障したハードドライブからNTFSパーティションの最初の3分の1を回復し、回復したパーティションセグメントを小さなハードドライブに正常に再構成して、キャプチャされたファイルを回復しました（残りは失われました）。このために私が取ったステップは次のとおりです。（もちろん金のこぎり!!）...

ソースハードドライブは、NTFS形式の750GBとMBRファイルテーブルで構成されています。ファイルバックアップ用に数回だけ使ってみたので、ほとんどのファイルが160GB程度になるドライブの先頭に入っています。家族の一人がハードドライブ（外付け）を床に落としました。それ以来、正常に動作したことがありません！ ddrescueを使用して（苦労して）ドライブの始まりの大部分を回復することができました。物理的な損傷のため、全体的に非常に頻繁なシャットダウン...

利用可能な小さな150GBノートブックハードドライブ（外部マウント）があり、ddrescueデータをここに直接抽出します。または、データをイメージファイルに抽出してファイルをマウントすることもできますが、データをハードドライブに直接書き込む方が簡単だと思います。

コアリカバリ技術は、リカバリハードドライブのMBRおよびNTFSブートセクタデータを手動で編集することです。そうしないと、どのオペレーティングシステムでもハードドライブを認識できません。 Linuxでは、これを行うのに適したプログラムが見つからず、Windowsに切り替えました。もはやメンテナンスされていませんが、まだ便利なWindowsサポートツールと呼ばれる便利なパッケージがあります（下記のリンクを参照）！パーティションの編集に使用するツールはDisk Probeです。ハードドライブの終了セクタ値を知っていることを確認してください（Ubuntuではfdisk -lを使用しました）。

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

良い電卓と創造性を使って、WindowsのDisk Probeにハードドライブをロードしてマウントし、最後のセクタ値を編集しました。 MBRでは、a）ハードドライブエンドセクタとb）NTFSパーティションエンドセクタという2つの値のセットを変更する必要があります。 NTFSブートセクタでは、パーティション全体のセクタ値を変更する必要があります。それぞれの場合、小さいハードドライブの縮小された「サイズ」に合わせて値が減少します（エンドセクタは750 GBから150 GBに変更されます）。この値を編集するには、[表示]タブをクリックします。

NTFSブートセクタデータを編集するDisk Probeイメージ。

上記のフィールドを編集した後、Windowsはそのパーティションが破損しているにもかかわらず有効なパーティションとして認識しました。コマンドプロンプトに入り、破損したハードドライブからWindowsプログラムChkdsk（chdsk D：）を実行しました。パーティションがファイル単位で生きているのを見るのは楽しいことです！プログラムはパーティションテーブルを再作成し、破損したハードドライブからコピーされたすべてのファイルを正常に再マップします。範囲外（コピーされていない）ファイルが見つからなかったため削除されました。

次のセクションでは、Windowsを含むファイルを使用して150 GBのハードドライブを正常に再構築したため、理由を理解できません。それにもかかわらず、Windows自体はファイルを表示するためにハードディスクパーティションを開くことができません（いくつかのバグがあります）。しかし、Ubuntuはあなたを救うことができます！ Ubuntuで再起動して外付けハードドライブをマウントしましたが、まったく問題がなく、修復されたファイルがすべて表示されました！

大きなハードドライブから小さなハードドライブにファイルを回復するこの鋸歯の方法が、他の貧しい魂にも役立つことを願っています。乾杯！