LVM RAID1: Partitionen verkleinern und vergrößern

Kurzfassung: Diese Anleitung zeigt Schritt für Schritt, wie Sie ein Software-RAID1 mit LVM darauf sicher verkleinern (shrink) und wieder vergrößern (grow) können — sowohl für intakte als auch für degradierte Arrays. Starten Sie von einem Rescue-System, sichern Sie wichtige Daten, prüfen das Dateisystem und verändern erst die Dateisystemgröße, dann das LVM-Laufwerk und schließlich das RAID-Device. Lesen Sie die Risikohinweise und die Checklisten, bevor Sie Änderungen am Produktivsystem vornehmen.

Wichtig: Arbeiten Sie nur, wenn Sie aktuelle Backups haben. Fehlerhafte Schritte können Datenverlust verursachen.

Absicht dieses Artikels und verwandte Begriffe

Primäre Absicht: zeigen, wie man RAID1-Partitionen mit LVM oberhalb sicher verkleinert und wieder vergrößert. Verwandte Varianten: LVM verkleinern, LVM vergrößern, mdadm RAID1 resize, pvresize, lvreduce, lvextend.

Begriffsdefinitionen in einer Zeile:

RAID1: Spiegelung von zwei oder mehr Festplatten.
LVM: Logical Volume Manager; Abstraktionsebene für flexible Volume-Größen.
PV/VG/LV: Physical Volume / Volume Group / Logical Volume.

TL;DR für Entscheider

Sicherung prüfen: Vor jeder Größenänderung muss ein konsistentes Backup vorhanden sein.
Rescue-System: Für System-Partitionen offline booten (z. B. Live-CD).
Reihenfolge: Dateisystem verkleinern → LV verkleinern → PV anpassen → RAID anpassen → PV wieder vergrößern → LV/Dateisystem zurück vergrößern.

1 Vorbemerkung und Ausgangsszenario

In diesem Artikel wird demonstriert, wie man ein Software-RAID1 (/dev/md1) verkleinert und wieder vergrößert, wenn darauf ein LVM-Physical-Volume liegt, das die Volume Group “server1” enthält. Die Beispiele wurden mit ext3-Dateisystemen getestet; die Befehle gelten grundsätzlich auch für ext4, beachten Sie aber die jeweiligen Tool-Optionen.

Ausgangssituation (Beispiel):

RAID: /dev/md1, bestehend aus /dev/sda5 und /dev/sdb5
LVM PV auf /dev/md1, VG server1
LV: /dev/server1/root (System, gemountet als /) und /dev/server1/swap_1

Kurzfall: Eine Platte ist defekt oder enthält fehlerhafte Sektoren am Ende; Ziel ist es, das RAID temporär zu verkleinern, die defekten Sektoren zu umgehen, neue Platte einzubauen und anschließend wieder auf die ursprüngliche Größe zu wachsen.

Wichtig: Diese Anleitung enthält sowohl Schritte für ein intaktes Array als auch Hinweise für den degradieren Fall. Wenn das betroffene Array Ihre Systempartition enthält, verwenden Sie ein Rescue-System (z. B. Knoppix Live-CD) — die LVs müssen unmounted sein.

2 Vorbereitungen (Rescue-System und Module)

Hinweis: Wenn Sie nicht die Systempartition bearbeiten, ist ein Rescue-System optional. Dennoch sollten LVs unmounted sein.

Booten Sie in ein Rescue-System (Live-CD/-USB).
Module laden (falls erforderlich):

modprobe md
modprobe linear
modprobe multipath
modprobe raid0
modprobe raid1
modprobe raid5
modprobe raid6
modprobe raid10

mdadm konfigurieren und Arrays starten:

cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_orig
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
mdadm -A --scan

LVM-Dienste starten:

/etc/init.d/lvm start

Dateisystemprüfung durchführen (wichtig vor Resize):

e2fsck -f /dev/server1/root

Wichtig: Verwenden Sie das passende fsck-Tool für Ihr Dateisystem (z. B. xfs_repair für XFS; beachten Sie, dass XFS nicht verkleinert werden kann).

3 Intaktes Array: Schritt-für-Schritt-Verkleinerung und Wiederherstellung

Szenario: /dev/md1 ist aktuell 5 GB; Ziel ist eine temporäre Verkleinerung auf 4 GB, um fehlerhafte Sektoren am Ende einer physischen Partition zu umgehen. Die LVs sollen nach dem erfolgreichen Austausch wieder vergrößert werden.

Wichtig: Die Reihenfolge ist entscheidend — beginnen Sie bei der obersten Ebene (Dateisystem) und arbeiten Sie sich nach unten (LV → PV → RAID).

