# LVM Praxisguide: Dynamisches Storage-Management

TL;DR / Management Summary LVM ist der Industriestandard für flexibles Storage-Management unter Linux. Es ermöglicht das Bündeln mehrerer physikalischer Disks zu einem Pool und das dynamische Zuweisen von Speicherplatz an “Partitionen” (Logical Volumes). Die größten Vorteile: Online-Resizing (Vergrößern ohne Neustart) und Snapshots für Backup-Konsistenz. In diesem Guide lernen wir die CLI-Befehle, die jeder Admin beherrschen muss.

# 1. Einführung & Architektur

Die drei Ebenen des LVM.

LVM ist wie eine Abstraktionsschicht zwischen Hardware und Betriebssystem.

# Die Hierarchie (Mermaid)

graph TD
    subgraph "Hardware Layer"
        A[Disk 1 /dev/sdb] --- B[Partition /dev/sdb1]
        C[Disk 2 /dev/sdc] --- D[Partition /dev/sdc1]
    end
    subgraph "LVM Layer"
        B --> E[Physical Volume PV]
        D --> F[Physical Volume PV]
        E --> G[Volume Group VG 'data_pool']
        F --> G
        G --> H[Logical Volume LV 'web_data']
        G --> I[Logical Volume LV 'backup_data']
    end
    subgraph "OS Layer"
        H --> J[Filesystem: /var/www]
        I --> K[Filesystem: /mnt/backup]
    end

# 2. Initiales Setup

Vom leeren Datenträger zum Dateisystem.

# Schritt 1: Physical Volume (PV) vorbereiten

Initialisiert die Disk für die Nutzung mit LVM.

sudo pvcreate /dev/sdb

# Schritt 2: Volume Group (VG) erstellen

Erstellt einen Pool namens vg_data und fügt die Disk hinzu.

sudo vgcreate vg_data /dev/sdb

# Schritt 3: Logical Volume (LV) anlegen

Erstellt eine “virtuelle Partition” mit 50GB Größe.

sudo lvcreate -L 50G -n lv_projects vg_data

# Schritt 4: Dateisystem erstellen & Mounten

sudo mkfs.ext4 /dev/vg_data/lv_projects
sudo mount /dev/vg_data/lv_projects /mnt/projects

# 3. Storage-Erweiterung im Betrieb

Keine Downtime, keine Panik.

Wenn die Volume Group voll ist, fügen wir einfach eine neue Disk hinzu.

# 1. Neue Disk initialisieren
pvcreate /dev/sdc

# 2. Bestehende VG erweitern
vgextend vg_data /dev/sdc

# 3. LV vergrößern (nutzt den neuen Platz)
lvextend -L +100G /dev/vg_data/lv_projects

# 4. Filesystem online anpassen (Ext4)
resize2fs /dev/vg_data/lv_projects

# 4. LVM Snapshots

Backups ohne Dateisperren.

Ein Snapshot ist ein “Point-in-Time” Abbild eines LVs. Er verbraucht am Anfang fast keinen Platz, wächst aber mit jeder Änderung am Original-LV.

# Erstellt einen Snapshot von 'lv_projects' mit 5GB Puffer
lvcreate -L 5G -s -n projects_snap /dev/vg_data/lv_projects

# Jetzt kann der Snapshot gemountet und gesichert werden
mount /dev/vg_data/projects_snap /mnt/backup_source

# 5. Day-2 Operations: Status & Wartung

Den Durchblick behalten.

# Schnelle Check-Befehle

• pvs: Liste aller Physical Volumes.
• vgs: Liste aller Volume Groups.
• lvs: Liste aller Logical Volumes.

# Detaillierte Infos

sudo vgdisplay vg_data

Achten Sie auf “Free PE / Size” – das ist der Platz, den Sie noch an LVs verteilen können.

# 6. Troubleshooting & “War Stories”

Wenn die Metadaten streiken.

# Story 1: “Die verschwundene VG”

Symptom: Nach einem Hardware-Wechsel wird die VG nicht mehr gefunden. Ursache: Die PV-Signaturen sind da, aber die VG ist nicht aktiviert. Lösung: vgscan gefolgt von vgchange -ay (Activate Yes).

# Story 2: “Das volle Snapshot-LV”

Symptom: Ein Server wird extrem langsam und ein LV lässt sich nicht mehr mounten. Ursache: Ein automatisches Backup-Skript hat einen Snapshot erstellt, ihn aber nicht gelöscht. Der Puffer lief voll. Lösung: Snapshot löschen: lvremove /dev/vg_data/projects_snap. Prüfen Sie regelmäßig mit lvs, ob noch Snapshots aktiv sind.

# 7. Fazit & Empfehlung

LVM ist Pflicht für jeden Server. Es schützt Sie davor, das System neu aufsetzen zu müssen, nur weil eine Partition falsch geplant wurde.

• Tipp: Benennen Sie VGs und LVs sinnvoll (z.B. vg_system, lv_root, lv_swap). Vermeiden Sie Standardnamen wie VolGroup00.
• Thin Provisioning: Wenn Sie viel Storage-Overcommitment brauchen, schauen Sie sich LVM-Thin an (Standard in Proxmox).

# Anhang: Cheatsheet