LVM Logical Volumes praktisch nutzen: Flexible Datenträgerverwaltung unter Linux

1. Warum LVM klassische Partitionen ablöst

LVM (Logical Volume Manager) ist eine zusätzliche Abstraktionsschicht zwischen physischen Speichermedien und Dateisystemen unter Linux. Statt eine Festplatte direkt in starre Partitionen mit fixer Größe zu unterteilen, fasst LVM eine oder mehrere Festplatten zu einem gemeinsamen Speicherpool zusammen, aus dem flexible Logical Volumes geschnitten werden. Wer schon einmal eine Partition vergrößern musste, während der Server produktiv lief, kennt das Problem: klassische Partitionstabellen erlauben das nur eingeschränkt, oft nur mit Neustart oder komplettem Neuaufbau des Dateisystems. LVM löst genau dieses Problem, indem es die logische Größe eines Volumes von der physischen Anordnung der Daten auf der Platte entkoppelt.

Für den Praxiseinsatz auf Servern, etwa bei Magento oder anderen PHP-Anwendungen mit wachsenden Datenbanken und Medienverzeichnissen, ist LVM fast schon Standard. Ein Logical Volume für /var/lib/mysql lässt sich online vergrößern, sobald der Datenbestand wächst, ohne Downtime und ohne Datenverlust. Auch Snapshots für konsistente Backups sind ohne LVM auf klassischen Partitionen praktisch nicht möglich. Wer produktive Linux-Server betreibt, sollte LVM daher von Anfang an einplanen, selbst wenn der initiale Speicherbedarf klein erscheint.

2. Physical Volume, Volume Group, Logical Volume

LVM basiert auf drei zentralen Objekten, die aufeinander aufbauen. Das Physical Volume (PV) ist eine komplette Festplatte oder Partition, die LVM als Rohmaterial zur Verfügung gestellt wird. Mehrere Physical Volumes werden zu einer Volume Group (VG) zusammengefasst, quasi einem gemeinsamen Topf aus Speicherplatz. Aus dieser Volume Group schneidet man dann beliebig viele Logical Volumes (LV), die sich wie normale Blockgeräte verhalten und mit einem Dateisystem formatiert werden.

Intern arbeitet LVM mit sogenannten Physical Extents, kleinen, gleich großen Speicherblöcken (standardmäßig 4 MiB), aus denen sich die gesamte Volume Group zusammensetzt. Ein Logical Volume besteht aus einer bestimmten Anzahl solcher Extents, die nicht zwingend zusammenhängend auf der Platte liegen müssen. Genau diese Indirektion macht das Vergrößern, Verkleinern und Verschieben von Logical Volumes im laufenden Betrieb möglich, ohne dass die Anwendung darüber etwas mitbekommt.

3. LVM einrichten: pvcreate, vgcreate, lvcreate

Der Aufbau einer LVM-Struktur folgt immer derselben Reihenfolge: zuerst wird die Festplatte als Physical Volume initialisiert, dann wird daraus eine Volume Group gebildet, und erst danach entstehen die eigentlichen Logical Volumes. Vor dem ersten Schritt muss die Platte oder Partition leer sein, LVM überschreibt beim Initialisieren den Anfang des Geräts mit eigenen Metadaten.

# Initialize a raw disk as an LVM physical volume
sudo pvcreate /dev/sdb

# Create a volume group from one or more physical volumes
sudo vgcreate vg_data /dev/sdb

# Create a logical volume with a fixed size inside the volume group
sudo lvcreate -L 50G -n lv_mysql vg_data

# Create a logical volume that uses all remaining free space
sudo lvcreate -l 100%FREE -n lv_media vg_data

# Verify the resulting device path
ls -l /dev/vg_data/lv_mysql

Nach lvcreate steht das Logical Volume als Blockgerät unter /dev/vg_data/lv_mysql zur Verfügung, parallel dazu existiert ein zweiter, stabilerer Pfad unter /dev/mapper/vg_data-lv_mysql. Beide Pfade zeigen auf dasselbe Gerät, in /etc/fstab sollte man aber immer die UUID des Dateisystems referenzieren, nicht den Gerätepfad, weil sich Gerätenamen bei Neustarts theoretisch ändern können.

4. Dateisystem erstellen und dauerhaft einhängen

