LVM Volumes im laufenden Betrieb erweitern und verkleinern — Praxis-Guide

LVM Volumes online erweitern und verkleinern ohne Neustart. Schritt-für-Schritt mit lvextend, lvreduce, resize2fs und praktischen Beispielen für Proxmox und Linux Server.

Du kennst das Problem: Die /var-Partition ist voll, dein Docker-Host schreit nach mehr Speicher, oder dein Proxmox Homelab braucht dringend zusätzlichen Platz. Zum Glück nutzt du LVM — aber wie erweitert man ein Volume, während das System läuft?

In diesem Guide zeige ich dir, wie du LVM-Volumes online erweitern (ohne Neustart!), sicher verkleinern und dabei häufige Fehler vermeidest. Mit konkreten Befehlen, Proxmox-spezifischen Tipps und echten Praxisbeispielen.

Warum LVM? Die Vorteile auf einen Blick#

Logical Volume Manager (LVM) ist der Standard für flexible Storage-Verwaltung unter Linux. Anders als klassische Partitionen lassen sich LVM-Volumes nachträglich anpassen — perfekt fürs Homelab!

Die wichtigsten Vorteile:

  • ✅ Online-Erweiterung: Volumes vergrößern ohne Downtime
  • ✅ Flexible Aufteilung: Speicher zwischen Volumes verschieben
  • ✅ Snapshots: Backups im laufenden Betrieb
  • ✅ Mehrere Disks: Kombiniere physische Laufwerke zu einem Volume

Wann brauchst du Resize?

  • 🚨 /var ist voll (Docker-Container, Logs)
  • 🚨 VM-Disk erweitert, aber im Gastsystem nicht sichtbar
  • 🚨 Home-Verzeichnis braucht mehr Platz
  • 🚨 Falsche Partitionierung bei Installation

LVM-Basics: Die drei Schichten verstehen#

Bevor wir loslegen, musst du die LVM-Architektur verstehen. LVM arbeitet in drei Ebenen:

┌─────────────────────────────────────┐
│   Logical Volume (LV)               │  ← Das siehst du: /dev/vg-name/lv-name
│   z.B. /dev/vg-data/var             │     Wird gemountet als /var
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│   Volume Group (VG)                 │  ← Pool aus einem oder mehreren PVs
│   z.B. vg-data                      │     Verwaltet den Speicher-Pool
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│   Physical Volume (PV)              │  ← Physische Disk/Partition
│   z.B. /dev/sda5, /dev/sdb1         │     Echte Hardware-Layer
└─────────────────────────────────────┘

Die wichtigsten Begriffe:

Begriff Bedeutung Beispiel

PV (Physical Volume) Physische Disk oder Partition /dev/sda5 VG (Volume Group) Pool aus einem oder mehreren PVs vg-data PE (Physical Extent) Kleinste Speichereinheit (meist 4 MB) -

Status prüfen:

# Alle drei Ebenen auf einen Blick
pvs    # Physical Volumes
vgs    # Volume Groups
lvs    # Logical Volumes

# Detaillierte Infos
pvdisplay
vgdisplay
lvdisplay

LVM erweitern im laufenden Betrieb (Online-Resize)#

Der Traum: Volume vergrößern, ohne das System herunterzufahren. Mit LVM kein Problem! Der Prozess läuft in drei Schritten:

  1. Physical Volume erweitern (wenn die Disk größer wurde)
  2. Logical Volume erweitern
  3. Filesystem anpassen

Schritt 1: Physical Volume erweitern (nach Disk-Vergrößerung)#

Du hast in Proxmox, VMware oder am RAID-Controller die Disk vergrößert? Dann muss LVM das erstmal mitbekommen.

Variante A: Extended Partition neu anlegen (MBR)

Bei alten MBR-basierten Systemen musst du die Extended Partition neu anlegen, um den zusätzlichen Platz nutzbar zu machen:

# ACHTUNG: Dieser Prozess ist heikel! Backup vorher empfohlen.
fdisk /dev/sda

# In fdisk:
# 1. Extended Partition (meist 2) löschen
Command (m for help): d
Partition number (1-5): 2

# 2. Neue Extended Partition mit Standardwerten anlegen
Command (m for help): n
Select (default p): e
Partition number: 2
First sector: [ENTER für Standard]
Last sector: [ENTER für Standard]

# 3. Neue Logical Partition (5) anlegen
Command (m for help): n
Select (default p): l
First sector: [ENTER für Standard]
Last sector: [ENTER für Standard]