Schritt 1 — Dateisystem prüfen und verkleinern

Führen Sie eine Dateisystemprüfung durch:

e2fsck -f /dev/server1/root

Verkleinern Sie das Dateisystem auf einen sicheren Wert, kleiner als das Ziel-LV. Beispiel: Dateisystem auf 2G schrumpfen:

resize2fs /dev/server1/root 2G

Hinweis: Verwenden Sie einen Wert, der alle Daten plus Wachstumsmarge abdeckt.

Schritt 2 — LV verkleinern

Anschließend LV verkleinern (z. B. auf 2.5G):

lvreduce -L2.5G /dev/server1/root

Wichtig: Prüfen Sie mit lvdisplay die aktuelle LV-Größe vor und nach dem Befehl.

Schritt 3 — Swap-LV entfernen (optional)

Wenn ein Swap-LV am Ende des PV liegt, kann es notwendig sein, diesen temporär zu entfernen, damit genug zusammenhängender Platz frei wird.

lvremove /dev/server1/swap_1

Schritt 4 — PV verkleinern

Schrumpfen Sie das PV so, dass es in das verkleinerte RAID-Device passt. Beispiel: Setzen der PV-Größe auf 3G:

pvresize --setphysicalvolumesize 3G /dev/md1

Schritt 5 — RAID verkleinern

Die mdadm –grow –size nimmt die Größe in KiB (für 4 GB: 4 × 1024 × 1024 = 4194304). Die Größe muss durch 64 teilbar sein.

mdadm --grow /dev/md1 --size=4194304

Wichtig: Die Operation reduziert die Anzahl der verfügbaren Blöcke auf jedem Member; während der Änderung sollten Sie auf Fehlermeldungen im Kernel-Log achten.

Schritt 6 — PV auf größtmögliche Größe zurücksetzen und LVs anpassen

Nachdem das RAID kleiner ist, lassen Sie pvresize das PV wieder anpassen:

pvresize /dev/md1

Prüfen Sie die freie PE-Anzahl mit vgdisplay. Erstellen Sie gegebenenfalls das Swap-LV neu und wachsen Sie das Root-LV wieder:

lvcreate --name swap_1 -l 66 server1
mkswap /dev/server1/swap_1
lvextend -l +317 /dev/server1/root
resize2fs /dev/server1/root
e2fsck -f /dev/server1/root

Das Beispiel oben zeigt die genaue Reihenfolge und die Rechnungen für PEs. Ihre Werte (PE Size/Anzahl) entnehmen Sie vgdisplay.

Schritt 7 — Neustart und Kontrolle

Rebooten Sie in das Standard-System und prüfen Sie:

cat /proc/mdstat
df -h
pvdisplay
vgdisplay
lvdisplay

Kontrollieren Sie, ob die Größen wie gewünscht sind und das System sauber bootet.

4 Degradiertes Array: Vorgehen bei einem beschädigten Member

Szenario: /dev/md1 ist degraded, z. B. /dev/sda5 ausgefallen, /dev/sdb5 aktiv, aber mit fehlerhaften Sektoren am Ende. Ziel: Array so verändern, dass die fehlerhaften Bereiche nicht verwendet werden, neues Ersatzmedium einbauen, Resync durchführen und wieder in die ursprüngliche Größe wachsen.

Wichtig: Bei degradierter RAID-Konfiguration ist die Fehlerwahrscheinlichkeit höher. Backups sind Pflicht.

Kerntaktik:

RAID temporär kleiner machen, um beschädigte Sektoren zu umgehen
Ersatzlaufwerk einbauen und Partition anlegen
Ersatzpartition dem Array hinzufügen, Resync abwarten
defekte Partition entfernen, zweite Ersatzplatte einbauen (falls nötig)
RAID wieder auf ursprüngliche Größe bringen

Schritt 1 — Zustand prüfen

cat /proc/mdstat
mdadm --detail /dev/md1
dmesg | tail -n 50

Schritt 2 — Degradierte Member identifizieren und ggf. ausbinden

Wenn ein Member fehlerhaft ist, markieren Sie es als failed und entfernen Sie es (falls noch nicht automatisch geschehen):

mdadm --fail /dev/md1 /dev/sda5
mdadm --remove /dev/md1 /dev/sda5

Schritt 3 — RAID verkleinern, um fehlerhafte Sektoren zu umgehen

Verkleinern Sie /dev/md1 wie im intakten Fall mit mdadm --grow --size=... nachdem Sie PV/LV/Dateisystem vorbereitet haben (siehe Abschnitt 3).

Schritt 4 — Ersatzplatte einbauen, Partition anlegen und hinzufügen

