LVMへの移行

Question

私の Ubuntu メディア サーバーのドライブはほぼいっぱいです。マシンにさらに 2 TB の容量を追加し、3.5 TB すべてを 1 つのドライブとして認識できるようにしたいと考えています。さらに複雑なことに、ドライブ上のデータを失ったり、プログラムを再構成したりすることは避けたいと考えています。

私の計画は、LVM を使用して新しいドライブにボリューム グループを作成し、dd を使用して古いドライブの内容をコピーすることでした。その後、古いドライブを消去してボリューム グループに追加する予定です。

この計画はうまくいくでしょうか？

私の最大の疑問は次のとおりです。 -dd は問題なくインストールを別のドライブにコピーできますか? ボリューム グループであっても? -dd は 1.5 TB ドライブを 2 TB ドライブにコピーし、残りのスペースを空けておくことができますか?

Answer 1

すでに LVM を使用している場合:

• 新しいディスクがマウントされ、LVM用にパーティション分割されていることを確認します（LVMビットを切り替えます）
• 新しいディスクにPVを作成します（pvcreate /dev/your-new-disk）
• VG を拡張して新しい PV を含めます ( vgextend your-volume-group /dev/your-new-disk)
• pvmove古いディスクから新しいディスクにデータを移動します。 は必要ありませんdd。 ( pvmove /dev/your-old-diskLVM に、古いディスクから他の使用可能なディスクにデータを移動するように強制します。)

まだ LVM を使用していない場合は:

• 新しいディスクに PV と VG を作成します。
• 新しい VG の新しい LV にデータをコピーします。ファイルシステムで使用できる場合は+
  を使用しますが、必要に応じてまたはを使用することもできます。dumprestorecpiotardd
• 古いディスクをフォーマットし、PV に変換して、VG に追加します。

---

^{以下は多少主観的な内容であり、LVM とは何の関係もありません。}

• ^{dump+ restore:}
  • ^{生のブロックデバイス上で操作するため、ソースatimeなどは影響を受けず、宛先ctimeなどを正しく設定できます。}
  • ^{すべてのハードリンクを保持し、すべての拡張属性、セキュリティ ポリシー、およびその他のファイルシステム固有のメタデータを保持できるほどファイルシステムの内部を十分に理解している必要があります。}
  • ^{ソースとコピー先のサイズは異なっていてもかまいません。使用中のデータのみがコピーされます。}
  • ^{最も速い方法のはずです。}
• ^{cpio/ tar/ rsync/ cp:}
  • ^{マウントされたファイルシステムで操作するため、ソースatimeが変更され、宛先はctime保持できず、inode 番号が変更されるなどします。}
  • ^{ハードリンクを保持するには、すべての既知の inode をメモリ内に保持する必要がありますが、正しく実行されるかどうかはわかりません。ツールは、拡張属性、セキュリティ ポリシー、およびその他のファイルシステム固有のメタデータを保持するために、ファイルシステムを十分に理解したり、権限を持っている場合とそうでない場合があります。
    (たとえば、ext4 はミリ秒未満のタイムスタンプをサポートしていますが、私が知る限り、これらのツールのいずれもそれを保持しません。)}
  • ^{ソースとコピー先のサイズは異なっていてもかまいません。指定されたデータのみがコピーされます。}
  • ^{システムコール( stat、、、、、、、、、、…)に多くの時間を費やしopendirます。readdirclosedirmkdiropenreadwriteclose}
• ^dd:
  • ^{生のブロック デバイスの正確なコピーです。}
  • ^{使用中かどうかに関係なく、すべてのブロックをコピーします。}
  • ^{一意であるべきもの (UUID など) を含め、すべてのファイルシステム構造を複製します。XFS
    の場合、両方を同じシステムに同時にマウントすることはできません (デフォルトでは)。}
  • ^{コピー中にサイズを変更することはできません。}
  • ^{ファイルシステムがあまりいっぱいでない場合は、比較的遅くなります。}