# 4. Partition-Typ auf LVM setzen
Command (m for help): t
Partition number: 5
Hex code: 8e

# 5. Änderungen schreiben
Command (m for help): w

WICHTIG: Dieser Schritt löscht KEINE Daten, aber schreib-Fehler können das System unbootable machen. Backup first!

Partition-Tabelle neu einlesen:

partprobe /dev/sda
# oder bei Fehlern:
partx -u /dev/sda

Physical Volume resizen:

pvresize /dev/sda5

Variante B: GPT-Partition erweitern (moderner Ansatz)

Bei GPT-basierten Systemen (Standard bei UEFI) ist es einfacher:

# Partition automatisch erweitern
growpart /dev/sda 5

# PV resizen
pvresize /dev/sda5

Status prüfen:

pvs
# Sollte jetzt die neue Größe zeigen:
# PV         VG      Fmt  Attr PSize   PFree
# /dev/sda5  vg-data lvm2 a--  100,00g 50,00g

Schritt 2: Logical Volume erweitern#

Jetzt kommt der einfache Teil. Du hast drei Möglichkeiten:

Option 1: Feste Größe hinzufügen

lvextend -L +20G /dev/vg-data/var

Option 2: Kompletten freien Speicher nutzen

lvextend -l +100%FREE /dev/vg-data/var

Option 3: Auf absolute Größe erweitern

lvextend -L 100G /dev/vg-data/var

Schritt 3: Filesystem erweitern#

Das Logical Volume ist größer, aber das Filesystem weiß das noch nicht. Das musst du jetzt anpassen:

Für ext4/ext3 (häufigster Fall):

resize2fs /dev/mapper/vg--data-var

Für XFS:

xfs_growfs /

All-in-One mit lvextend:

# Seit LVM 2.02 gibt's die --resizefs Option
lvextend -l +100%FREE --resizefs /dev/vg-data/var

Prüfen, ob’s geklappt hat:

df -h
# /dev/mapper/vg--data-var sollte jetzt größer sein

Praktisches Beispiel: Docker-Host erweitern#

Dein Docker auf Proxmox läuft voll? So erweiterst du /var im laufenden Betrieb:

# 1. Proxmox: VM-Disk von 50 GB auf 100 GB erweitern (WebUI)
# 2. Im Guest: PV resizen
pvresize /dev/sda5

# 3. LV erweitern (hier: +50 GB)
lvextend -l +100%FREE --resizefs /dev/vg-docker/var

# 4. Prüfen
df -h | grep var
# Filesystem             Size  Used Avail Use% Mounted on
# /dev/mapper/vg-docker-var  100G   45G   52G  47% /var

Das war’s! Keine Downtime, Docker läuft weiter, Problem gelöst.

LVM verkleinern (mit Downtime)#

Das Verkleinern ist riskanter als Erweitern, weil du Datenverlust riskierst, wenn du dich verrechnet. Backup ist PFLICHT!

Warum verkleinern?

  • /home ist überdimensioniert, /var braucht Platz
  • VM-Disk soll schrumpfen (z.B. vor Migration)
  • Storage-Layout optimieren

Sicherer Ablauf zum Verkleinern#

Voraussetzung: Das Filesystem muss unmountet sein. Root-Partitionen können nur von Live-System/Rescue verkleinert werden.

Schritt-für-Schritt:

# 1. Filesystem unmounten
umount /home

# 2. Filesystem-Check (ZWINGEND!)
e2fsck -f /dev/mapper/vg-data-home

# 3. Filesystem verkleinern (ERST das Filesystem!)
resize2fs /dev/mapper/vg-data-home 70G

# 4. Logical Volume verkleinern (DANN das LV!)
lvreduce -L 70G /dev/vg-data-home
# Achtung: -L (absolut), nicht -L - (relativ)!

# 5. Erneuter Check
e2fsck -f /dev/mapper/vg-data-home

# 6. Mounten
mount /home

KRITISCH: Du musst das Filesystem VOR dem LV verkleinern! Umgekehrt würdest du Daten abschneiden.

Speicher zwischen Volumes verschieben#

Klassischer Use-Case: /home hat 100 GB, braucht aber nur 50 GB. /var ist voll.

# 1. Home verkleinern (siehe oben)
umount /home
e2fsck -f /dev/mapper/vg-data-home
resize2fs /dev/mapper/vg-data-home 50G
lvreduce -L 50G /dev/vg-data-home
mount /home

