私はdd次のようにディスクのクローンを作成していました:
dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync
そして、それは常にうまく機能しました。 'dd' に関するすべてのドキュメントでは、ターゲット ディスクのサイズはソースと同じかそれより大きくなければならないことを念入りに思い出させてくれます。 それは絶対に真実である必要がありますか?
さて、私は、より小さなディスクにクローンすると、同じサイズのパーティションは期待できないことを理解しています。部分的に ターゲットの「境界外」はそのまま残ります。
しかし、後でターゲットのパーティションを編集して「範囲外」のものを削除する必要があることを十分承知した上で、ターゲットの物理サイズの制限までソースのブルートフォース コピーを作成するために「dd」を使用できるでしょうか? それとも、「dd」はターゲットがサイズの制限に達したときに、煙を上げる残骸の山に縮小するでしょうか ;-)
ところで、これについて調査したところ、から までのbs=すべてのの推奨値を見ましたが、実際に最適なものは何でしょうか?bs=1024bs=32M
答え1
他の人がここで述べているように、ddディスクの最後に GPT テーブルのコピーが配置されているため、これを使用すると機能しません。
次の方法を使用して、より小さなドライブへの移行を実行することができました。
まず、選択したライブ CD ディストリビューションを起動します。
ソース ドライブのパーティションのサイズを、小さい方のドライブの制約内に収まるように変更します (例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 パーティション テーブルを複製するときやコンテンツを するときにドライブの名前を間違えると、コンテンツが失われることになります :)
答え2
少なくとも物理ドライブが煙を出すことはないはずですが、ファイルシステムが機能しなくなる可能性が非常に高いです (つまり、ターゲット ファイルシステムです。コピーしただけでソースに何も触れていない場合は、ソース自体は問題ありません)。パーティション内のデータは、必ずしも昇順に割り当てられるわけではありません。パーティションがいっぱいでなくても、パーティションの最後にデータの一部がある場合があります (実際には、一部のファイルシステムではこれが決定論的に発生すると思いますが、詳細を把握するほどの知識はありません)。そこにあるデータは、ファイルシステムの整合性にとって不可欠な場合があります。したがって、このようなコピーには頼らないことを強くお勧めします。
このコピーを実行するには、まずパーティションの内部構造を認識し、すべてを適切な順序で小さなパーティションに再マップできるツールを使用してパーティションを縮小する必要があります。その後、コピーを実行できます。は、gpartedこのような操作を実行するのに適した GUI インターフェイスです。
値についてはbs、実際のコピーを開始する前に、いくつかのテストを行うのが通常最善の策です。このチェックを自動化するツールがいくつかありますが、名前は覚えていません。私の経験では、最適な範囲は通常 4M から 16M の間です。それよりも高いと、あまり効果がありません。ただし、ディスク自体を含む多くの要因に依存します。たとえば、実際のハイエンド ディスクで作業することはほとんどありませんが、速度とキャッシュ サイズが大きいため、より高い値に適している可能性があります。
編集パーティションが完全にコピーされていれば、問題なく使用できます。ただし、他の人が強調しているように、パーティション テーブルが (少なくとも関連するエントリが) そのままであることも確認する必要があります。MBR の 4 つのプライマリ パーティションはディスクの最初の 512 バイトに記述されているため、問題はありません。論理パーティションは拡張パーティション全体に記述されるため、エントリが失われる可能性があります (ただし、いずれにせよ失われるパーティションを記述します)。GPT では、ディスクの先頭と末尾の両方にパーティション テーブルのコピーがあります。2 番目のコピーは失われますが、1 番目のコピーから再構築できます。もちろん、できるだけ早く行うことをお勧めします。この点については、他の回答の方が正確でした。
答え3
提案された「チャレンジ」は、最初は難しく、実現不可能で、一部のコメントにあるようにナイーブに聞こえるかもしれませんが、そうではありません。dd を使用して大きなディスクから小さなディスクに移行するという基本的な考え方はまったく問題なく、データの移行にメリットがあります。もちろん、占有データが移行先のディスクに収まるだけの十分な空き領域があることは必須の要件です。
アイデアは、最初に提案されたようにディスク全体を一度に dd するのではなく、各パーティションを個別に dd することを検討することです。さらに多くのことが実現できます。切り捨てられるパーティションも、ファイルシステムのサイズ変更ツールの助けを借りて安全に移行できます。実際、このような種類の移行は、ブロック デバイス層ではなくファイルシステム層で動作する cp、rsync、pax などのツールでは簡単にコピーできないファイルシステム メタデータと拡張ファイル属性を保持するために興味深いものです。dd を使用すると、SELinux の問題を回避するために OS を再インストールしたり、FS を再ラベル付けしたりする必要がなくなります。
以下は、同様のタスクを達成するために私が通常行っていることです。
1) まず、切り捨てられる影響を受けるパーティション内のファイルシステムを縮小する必要があります。そのためには、resize2fs ツールを使用します (ext2/ext3/ext4 ファイルシステムについて話しているものと仮定します。他の最新のファイルシステムにも、同じ目的のサイズ変更ツールがあります)。当然の理由により、ファイルシステムは、それが存在するパーティションよりも大きくすることはできませんが、安全に小さくすることはできます。ここでの安全策は、「必要以上に」縮小することです。たとえば、1TB のファイルシステムがあり、それを 500 ギガバイトのドライブに移行するとします。この場合、ファイルシステムをたとえば 450 ギガバイトに縮小することをお勧めします (もちろん、これには十分な空き領域が必要です。つまり、このファイルシステムで現在占有されている領域は 450 ギガバイトを超えることはできません)。明らかに無駄になっている 50 ギガバイトの領域は、データ移行後に修正されます。
2) スペースの制約を考慮して、適切なジオメトリで宛先ディスクをパーティション分割します。
3) ディスク デバイスではなくパーティション デバイスを使用してデータを dd します (つまり、dd if=/dev/sda# of=/dev/sdb#を使用する代わりに各パーティションに を使用しますif=/dev/sda of=/dev/sdb)。注: ここでの sda と sdb は単なる例です。重要な注意: 大きいパーティション デバイスから小さいパーティション デバイスに dd すると、dd はブロック デバイスの末尾に post を書き込もうとしているというエラーを出しますが、その時点に達する前にファイル システム データが完全にコピーされているので問題ありません。このようなエラー メッセージを回避するには、縮小されたファイル システム サイズに一致するようにbs=およびcount=パラメータを使用してコピーのサイズを指定できますが、これには (簡単な) 計算が必要になりますが、誤って行うとデータが危険にさらされる可能性があります。
4) データを dd した後、resize2fs を使用して、宛先パーティション内の各ファイルシステムのサイズを再度変更します。今回は、新しいファイルシステムのサイズを指定しないでください。サイズを指定せずに実行すると、resize2fs はファイルシステムを拡張して最大許容サイズを占有します。したがって、この場合、450 ギガのファイルシステムは再び拡張して 500 ギガのパーティション全体を占有し、バイトは無駄になりません。(「必要以上に縮小する」アプローチにより、誤ってサイズを指定してデータを危険にさらすことを回避できます。GB と GiB の単位は扱いにくいことに注意してください)。
より複雑な操作に関する注意: 一緒にコピーする予定のブート マネージャーがある場合 (非常に可能性が高い)、パーティション デバイス (などdd if=/dev/sda of=/dev/sdb bs=4096 count=5) ではなくディスク デバイスを使用してディスクの最初の数 KB を dd し、/dev/sdb のジオメトリを再構成できます (一時的に新しいドライブの無効なジオメトリが含まれますが、ブート マネージャーはそのままで有効です)。最後に、上記のようにパーティション デバイスを使用して、一度に 1 つのパーティションを dd します。私はこのような操作を何度も行いました。ごく最近、MacOSX と Linux のインストールが混在する HDD から MacMini6,2 のより小さな SDD にアップグレードするという複雑な移行を正常に実行しました。この場合、外部ドライブから Linux を起動し、ブート マネージャーを dd し、gdisk を実行して新しいディスクの GPT を修正し、最後に縮小したばかりのファイル システムを含む各パーティションを dd する必要がありました。 (GPT パーティション スキームは、パーティション テーブルのコピーを 2 つ保持します。1 つはディスクの先頭に、もう 1 つはディスクの末尾にあります。gdisk は、PT の 2 番目のコピーが見つからないことと、パーティションがディスク サイズを超えていることが原因で頻繁にエラーを出力しますが、ディスク ジオメトリを再定義すると、PT コピーの問題は正しく修正されます)。これははるかに複雑なケースでしたが、この種の操作も完全に実行可能であることを示しているため、言及する価値があります。
幸運を祈ります！...そして最も重要なことは、このような操作を行う前にすべての重要なデータをバックアップすることを忘れないでください。ミスをすると、データが回復不能なほど損傷する可能性があります。
念のため、移行前にデータをバックアップしてください! :)
答え4
このトピックに関する私の経験が他の読者にとって役立つかもしれないので、共有したいと思います。最近私はDDRESSUE について故障したハードドライブからNTFSパーティションの最初の1/3を回復し、回復したパーティションのセグメントをより小さなハードドライブに再構築することに成功しました。これにより、キャプチャされたファイルが救出されました（残りは失われました）。以下は、私がこれを行うために行った手順です。(間違いなくHACKSAWアプローチです!!)...
ソース ハード ドライブは、MBR ファイル テーブルを使用して NTFS でフォーマットされた 750 GB で構成されていました。ファイルのバックアップに数回使用しただけなので、ほとんどのファイルはドライブの先頭、約 160 GB にありました。家族の 1 人がハード ドライブ (外部にマウント) を床に落としてしまい、それ以降、正常に機能しなくなりました。ddrescue を使用して (苦労して)、ドライブの先頭の大部分を回復できました。物理的な損傷のため、プロセス中は頻繁にシャットダウンしました...
150GB の小さなラップトップ ハード ドライブ (外部にマウント) があり、そこに ddrescue データを直接抽出しました。あるいは、データをイメージ ファイルに抽出し、後でそのファイルをマウントすることもできましたが、データを直接ハード ドライブに書き込む方が簡単だと思いました。
救出の鍵となるのは、救出用ハード ドライブの MBR と NTFS ブート セクター データの両方を手動で編集することでした。そうしないと、ハード ドライブはどのオペレーティング システムでも認識されません。Linux で適切なプログラムが見つからなかったため、Windows に頼りました。Windows Support Tools という便利なパッケージがあります。現在はメンテナンスされていませんが、まだ役に立ちます (下のリンクを参照)。パーティションの編集に使用したツールは Disk Probe です。ハード ドライブの終了セクター値を確認してください (Ubuntu では fdisk -l を使用しました)
https://en.wikipedia.org/wiki/Windows_サポート_ツール
優れた計算機と創造性を駆使して、ハード ドライブを Windows のディスク プローブにロードしてマウントし、終了セクターの値を編集しました。MBR では、2 セットの値、つまり a) ハード ドライブ終了セクターと b) NTFS パーティション終了セクターを変更する必要がありました。NTFS ブート セクターでは、パーティションの合計セクター値を変更する必要がありました。いずれの場合も、数値は、より小さいハード ドライブの「サイズ」の減少に合わせて減少しました (終了セクターは 750 GB から 150 GB に変更されました)。これらの値を編集するには、[表示] タブをクリックします。
これは、NTFSブートセクタデータを編集しているディスクプローブの動作イメージです。
前述のフィールドを編集すると、Windows はパーティションを破損しているものの有効なパーティションとして認識しました。コマンド プロンプトに入り、破損したハード ドライブで Windows プログラム Chkdsk を実行しました (chdsk D:)。パーティションがファイルごとに復活するのを見るのは感動的でした。プログラムはパーティション テーブルを再構築し、破損したハード ドライブからコピーされたすべてのファイルを正常に再マップしました。範囲外のファイル (コピーされていないファイル) は見つからず、削除されました。
次の部分は、Windows がファイルを含めて 150 GB のハード ドライブを正常に再構築したため、理由がわかりません。それにもかかわらず、Windows はネイティブではハード ドライブのパーティションを開いてファイルを表示できませんでした (何らかのエラーがありました)。しかし、Ubuntu が助けてくれました。Ubuntu を再起動し、外付けハード ドライブをマウントすると、まったく問題なく、復元されたファイルがすべて表示されました。
大容量ハードドライブから小容量ハードドライブにファイルを復元するこの巧妙な方法が、私以外の誰かの役に立つことを願っています。乾杯!