Migration zu LVM

Question

Das Laufwerk auf meinem Ubuntu-Medienserver ist fast voll. Ich möchte die Kapazität des Rechners um weitere 2 TB erweitern und möchte, dass alle 3,5 TB als ein einziges Laufwerk erkannt werden. Um es noch komplizierter zu machen, möchte ich keine Daten auf dem Laufwerk verlieren oder Programme neu konfigurieren müssen.

Mein Plan war, mit LVM eine Volume-Gruppe auf dem neuen Laufwerk zu erstellen und mit dd den Inhalt des alten Laufwerks zu kopieren. Dann möchte ich das alte Laufwerk löschen und es der Volume-Gruppe hinzufügen.

Wird dieser Plan funktionieren?

Meine größten Fragen sind: - Kann dd meine Installation problemlos auf ein anderes Laufwerk kopieren? Auch wenn es sich um eine Volume-Gruppe handelt? - Kann dd ein 1,5-TB-Laufwerk auf ein 2-TB-Laufwerk kopieren und den verbleibenden Speicherplatz frei lassen?

Answer 1

Wenn Sie LVM bereits verwenden:

• Stellen Sie sicher, dass die neue Festplatte für LVM gemountet und partitioniert ist (LVM-Bit umschalten).
• Erstellen Sie ein PV auf der neuen Festplatte ( pvcreate /dev/your-new-disk)
• Erweitern Sie Ihre VG um das neue PV ( vgextend your-volume-group /dev/your-new-disk)
• pvmoveIhre Daten von der alten Festplatte auf die neue. Kein Bedarf dd. ( pvmove /dev/your-old-diskzwingt LVM, die Daten von der alten Festplatte auf eine andere verfügbare Festplatte zu verschieben.)

Wenn Sie LVM noch nicht verwenden:

• Erstellen Sie ein PV und VG auf der neuen Festplatte.
• Kopieren Sie Ihre Daten in ein neues LV in der neuen VG.
  Ich würde dump+ verwenden restore, falls für Ihr Dateisystem verfügbar, aber Sie können auch oder cpioverwenden , wenn Sie möchten.tardd
• Formatieren Sie die alte Festplatte, machen Sie ein PV daraus und fügen Sie es dem VG hinzu.

---

^{Das Folgende ist etwas subjektiver Natur und hat nichts mit LVM zu tun.}

• ^{dump+ restore:}
  • ^{Arbeiten Sie auf dem Rohblockgerät, sodass Quelle atimeusw. nicht beeinträchtigt werden und Ziel ctimeusw. korrekt eingestellt werden können.}
  • ^{Behält alle Hardlinks bei und sollte die internen Vorgänge des Dateisystems gut genug verstehen, um alle erweiterten Attribute, Sicherheitsrichtlinien und andere dateisystemspezifische Metadaten beizubehalten.}
  • ^{Quelle und Ziel können unterschiedliche Größen haben; es werden nur die Daten kopiert, die gerade verwendet werden.}
  • ^{Sollte die schnellste Methode sein.}
• ^{cpio/ tar/ rsync/ cp:}
  • ^{Arbeiten Sie mit dem gemounteten Dateisystem, sodass die Quelle atimegeändert wird, das Ziel ctimenicht beibehalten werden kann, Inode-Nummern sich ändern usw.}
  • ^{Um Hardlinks zu erhalten, müssen alle bekannten Inodes im Speicher bleiben. Dies kann richtig oder falsch erfolgen. Das Tool versteht das Dateisystem möglicherweise nicht gut genug oder verfügt nicht über die erforderlichen Berechtigungen, um erweiterte Attribute, Sicherheitsrichtlinien und andere dateisystemspezifische Metadaten zu erhalten.
    (Ext4 unterstützt beispielsweise Zeitstempel unter einer Millisekunde, aber meines Wissens bewahrt keines dieser Tools sie auf.)}
  • ^{Quelle und Ziel können unterschiedliche Größen haben; kopiert nur angegebene Daten.}
  • ^{Verbringt viel Zeit mit Systemaufrufen ( stat, opendir, readdir, closedir, mkdir, open, read, write, close, …).}
• ^dd:
  • ^{Ist eine exakte Kopie des Raw-Block-Geräts.}
  • ^{Kopiert alle Blöcke, unabhängig davon, ob sie verwendet werden oder nicht.}
  • ^{Dupliziert alle Dateisystemstrukturen, einschließlich der Dinge, die eindeutig sein sollten (wie UUID).
    Beide können (standardmäßig) nicht gleichzeitig auf demselben System gemountet werden, wenn es sich um XFS handelt.}
  • ^{Die Größe kann während des Kopierens nicht geändert werden.}
  • ^{Vergleichsweise langsam, wenn das Dateisystem nicht sehr voll wäre.}