# 2. Prüfen, ob Speicher frei ist
vgs
# VG      #PV #LV #SN Attr   VSize   VFree
# vg-data   1   3   0 wz--n- 200,00g 50,00g

# 3. Var erweitern (online möglich!)
lvextend -L +50G --resizefs /dev/vg-data/var

# 4. Status prüfen
df -h

Pro-Tipp: Du kannst auch erstmal nur das LV verkleinern und den Speicher für später reservieren:

# 10 GB von home nehmen, aber noch nicht zuweisen
lvreduce -L -10G /dev/vg-data-home
# → Diese 10 GB bleiben in der VG als "VFree"

Proxmox-spezifische Tipps#

In Proxmox VMs/CTs läuft LVM oft zweistufig: Host und Guest.

VM-Disk erweitern (Host-Seite)#

In der Proxmox WebUI:

  1. VM auswählen → Hardware → Hard Disk auswählen
  2. “Disk Action” → “Resize disk”
  3. Zusätzliche GB eingeben (z.B. +50)

Oder per CLI:

# Auf dem Proxmox Host
qm resize <VM-ID> scsi0 +50G

Wichtig: Das vergrößert nur die virtuelle Disk! Im Guest musst du noch LVM resizen (siehe oben).

Container (LXC) mit LVM-Thin-Provisioning#

Bei LXC-Containern auf LVM-Thin funktioniert’s ähnlich:

# Auf dem Proxmox Host
pct resize <CT-ID> rootfs +20G

Im Container ist keine weitere Aktion nötig — das Filesystem wird automatisch erweitert.

Proxmox Host selbst erweitern#

Der Proxmox Host nutzt meist pve/root und pve/data:

# Nach Disk-Erweiterung im Hypervisor/RAID
pvresize /dev/sda3

# Freien Speicher anzeigen
vgs pve

# Root-Volume erweitern (für /var/lib/vz)
lvextend -l +100%FREE --resizefs /dev/pve/root

Achtung: pve/data ist ein Thin-Pool, den resized man anders:

lvextend -L +50G /dev/pve/data

Troubleshooting: Häufige Fehler und Lösungen#

Fehler: “Can’t resize online”#

Symptom:

resize2fs: Operation not supported while filesystem is mounted

Ursache: Online-Resize wird nicht unterstützt (z.B. beim Verkleinern).

Lösung:

# Filesystem unmounten
umount /home
# Dann resize2fs ausführen

Fehler: “No space left on device” trotz resize#

Symptom: LV und Filesystem sind größer, aber df -h zeigt alte Größe.

Ursache: Falsche Device-Pfade oder Filesystem nicht resized.

Lösung:

# Prüfe LV-Status
lvdisplay /dev/vg-data/var

# Prüfe Filesystem-Status
df -h | grep var

# Manuell resizen
resize2fs /dev/mapper/vg--data-var

# Notfalls remounten
umount /var && mount /var

Fehler: “Physical volume not found”#

Symptom:

pvresize: Physical volume "/dev/sda5" not found

Ursache: Partition-Tabelle noch nicht neu eingelesen.

Lösung:

partprobe /dev/sda
# oder
partx -u /dev/sda

# Kernel-Log prüfen
dmesg | tail -n 20

Warnung: “–resizefs only works with ext4”#

Symptom:

lvextend: --resizefs is only supported for ext2/ext3/ext4 filesystems

Ursache: Du nutzt XFS, Btrfs oder ein anderes Filesystem.

Lösung:

# Für XFS
lvextend -l +100%FREE /dev/vg-data/var
xfs_growfs /var

# Für Btrfs
lvextend -l +100%FREE /dev/vg-data/var
btrfs filesystem resize max /var

Fehler: “lvreduce: New size would cut into existing data”#

Symptom: Beim Verkleinern meckert LVM.

Ursache: Du versuchst, das LV kleiner zu machen als das Filesystem.

Lösung:

# IMMER erst Filesystem verkleinern!
e2fsck -f /dev/mapper/vg-data-home
resize2fs /dev/mapper/vg-data-home 50G
# DANN das LV
lvreduce -L 50G /dev/vg-data-home

System bootet nicht mehr nach Resize#

Symptom: Nach fdisk-Änderungen bootet System nicht.

Ursache: Partition-Start geändert oder falsche Partition-ID.

Lösung:

