LVM unter Linux erklärt: Warum ich meinen Server damit auf SSD und HDD aufteile

Eigentlich wollte ich meinem Server nur etwas mehr Geschwindigkeit gönnen. Bisher liefen Betriebssystem, Datenbanken, Docker und meine großen Datenbestände gemeinsam auf zwei 12-TB-Festplatten im RAID1.

Für Nextcloud-Dateien, Fotos, Videos und andere große Datenmengen funktioniert das wunderbar. Bei vielen kleinen Dateien sieht die Sache allerdings anders aus.

Das habe ich zuletzt bei einem Nextcloud-Update ziemlich deutlich gemerkt. Das Backup des Nextcloud-Updaters brachte die Festplatten auf nahezu 100 Prozent Auslastung, obwohl nur wenige Megabyte pro Sekunde übertragen wurden.

Die Lösung war eine zusätzliche 1-TB-SATA-SSD.

Damit stellte sich direkt die nächste Frage: Wie teile ich den Speicher sinnvoll auf, ohne das komplette System neu installieren zu müssen?

Hier kommt LVM ins Spiel.

Was ist LVM überhaupt?

LVM steht für Logical Volume Manager und ist unter Linux eine Möglichkeit, Speicher flexibler zu verwalten als mit klassischen festen Partitionen.

Bei einer normalen Partitionierung teilt man eine Festplatte beispielsweise in mehrere feste Bereiche auf. Ist eine dieser Partitionen irgendwann voll, während auf einer anderen noch reichlich Platz vorhanden ist, wird das Verschieben des Speicherplatzes schnell umständlich.

LVM setzt eine zusätzliche Verwaltungsebene zwischen Datenträger und Dateisystem.

• Physical Volume (PV): der tatsächliche Datenträger oder eine Partition
• Volume Group (VG): ein gemeinsamer Speicherpool
• Logical Volume (LV): daraus erstellte virtuelle Partitionen

Vereinfacht gesagt funktioniert LVM also nach dem Prinzip:

Datenträger → Speicherpool → Logical Volumes

Physical Volume: Der tatsächliche Speicher

Am Anfang steht ein sogenanntes Physical Volume, kurz PV.

Bei meiner neuen 1-TB-Kingston-SSD wird dafür beispielsweise die dritte Partition verwendet:

/dev/sdb3

Diese Partition wird LVM zur Verfügung gestellt und bildet anschließend die Grundlage für die Volume Group.

Volume Group: Der Speicherpool

Ein oder mehrere Physical Volumes werden zu einer sogenannten Volume Group zusammengefasst.

Bei meiner SSD heißt diese Volume Group:

vgssd

Man kann sich eine Volume Group wie einen großen Speicherpool vorstellen. Aus diesem Pool werden anschließend die einzelnen Logical Volumes angelegt.

Mein aktueller Aufbau

Auf meiner neuen 1-TB-SATA-SSD habe ich mehrere Logical Volumes angelegt:

• vgssd-root – 60 GB – /
• vgssd-var – 50 GB – /var
• vgssd-varlib – 150 GB – /var/lib
• vgssd-opt – 180 GB – /opt
• vgssd-home – 100 GB – /home
• vgssd-www – 100 GB – /var/www
• vgssd-matrix – 100 GB – /matrix
• vgssd-swap – 16 GB – Swap

Für Linux verhalten sich diese Logical Volumes anschließend fast wie normale Partitionen.

Warum das bei meinem Server praktisch ist

Neben der SSD besitzt mein Server weiterhin zwei große 12-TB-Festplatten im RAID1.

Dort bleibt vor allem das große Datenverzeichnis /srv. Darunter liegen beispielsweise die eigentlichen Nextcloud-Dateien und andere große Datenbestände.

Genau dafür eignen sich klassische Festplatten weiterhin hervorragend: viel Speicherplatz zu vergleichsweise niedrigen Kosten.

Auf die SSD sind dagegen Bereiche gewandert, bei denen kurze Zugriffszeiten wichtig sind:

• Debian selbst
• MariaDB
• PostgreSQL
• Docker
• Nextcloud- und WordPress-Code
• Matrix
• Redis
• Meilisearch
• /opt
• /var/lib

Damit bleiben große Medien und Nutzerdaten auf dem HDD-RAID, während Anwendungen und Datenbanken von der Geschwindigkeit der SSD profitieren.

Speicher später flexibel verteilen

Einer der größten Vorteile von LVM ist für mich die Möglichkeit, Speicher später neu zu verteilen.

Ich habe auf der SSD bewusst nicht den gesamten Platz vergeben. Ein Teil bleibt innerhalb der Volume Group vgssd frei.

Sollte beispielsweise /var/lib mit derzeit 150 GB irgendwann zu klein werden, kann ich diesem Logical Volume zusätzlichen Speicher aus dem freien Pool geben.

Dafür muss weder Debian neu installiert noch die komplette SSD neu partitioniert werden.

LVM hilft auch bei Migrationen

Vor dem SSD-Umbau lagen die einzelnen Systembereiche meines Servers ebenfalls auf LVM-Volumes des HDD-RAIDs.

• vg0-root
• vg0-var
• vg0-varlib
• vg0-opt
• vg0-www
• vg0-matrix
• vg0-home
• vg0-srv

Nach der Migration befinden sich die Systembereiche auf der SSD. Das große Datenvolume /srv bleibt dagegen auf dem HDD-RAID.

Für Nextcloud ändert sich dadurch beispielsweise nichts. Der Programmcode liegt weiterhin unter /var/www/nextcloud, während die eigentlichen Nutzerdaten weiterhin unter /srv liegen.

Nur der physische Speicher darunter hat sich geändert.

LVM ist kein RAID und kein Backup

LVM, RAID und Backup erfüllen unterschiedliche Aufgaben.

• RAID1 schützt bei meinem Server vor dem Ausfall einer einzelnen HDD.
• LVM organisiert und verteilt Speicherplatz.
• Backups schützen vor Datenverlust.

LVM sorgt also nicht automatisch für Redundanz. Fällt meine einzelne SSD aus, sind auch die darauf liegenden Logical Volumes betroffen. Ein externes Backup bleibt deshalb weiterhin wichtig.

Fazit

Für einen normalen Desktop-PC ist LVM nicht zwingend notwendig. Auf einem Server mit mehreren Diensten und unterschiedlichen Speicheranforderungen kann es dagegen sehr praktisch sein.

Bei meinem Server kann ich damit schnellen SSD-Speicher für Anwendungen und Datenbanken mit einem großen HDD-RAID für Massendaten kombinieren.

Im nächsten Teil schauen wir uns an, wie Physical Volumes, Volume Groups und Logical Volumes praktisch angelegt werden.

LVM unter Linux – die Serie

• Teil 1: Was ist LVM und welche Vorteile hat es?
• Teil 2: LVM einrichten und Logical Volumes erstellen
• Teil 3: LVM-Volumes vergrößern und verkleinern
• Teil 4: Alte LVM-Volumes sicher löschen und Speicher freigeben