Bauen Sie physisch die neue Festplatte ein.
Erstellen Sie passende Partitionen (z. B. mit fdisk oder parted) mit identischer Größe/Typ (Linux raid autodetect):

# Beispiel mit sda neu:
fdisk /dev/sda
# Partition anlegen: /dev/sda5, Typ fd (Linux raid autodetect)

Fügen Sie die neue Partition dem RAID hinzu:

mdadm --add /dev/md1 /dev/sda5

Überwachen Sie den Resync:

watch -n 10 cat /proc/mdstat

Schritt 5 — Defekte Platte ersetzen und Array wiederherstellen

Nachdem das neue Member synchronisiert ist, entfernen Sie das defekte Member (falls noch vorhanden) und ersetzen Sie es analog.

Schritt 6 — RAID wieder vergrößern

Sobald alle Members gesund sind und der Resync abgeschlossen ist, können Sie das RAID wieder auf die gewünschte Größe bringen (invertierter Ablauf):

mdadm --grow /dev/md1 --size=
pvresize /dev/md1
# dann lvextend/resize2fs wie benötigt

5 Wichtige Hinweise, Risiken und Prüfungen

Wichtig: Verkleinern von Dateisystemen ist riskanter als Vergrößern. Bei Fehlern droht Datenverlust.

Risiken und Gegenmaßnahmen:

Datenverlust bei falscher Größenwahl: Immer vorher vollständige Backups erstellen.
Resync-Abbruch bei fehlerhaften Sektoren: Fehlerhafte Platte entfernen oder Partition so verkleinern, dass defekte Bereiche nicht verwendet werden.
Inkompatible Dateisysteme: Einige Dateisysteme (z. B. XFS) lassen sich nicht verkleinern; planen Sie entsprechend.
Metadata-Granularität: PE-Größe, LV-Alignedness und Partition-Grenzen können Einfluss haben — prüfen Sie pvdisplay und vgdisplay.

Prüfungen (vor und nach jeder größeren Operation):

e2fsck (oder passendes Tool) vor Resize
mdadm –detail vor Änderungen
dmesg / /var/log/kern.log auf I/O-Fehler prüfen
pvdisplay, vgdisplay, lvdisplay zur Konsistenzprüfung

6 Alternative Ansätze und Gegenbeispiele

Alternative A — Backup, Recreate, Restore

Vollständiges Backup (Image oder rsync), RAID neu erstellen, LVM neu aufsetzen, Daten zurückspielen. Sicher, aber zeitaufwändig.

Alternative B — Live-Migration auf neue Disks

Neue Disks einbauen, RAID neu aufbauen (oder mit –add und Resync), LVM-PV nach und nach erweitern, dann alte Disks entfernen.

Wann diese Anleitung nicht passt:

Wenn Sie XFS als Dateisystem verwenden (keine Verkleinerung möglich).
Wenn kein Rescue-System verfügbar ist und Sie an der System-Partition arbeiten müssen.
Wenn kein aktuelles Backup vorhanden ist.

7 Maturity-Level und Empfehlungen

Maturity-Stufen für Operationen an LVM/RAID1:

Stufe 1 (Test): Üben Sie die Schritte in einer VM oder auf nicht-produktiven Geräten.
Stufe 2 (Limited Production): Kleine Datenmengen, verfügbare Backups, Wartungsfenster.
Stufe 3 (Production): Dokumentierte SOPs, Change-Management, Redundante Backups, Überwachung.

Empfehlung: Auf Produktivsystemen nie ohne Test und Backup arbeiten.

8 Factbox: Wichtige Zahlen und Begriffe (Beispielwerte)

Beispiel PE-Size: 4.00 MB
Beispiel PV-Size: 4.75 GB → nach Shrink 4.00 GB
mdadm –grow –size ist in KiB (1 GiB = 1024 × 1024 KiB)
resize2fs ohne Angabe wächst auf maximal verfügbare Größe

Hinweis: Nutzen Sie vgdisplay und pvdisplay für Ihre realen Werte.

9 Playbook / SOP-Checkliste für Administratoren

Vorbereitung

Vollständiges Backup vorhanden und überprüfbar
Wartungsfenster & Mitteilungen geplant
Rescue-Medium bereit
Boot in Rescue-Umgebung getestet
Notfallplan & Rollback-Plan vorhanden

Durchführung (Rescue-System)

Module laden (md, raid1, …)
mdadm-Konfiguration prüfen
LVM starten
Dateisystemprüfungen durchführen
Dateisystem verkleinern (resize2fs)
LV verkleinern (lvreduce)
PV verkleinern (pvresize –setphysicalvolumesize)
RAID verkleinern (mdadm –grow –size)
pvresize ohne Size ausführen
LVs neu anlegen/erweitern
Dateisystem vergrößern (resize2fs)
e2fsck erneut
System normal booten und Validierung