Ein frisch erstelltes Logical Volume ist zunächst nur ein leeres Blockgerät, es braucht ein Dateisystem, bevor Daten geschrieben werden können. Mit mkfs.ext4 /dev/vg_data/lv_mysql oder mkfs.xfs /dev/vg_data/lv_media wird das gewünschte Dateisystem angelegt, die Wahl zwischen ext4 und XFS hängt vom Anwendungsfall ab, XFS skaliert bei sehr großen Dateien und parallelen Schreibzugriffen oft etwas besser. Danach lässt sich das Volume manuell mit mount einhängen, für den dauerhaften Betrieb gehört der Eintrag aber in /etc/fstab.

# /etc/fstab entry for an LVM logical volume, referenced by UUID
# Find the UUID first: blkid /dev/vg_data/lv_mysql

UUID=4f3a9c21-8b7e-4e2a-9d31-7a5c8e0f1a22  /var/lib/mysql  ext4  defaults,noatime  0  2
UUID=9a1e77d0-2c44-4b19-9e8a-1f6d3c5b7e90  /var/www/media  xfs   defaults,noatime  0  2

Die Option noatime verhindert, dass bei jedem Lesezugriff der Zugriffszeitstempel aktualisiert wird, was bei Datenbank-Workloads spürbar I/O-Last spart. Nach einer Änderung an /etc/fstab sollte man immer mit sudo mount -a testen, ob die Datei syntaktisch korrekt ist, bevor der nächste Neustart ansteht, ein Tippfehler in dieser Datei kann sonst dazu führen, dass das System beim Booten in den Notfallmodus fällt.

5. Logical Volumes online vergrößern

Der eigentliche Mehrwert von LVM zeigt sich, wenn ein Logical Volume im laufenden Betrieb vergrößert werden muss. Voraussetzung ist freier Speicherplatz in der zugehörigen Volume Group, entweder aus ungenutzten Extents oder durch das Hinzufügen einer weiteren Platte. Der Vorgang läuft in zwei Schritten ab: zuerst wird das Logical Volume selbst vergrößert, danach muss das Dateisystem im Inneren auf die neue Größe angepasst werden, beide Schritte lassen sich bei ext4 und XFS ohne Aushängen des Dateisystems durchführen.

# Extend the logical volume by 20 GiB
sudo lvextend -L +20G /dev/vg_data/lv_mysql

# Resize the ext4 filesystem to fill the new logical volume size
sudo resize2fs /dev/vg_data/lv_mysql

# For XFS, the filesystem must be mounted during the resize
sudo xfs_growfs /var/www/media

# Combine both steps for ext4 in a single command
sudo lvextend -r -L +20G /dev/vg_data/lv_mysql

Die Kombination aus lvextend mit dem Flag -r führt beide Schritte automatisch aus und erkennt selbstständig, ob ext4 oder XFS im Einsatz ist. Wichtig: LVM kann Logical Volumes zwar auch verkleinern, das ist bei XFS grundsätzlich nicht möglich, XFS unterstützt ausschließlich das Wachsen eines Dateisystems, niemals das Schrumpfen. Wer also plant, ein Volume später eventuell zu verkleinern, sollte von Anfang an ext4 wählen.

6. Snapshots für konsistente Backups

LVM-Snapshots erlauben es, den Zustand eines Logical Volumes zu einem bestimmten Zeitpunkt einzufrieren, ohne den Produktivbetrieb zu unterbrechen. Technisch legt LVM dafür ein neues, meist deutlich kleineres Logical Volume an, das nur die Änderungen (Copy-on-Write) gegenüber dem Original speichert. Für Backups bedeutet das: statt eine laufende MySQL-Datenbank während des Dumps zu blockieren, erstellt man einen Snapshot, mountet ihn separat und sichert von dort aus, während die eigentliche Datenbank weiterläuft.

# Create a snapshot with 5 GiB reserved for copy-on-write changes
sudo lvcreate -L 5G -s -n lv_mysql_snap /dev/vg_data/lv_mysql

# Mount the snapshot read-only for a consistent backup
sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_data/lv_mysql_snap /mnt/snap

# Run the backup against the frozen snapshot
sudo tar -czf /backup/mysql-$(date +%F).tar.gz -C /mnt/snap .

# Clean up after the backup completed
sudo umount /mnt/snap
sudo lvremove -f /dev/vg_data/lv_mysql_snap

Ein Snapshot ist kein Ersatz für ein vollständiges Backup, er lebt in derselben Volume Group wie das Original und ist bei einem Totalausfall der Platte ebenfalls verloren. Wichtig ist außerdem, den reservierten Speicher für Copy-on-Write-Änderungen ausreichend groß zu wählen, läuft dieser Bereich während des Backups voll, wird der Snapshot automatisch ungültig. Für Datenbanken mit hoher Schreiblast sollte der Snapshot daher zügig erstellt, gesichert und wieder entfernt werden.

