'dd'を使用して、パーティションを編集する必要があることを認識して、より小さなHDDに複製できますか？
私はddを使用して、次のようにディスクのクローンを作成しました：
dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync
そして、それは常にうまくいきます。 'dd'に関するすべてのドキュメントは、ターゲットディスクのサイズがソースと同じかそれ以上である必要があることを思い出させるために苦労します。それは絶対に本当である必要がありますか？
さて、私はより小さなディスクにクローンを作成する場合、ターゲットの部分的に「範囲外」でさえあるパーティションがそのままであると期待できないことを理解しています。
ただし、後でターゲットのパーティションを編集して「範囲外」のパーティションを削除する必要があることを十分に理解している場合でも、「dd」を使用してソースのブルートフォースコピーをターゲットの物理的なサイズは？または、ターゲットのサイズが限界に達したときに、ターゲットを「残骸の喫煙の山」に減らします;-)
ところで、これを調査して、bs=からbs=1024までのすべてのbs=32Mの推奨値を確認しましたが、実際には何が最適ですか？
他の人がここで言及したように、ディスクの最後に配置されたGPTテーブルのコピーのため、ddだけを使用しても機能しません。
次の方法を使用して、より小さなドライブへの移行を実行できました。
まず、選択した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
dd if=/dev/sda2 of=/dev/sdb2 bs=1M
dd if=/dev/sda3 of=/dev/sdb3 bs=1M
etc...
明らかに、バックアップなしでGPTパーティションテーブルを複製するとき、またはコンテンツをddingするときにドライブの名前を混在させると、コンテンツに別れを告げることができます:)
物理ドライブは少なくとも喫煙を開始するべきではありませんが、ファイルシステムが機能しなくなる可能性は非常に高くなります（つまり、ターゲットファイルシステムです。コピーしてソース内の何も変更しなかった場合、ソース自体は問題ありません） ）。パーティション内のデータは、必ずしも昇順で割り当てられるとは限りません。パーティションがいっぱいでなくても、一部がパーティションの最後にある場合があります（実際、これはいくつかのファイルシステムで確定的に発生すると思いますが、詳細を理解するのに十分な知識がありません）。そこにあるデータは、ファイルシステムの整合性に不可欠な場合があります。したがって、そのようなコピーに依存しないように強くお勧めします。
このコピーを行う場合は、まず内部構造を認識し、すべてを適切な順序で小さなパーティションに再マップできるツールを使用して、パーティションを圧縮する必要があります。その後、コピーを行うことができます。 gpartedは、この種のことを行うのに適したGUIインターフェイスです。
bs値の場合、通常、実際のコピーを開始する前にいくつかのテストを行うことが最善の方法です。このチェックを自動化するのに役立つツールがいくつかありますが、名前を覚えていません。私の経験では、最適な範囲は通常4Mから16Mです。それより高いと、あなたはもうあまり稼ぎません。しかし、それはディスク自体を含む多くのものに依存します。たとえば、実際のハイエンドディスクを使用することはほとんどありません。これは、速度とキャッシュサイズが大きいため、より高い値に適している場合があります。
[〜＃〜] edit [〜＃〜]パーティションが完全にコピーされた場合、問題なく使用できます。ただし、他の人が下線を引いたように、パーティションテーブルが完全な状態であることを確認する必要もあります（少なくとも、関連するエントリ）。 MBRの4つのプライマリパーティションでは、ディスクの最初の512バイトに記述されているため、問題はありません。ロジックパーティションは拡張パーティション全体に記述されるため、エントリが失われる可能性があります（とにかく失われるパーティションが記述されます）。 GPTを使用すると、ディスクの最初と最後の両方にパーティションテーブルのコピーがあります。 2番目のものは失われますが、最初のものから再構築できます。もちろん、それをできるだけ早く行うことをお勧めします。他の答えはそれに関してより正確でした。
提案された「チャレンジ」は最初は難しいように見えるかもしれませんが、実現可能ではないか、一部の人がコメントしたように素朴なように聞こえますが、そうではありません。大容量ディスクから小容量ディスクに移行するためにddを使用することの背後にある主なアイデアは、完全に適切であり、データの移行にメリットがあります。もちろん、占有されているデータが宛先ディスクに収まるように十分な空き領域を確保することは必要条件です。
アイデアは、最初に提案されたディスク全体ではなく、各パーティションを個別にddすることを考えることです。さらに多くのことを達成できます。切り捨てられるパーティションは、ファイルシステムのサイズ変更ツールを少し使用して安全に移行することもできます。実際、このような種類の移行は、ファイルシステムレイヤーとブロックデバイスレイヤーではなく動作するcp、rsync、paxなどのツールでは簡単にコピーできないファイルシステムのデータと拡張ファイル属性を維持するために興味深いものです。 ddを使用することで、OSを再インストールしたり、SELinuxの問題を回避するためにFSのラベルを付け直したりする必要がなくなります。
以下は、私が同様のタスクを達成するために通常行うことです。
1）最初に、切り詰められる影響を受けるパーティション内のファイルシステムを減らします。これには、resize2fsツールを使用します（ext2/ext3/ext4 fsについて話していると仮定します。他の最新のFSにも同じ目的でサイズ変更ツールがあります）。明らかな理由により、ファイルシステムはそれが常駐するパーティションより大きくすることはできませんが、安全に小さくすることができます。ここでの安全策は、「必要以上に」減らすことです。たとえば、500 GBのドライブに移行する1 TBのファイルシステムがあるとします。この場合、たとえば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パーティション全体を占有し、バイトが無駄になることはありません。 （「必要以上に減らす」アプローチは、誤ってサイズを誤って指定してデータを危険にさらすことを防ぎます。GBvs GiB単位は扱いにくい場合があることに注意してください）。
より複雑な操作に関する注意：コピーするつもりのブートマネージャーがある場合は、その可能性が非常に高いため、パーティションデバイス（dd if=/dev/sda of=/dev/sdb bs=4096 count=5など）の代わりにディスクデバイスを使用して、ディスクの最初の数KBをddできます。 ）、次に/ dev/sdbのジオメトリを再構成します（新しいドライブには無効なジオメトリが一時的に含まれますが、そのままの有効なブートマネージャが含まれます）。最後に、パーティションデバイスを使用して、パーティションを一度に1つずつ削除します。このような手術を何度もしました。ごく最近、MacOSXとLinuxのインストールが混在するHDDからMacMini6,2の小さなSDDにアップグレードするときに、複雑な移行を正常に実行しました。この場合、外部ドライブからLinuxを起動し、ブートマネージャーをddし、gdiskを実行して新しいディスクのGPTを修正し、最後に縮小したファイルシステムを含む各パーティションをddしました。 （GPTパーティションスキームでは、パーティションテーブルの2つのコピーがディスクの最初と最後に保持されます。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よりも遅い です。バッファサイズに最適な値は1つではなく、ハードウェアの特性によって異なります。サイズが小さすぎる場合、ddは多くの小さな転送を行うのに時間を浪費します。サイズが大きすぎる場合、ddは次のバッファの書き込みを開始する前に1つのバッファを完全に読み取るのに時間を浪費します。ディスクからディスクへの転送に最適なサイズは、通常数メガバイトです（1024バイトはとんでもなく小さいです）。 catは、ユーザーの負担なしに適切なサイズを選択します。
最初にソースのパーティションを縮小する必要があります（または、境界外を削除します）。ddより後、おそらくgdisk /dev/sd<target>を使用してパーティションテーブルを修復する必要があります
テーブルを修復するためのキーシーケンスはv r d wです
パーティションを必要よりも少し小さくして、ターゲットディスクのフルサイズに拡張してからパーティションをシュレッドすることをお勧めします。
（この回答は、私のHDDをより小さなSSDにクローンしたときの私の個人的な経験に基づいています）
これが別の読者に役立つことが判明した場合は、このトピックに関する私の経験を共有したいと思います。最近、私は[〜＃〜] ddrescue [〜＃〜]を使用して、故障したハードドライブからNTFSパーティションの最初の1/3を回復しました。パーティションの復元されたセグメントをより小さなハードドライブに正常に再構築しました-それにより、キャプチャされたファイルを救出します（そして残りを失います）。以下は、私が行った手順です（間違いなくHACKSAWアプローチ!!）...
ソースハードドライブは、NTFSでフォーマットされた750GBとMBRファイルテーブルで構成されていました。ファイルをバックアップするために数回しか使用していなかったので、ほとんどのファイルはドライブの最初にあり、約160GBの価値がありました。家族がハードドライブ（外付け）を床にたたきました-その後は正常に機能しませんでした。 ddrescueを使用して（苦労して）、ドライブの最初の大部分を回復できました。物理的な損傷のため、プロセス全体で非常に頻繁にシャットダウンします...
私は150GB（外付け）の小さなラップトップのハードドライブを持っていて、そこにddrescueデータを直接抽出しました。または、データをイメージファイルに抽出し、後でファイルをマウントすることもできますが、ハードドライブに直接データを書き込む方が簡単です。
レスキューの重要なトリックは、レスキューハードドライブのMBRとNTFSブートセクターの両方のデータを手動で編集することでした。そうしないと、ハードドライブはどのオペレーティングシステムにも認識されません。 Linuxで適切なプログラムを見つけることができなかったので、Windowsに切り替えました。 Windows Support Toolsという名前の便利なパッケージがあり、メンテナンスはされていませんが、まだ便利です（以下のリンクを参照）。パーティションの編集に使用したツールはディスクプローブです。ハードドライブのエンドセクター値を確認してください（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のハードドライブをファイルを含めて正常に再構築したためです。それにもかかわらず、ウィンドウはネイティブでファイル表示のためにハードドライブパーティションを開くことができませんでした（エラーが発生しました）。しかし、Ubuntuが助けになります！ Ubuntuで再起動し、外付けハードドライブをマウントしました。問題なく、復元されたすべてのファイルが表示されました。
うまくいけば、大きなハードドライブから小さなハードドライブにファイルを回復するこのこぎりの方法が、私以外の貧しい人々にも役立つことがわかるでしょう。乾杯！