# Mit Live-System/Rescue booten
# Partition-Tabelle prüfen
fdisk -l /dev/sda

# LVM aktivieren
vgscan
vgchange -ay

# Filesystem checken
e2fsck -f /dev/mapper/vg-data-root

# Grub neu installieren
mount /dev/mapper/vg-data-root /mnt
grub-install --root-directory=/mnt /dev/sda

Präventiv: Vor riskanten fdisk-Operationen immer Snapshot oder Backup!

Best Practices: So machst du’s richtig#

✅ Vor jeder Operation:

  • Backup! Snapshots sind kein Backup-Ersatz.
  • Status dokumentieren: pvs, vgs, lvs → Textfile
  • Bei kritischen Systemen: Maintenance Window

✅ Beim Erweitern:

  • Erst PV, dann VG, dann LV, dann Filesystem
  • --resizefs nutzen (spart einen Schritt)
  • Nach jedem Schritt Status prüfen

✅ Beim Verkleinern:

  • Doppelt und dreifach rechnen!
  • Filesystem-Check VOR und NACH der Operation
  • Filesystem IMMER vor LV verkleinern
  • Mindestens 10% Puffer lassen

✅ In Produktion:

  • Teste Resize-Prozedur erst in VM
  • Monitoring: Checke Alerts nach Resize
  • Dokumentiere Änderungen im Runbook

❌ Niemals:

  • Root-Partition online verkleinern (geht nicht)
  • LV vor Filesystem verkleinern (Datenverlust!)
  • Ohne Filesystem-Check resizen
  • In Produktions-Primetime rumexperimentieren

Zusammenfassung: Dein Cheat Sheet#

LVM erweitern (Online)#

# 1. Nach Disk-Vergrößerung: PV resizen
pvresize /dev/sda5

# 2. LV erweitern + Filesystem anpassen (ein Befehl!)
lvextend -l +100%FREE --resizefs /dev/vg-data/var

# 3. Status prüfen
df -h

LVM verkleinern (Offline)#

# 1. Unmounten
umount /home

# 2. Filesystem-Check
e2fsck -f /dev/mapper/vg-data-home

# 3. Filesystem verkleinern (ERST!)
resize2fs /dev/mapper/vg-data-home 50G

# 4. LV verkleinern (DANN!)
lvreduce -L 50G /dev/vg-data-home

# 5. Check & Mount
e2fsck -f /dev/mapper/vg-data-home
mount /home

Quick-Commands#

# Alle LVM-Infos auf einen Blick
pvs && vgs && lvs

# Freien Speicher in VG anzeigen
vgs --noheadings -o vg_free <vg-name>

# LV + Filesystem in einem Rutsch erweitern
lvextend -l +100%FREE --resizefs <lv-path>

# Filesystem manuell erweitern
resize2fs <lv-path>          # ext4
xfs_growfs <mountpoint>      # XFS

🛒 Empfohlene Hardware#

🖥️

Hetzner Cloud

LVM in der Cloud testen? Hetzner Cloud Server lassen sich mit zusätzlichen Volumes erweitern — perfekt zum Üben. Hetzner ausprobieren →

Fazit#

LVM-Resize ist weniger kompliziert, als es auf den ersten Blick scheint. Die goldene Regel: Beim Erweitern von unten nach oben (PV → VG → LV → FS), beim Verkleinern von oben nach unten (FS → LV).

Mit --resizefs sparst du dir einen Schritt und minimierst Fehlerquellen. In Proxmox-Umgebungen ist LVM besonders praktisch, weil du VMs flexibel anpassen kannst, ohne komplizierte Partitionierungs-Tools in der VM zu bemühen.

Wichtigste Takeaways:

  • ✅ Online-Erweiterung funktioniert problemlos (keine Downtime!)
  • ✅ Verkleinern braucht Unmount und doppelte Vorsicht
  • ✅ resize2fs/xfs_growfs nicht vergessen!
  • ✅ Backup vor riskanten Operationen ist PFLICHT

Jetzt bist du bereit, dein Storage flexibel zu verwalten. Viel Erfolg beim Resizen — und denk dran: Backup first! 🚀

Einige Links auf dieser Seite sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision — für dich ändert sich am Preis nichts. So unterstützt du diesen Blog und ermöglichst weitere kostenlose Tutorials. Danke! 🙏

[« Vorherige]
Home Assistant: Garagentor mit Zigbee-Sensor und Shelly steuern