Rollback-Plan

Bei Fehler: Wiederherstellung aus Backup oder Rücksetzung des RAID auf ältere Konfiguration (nur mit gültigen Backups möglich).

10 Testfälle und Akzeptanzkriterien

Testfälle:

TF1: Verkleinern eines Raid1 mit LVM, danach erfolgreicher Boot.
TF2: Vergrößern nach Austausch fehlerhafter Platte, Resync erfolgreich.
TF3: Entfernen und Wiederherstellen eines Swap-LVs ohne Datenverlust.

Kriterien bei Annahme:

System bootet fehlerfrei.
Alle LVs haben erwartete Größe und sind gemounted.
Keine I/O-Fehler in Kernel-Logs nach Resync.
mdadm zeigt [UU] für alle normalen Arrays.

11 Rollebasierte Checklisten

Systemadministrator

Backup prüfen
Commands und Reihenfolge dokumentieren
Wartungsfenster koordinieren

Rescue-Techniker

Live-System booten
Module und mdadm starten
Dateisysteme prüfen und anpassen

Operator

Hardwaretausch durchführen
Neue Partitionen anlegen und Device-Mapping prüfen

12 Decision-Tree (Mermaid) zur schnellen Entscheidungsfindung

flowchart TD
  A[RAID1 mit LVM resize nötig?] --> B{Beinhaltet es die Systempartition?}
  B -- Ja --> C[Boot in Rescue-System]
  B -- Nein --> D[Kann online erfolgen?]
  D -- Ja --> E[Unmount LVs und arbeiten]
  D -- Nein --> C
  C --> F[Dateisystem prüfen & verkleinern]
  E --> F
  F --> G[LV verkleinern]
  G --> H[PV verkleinern]
  H --> I[RAID verkleinern]
  I --> J[PV/pvresize]
  J --> K[LV/FS vergrößern und prüfen]
  K --> L[Reboot & Validierung]

13 Risiko-Matrix und Gegenmaßnahmen

Risiko: Datenverlust bei falscher Shrink-Größe
- Maßnahme: Vorher Backup, großzügige Margin beim Shrink
Risiko: Resync scheitert wegen I/O-Fehlern
- Maßnahme: Defekte Platte entfernen, Partition verkleinern, Ersatz einsetzen
Risiko: Dateisystem inkompatibel
- Maßnahme: Prüfen (XFS nicht shrinkbar), alternative Strategie wählen

14 Kompatibilität und Migrationshinweise

XFS: Kein Shrink möglich; alternative: Backup → neues FS auf kleinerem LV → Restore.
Verschiedene mdadm- und LVM-Versionen: Kleinere Unterschiede im Tool-Output, prüfen Sie manpages (man mdadm, man pvresize).

15 Kurzer Ankündigungstext für Change-Log (100–200 Zeichen)

Wartungsankündigung: Geplante Verkleinerung und Wiederherstellung von LVM-on-RAID1 auf Server1 zur Umgehung defekter Sektoren. Backup vorhanden; Reboot erforderlich.

16 1‑Zeilen Glossar

RAID1: Spiegelung für Redundanz. - LVM: Abstraktionsschicht für flexible Volumes.

17 Zusammenfassung

Testen Sie die gesamte Prozedur vorher in einer VM.
Backup ist zwingend erforderlich.
Reihenfolge: FS → LV → PV → RAID beim Verkleinern; umgekehrt beim Vergrößern.
Monitoren Sie Resync-Prozesse und Kernel-Logs auf I/O-Fehler.

Wichtig: Diese Anleitung bietet ein praxisbezogenes Vorgehen, ersetzt jedoch nicht ein getestetes, organisationsspezifisches Change-Management. Bei Unsicherheit: Support oder erfahrenen Kollegen hinzuziehen.

Befehle aus dem Beispiel (Originalausgaben zur Referenz)

cat /proc/mdstat

Beispielausgabe aus dem Original (nur als Referenz):

server1:~# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda5[0] sdb5[1]
4988032 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
248896 blocks [2/2] [UU]

unused devices: 
server1:~#

Weitere Ausgaben im Artikel stammen aus praktischen Tests und zeigen typische pvdisplay, vgdisplay und lvdisplay-Outputs; entnehmen Sie Ihre Werte den entsprechenden Tools auf Ihrem System.

Hinweis: Diese Anleitung ist eine Hilfestellung und keine rechtliche oder vertragliche Garantie. Führen Sie Änderungen nur nach ausreichender Prüfung und mit vorhandenem Backup durch.