7. Volume Group um neue Platten erweitern

Wächst der Speicherbedarf über die Kapazität der bestehenden Volume Group hinaus, lässt sich eine weitere physische Platte einfach hinzufügen. Dazu wird die neue Platte zunächst mit pvcreate als Physical Volume initialisiert und anschließend mit vgextend der bestehenden Volume Group zugeordnet. Ab diesem Moment steht der zusätzliche Speicherplatz für neue oder bestehende Logical Volumes zur Verfügung, ganz ohne die Anwendung zu stoppen.

Ein Nachteil dieser Flexibilität: Verteilt sich ein Logical Volume über mehrere physische Platten, hängt die Ausfallsicherheit von jeder einzelnen Platte ab, fällt eine davon aus, kann das gesamte Volume beschädigt sein. Für produktive Systeme kombiniert man LVM daher häufig mit RAID als darunterliegende Schicht, RAID sorgt für Redundanz auf Blockebene, LVM darüber für die flexible Aufteilung des resultierenden Speicherplatzes. pvmove erlaubt es zudem, Daten im laufenden Betrieb von einer Platte auf eine andere zu verschieben, etwa um eine alte Festplatte aus der Volume Group zu entfernen.

8. Monitoring und Troubleshooting

Der Überblick über bestehende LVM-Strukturen gelingt mit drei Kommandos, die jeweils eine der drei Ebenen anzeigen: pvs für Physical Volumes, vgs für Volume Groups und lvs für Logical Volumes. Alle drei Befehle liefern kompakte Tabellen mit Größe, freiem Speicherplatz und Zuordnung. Für detailliertere Informationen, etwa die genaue Extent-Verteilung eines Logical Volumes, liefert lvdisplay eine ausführlichere Ansicht.

# Overview of all three LVM layers
sudo pvs   # physical volumes: size, free space, VG assignment
sudo vgs   # volume groups: total size, free extents
sudo lvs   # logical volumes: size, attached volume group

# Detailed view of a single logical volume
sudo lvdisplay /dev/vg_data/lv_mysql

# Common troubleshooting: duplicate PV UUID after disk clone
sudo pvscan --cache
sudo vgimportclone --basevgname vg_data_clone /dev/sdc

Ein typisches Problem in der Praxis entsteht, wenn eine Festplatte per dd oder als VM-Snapshot geklont wird: LVM erkennt anhand der UUID zwei identische Physical Volumes und verweigert unter Umständen den Zugriff, um Datenkorruption zu vermeiden. vgimportclone löst dieses Problem, indem es der geklonten Volume Group und ihren Physical Volumes neue, eindeutige UUIDs zuweist. Wer regelmäßig mit LVM arbeitet, sollte pvs, vgs und lvs auch in eigenes Monitoring-Tooling integrieren, um Kapazitätsengpässe frühzeitig zu erkennen.

9. LVM im direkten Vergleich

Ob LVM, eine klassische Partition oder RAID die richtige Wahl ist, hängt vom konkreten Anwendungsfall ab. Die folgende Übersicht zeigt die wichtigsten Unterschiede in der Praxis.

In der Praxis zeigt sich: LVM kostet beim initialen Setup einen zusätzlichen Schritt, gewinnt diesen Aufwand aber bei jeder Größenänderung im laufenden Betrieb um ein Vielfaches zurück. Nur wenn absolute Einfachheit oder maximale Performance ohne jede Indirektionsebene gefragt ist, etwa bei sehr kleinen, unveränderlichen Systemen, lohnt sich der Verzicht auf LVM.

10. Zusammenfassung

LVM verwandelt starre Partitionen in einen flexiblen Speicherpool, aus dem sich Logical Volumes je nach Bedarf schneiden, vergrößern und mit Snapshots absichern lassen. Die drei Grundbegriffe Physical Volume, Volume Group und Logical Volume bauen aufeinander auf und bilden zusammen die Abstraktionsschicht, die produktive Linux-Server heute kaum noch missen wollen.

Wer LVM von Anfang an einplant, spart sich spätere Migrationen auf ein flexibleres Setup. Die Kombination aus Online-Vergrößerung, Snapshots für Backups und der Möglichkeit, jederzeit weitere Platten in eine Volume Group aufzunehmen, macht LVM zum Standardwerkzeug für Datenbank- und Medienverzeichnisse gleichermaßen.

11. FAQ: LVM Logical Volumes praktisch nutzen