dd
次のコマンドを使用して、リモートxfsディスクを別の場所に複製しようとします。
ssh root@source_ip "dd if=/dev/vda2 bs=16M conv=noerror,sync status=progress " | sudo dd of=/dev/nvme1n1 bs=16M conv=noerror,sync status=progress
ただし、次のエラー メッセージが表示されます。
828895133696 bytes (829 GB) copied, 39610.432258 s, 20.9 MB/s
1288490188800 bytes (1.3 TB) copied, 64529.849170 s, 20.0 MB/s
dd: error writing '/dev/nvme1n1': No space left on device
ソースディスクは1TB、ターゲットディスクは1.2TBです。
この場合、ディスク間のレプリケーションを実行できない理由を説明できる人はいますか?ありがとうございます!
元のディスクから削除されたファイルを回復しようとしていますが、DDがこの状況に適した唯一のツールであるかどうかはわかりません。
ベストアンサー1
比較するこの回答(bs=1K
ここでコメントを使用):
dd
オリジナルのテープデバイスで動作するように設計された古くて気まぐれなプログラムです。 1kBブロックを読み取るように指示すると、ブロックを読み取ろうとします。読み取りで1024バイト未満を返すと、それはすべてです。
conv=sync
読書量が期待以下になるとdd
重要になります。あなたの場合、パイプはいつでもssh
チャンク16M
全体をbs=16M
ローカルに渡すことはできません。dd
一度に読む、conv=sync
「欠落している」データを0(NULバイト)で埋めます。しかし、実際のデータはありませんでした。dd
ローカルが次のブロックを読み取ろうとすると、ローカルが欠落していると思われるコンテンツが渡されます。
実際、ネイティブはdd
ストリームのランダム(-ish)位置にゼロを注入します。明確でない場合は、以下を強調します。これによりデータが破損し、結果として「コピー」が事実上役に立たなくなります。。
conv=noerror,sync
リモート(読み取り)側での使用も間違っている可能性があります。この答えを比較してください:dd conv=sync,noerror
効果は何ですか?正しく使用するには、どのように機能するかを実際に理解する必要があります。
使用しているロケールには適していませんdd
conv=noerror,sync
。削除または追加iflag=fullblock
(サポートされている場合)正直に言うと、conv=noerror,sync iflag=fullblock
パイプから読み取るときにこれらのオプションを使用しないよりも、どのような利点があるのかわかりません。dd