Verkleinern eines degradierten mdadm RAID1 auf /dev/md1

Kurzfassung: Diese Anleitung beschreibt Schritt für Schritt, wie man ein degradiertes RAID1 Array /dev/md1, bestehend aus /dev/sda5 und /dev/sdb5, bei ausgefallenem /dev/sda5 sicher verkleinert. Zuerst wird die defekte Partition entfernt und die Superblöcke gelöscht, dann erfolgt das Arbeiten im Rettungssystem: Dateisystem prüfen, logisches Volumen und Dateisystem verkleinern, PV anpassen, RAID verkleinern, PV wieder erweitern, LVs wiederherstellen und letztlich die gesicherte Platte wieder einfügen. Achtung: Backups anfertigen und vor jedem Schritt prüfen

Einleitung

Diese Anleitung beschreibt, wie man ein degradiertes RAID1 Array verkleinert, wenn einer der beiden Spiegelträger ausgefallen ist. Ziel ist es, /dev/md1 von etwa 5 GB auf 4 GB zu verkleinern, dabei LVM und Dateisystem korrekt anzupassen und anschließend das ausgebaute Laufwerk wieder in das Array aufzunehmen.

Begriffe in einer Zeile

• RAID1: Spiegelung zweier Laufwerke
• mdadm: Tool zur Verwaltung von Linux-RAID
• LVM: Logical Volume Manager
• PV: Physical Volume
• VG: Volume Group
• LV: Logical Volume

Wichtig: Führen Sie diese Schritte nur, wenn Sie verifizierte Backups haben. Ein Fehler kann zum Datenverlust oder zu einem nicht bootfähigen System führen.

Ausgangssituation und Diagnosedaten

Der ursprüngliche Status des Systems war in etwa wie folgt erfasst:

cat /proc/mdstat

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

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

unused devices: server1:~#

df -h

server1:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/server1-root 4.5G 741M 3.5G 18% / tmpfs 126M 0 126M 0% /lib/init/rw udev 10M 68K 10M 1% /dev tmpfs 126M 0 126M 0% /dev/shm /dev/md0 236M 18M 206M 8% /boot server1:~#

pvdisplay

server1:~# pvdisplay — Physical volume — PV Name /dev/md1 VG Name server1 PV Size 4.75 GB / not usable 0 Allocatable yes (but full) PE Size (KByte) 4096 Total PE 1217 Free PE 0 Allocated PE 1217 PV UUID Ntrsmz-m0o1-WAPD-xhsb-YpH7-0okm-qfdBQG

server1:~#

vgdisplay

server1:~# vgdisplay — Volume group — VG Name server1 Format lvm2 Metadata Areas 1 VG Access read/write VG Status resizable Cur LV 2 Cur PV 1 VG Size 4.75 GB PE Size 4.00 MB Total PE 1217 Alloc PE / Size 1217 / 4.75 GB Free PE / Size 0 / 0 VG UUID X3ZYTy-39yq-20k7-GCGk-vKVU-Xe0i-REdEu0

server1:~#

lvdisplay

server1:~# lvdisplay — Logical volume — LV Name /dev/server1/root VG Name server1 LV Size 4.50 GB Current LE 1151

— Logical volume — LV Name /dev/server1/swap_1 VG Name server1 LV Size 264.00 MB Current LE 66

server1:~#

Diese Daten geben Aufschluss, dass /dev/md1 derzeit ca. 4.75 GB liefert und die logischen Volumes insgesamt etwa 4.76 GB belegen. Ziel ist, PV und Array kontrolliert zu reduzieren, sodass LVs und Dateisystem konsistent bleiben.

Übersicht der Strategie

Hauptschritte in der richtigen Reihenfolge:

1. Defekte Partition aus dem Array entfernen und Superblock löschen
2. Rettungssystem booten und RAID sowie LVM initialisieren
3. Dateisystem prüfen
4. Dateisystem verkleinern, LV verkleinern
5. Nicht zuletzt stehende LVs entfernen falls nötig, PV verkleinern
6. mdadm Array auf neue Größe setzen
7. PV wieder an die neue Arraygröße anpassen und LVs wiederherstellen
8. Dateisystem auf LV vergrößern, Integritätsprüfungen
9. Alte Platte wieder einbinden und rebuild starten

Jeder Schritt enthält Prüfungen und Hinweise, wann anzuhalten ist.

Schritt 1: Defekte Partition entfernen

Wichtig: Prüfen Sie, dass /dev/sda5 wirklich ausgefallen ist, bevor Sie entfernen. Falls die Platte noch gelegentlich antwortet, die SMART-Werte prüfen.

Ausführen auf dem laufenden System:

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

Anschließend unbedingt den Superblock auf /dev/sda5 löschen. Dies verhindert, dass der Datenträger beim nächsten Boot oder beim automatischen Scan wieder als Mitglied erkannt wird und das Array durcheinanderbringt.

mdadm --zero-superblock /dev/sda5

Wichtig: Wenn Sie diesen Schritt vergessen, kann das System nach dem Resizing Probleme beim Booten verursachen.

Schritt 2: Rettungssystem booten und Module laden

Booten Sie ein Rettungssystem oder Systemabbild, das mdadm und LVM unterstützt. Laden Sie die benötigten Kernelmodule:

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

Anschließend mdadm Arrays aktivieren und mdadm.conf sichern:

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

Starten Sie LVM:

/etc/init.d/lvm start

Schritt 3: Dateisystem prüfen

Vor jeder Größenänderung muss das Dateisystem geprüft werden:

e2fsck -f /dev/server1/root

Falls e2fsck Fehler meldet, beheben Sie diese vor dem Shrink.

Schritt 4: Dateisystem und LV verkleinern

Die Reihenfolge ist wichtig: Dateisystem zuerst, dann LV. Die Dateisystemgröße muss kleiner oder gleich der vorgesehenen LV-Größe sein.

Beispiel in dieser Anleitung: Ziel ist ein LV root von 2.5 GB mit einem ext4 Dateisystem von 2 GB. Wählen Sie Werte, die alle Daten aufnehmen.

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

Achtung: lvreduce kann zerstörerisch sein, wenn die angegebene Größe kleiner ist als das Dateisystem. Deshalb zuerst resize2fs ausführen.

Schritt 5: Swap LV entfernen falls am Ende

Wenn ein LV am physikalischen Ende liegt, muss es ggf. entfernt, später neu angelegt werden. In diesem Beispiel ist swap_1 am Ende und wird entfernt.

lvremove /dev/server1/swap_1

Wenn swap nicht am Ende liegt, sparen Sie sich diesen Schritt und stellen sicher, dass das letzte LV auf dem PV verkleinert wird.

Schritt 6: PV verkleinern

Jetzt kann das PV auf die neue physikalische Größe gesetzt werden. Beispiel: setzen auf 3 GB.

pvresize --setphysicalvolumesize 3G /dev/md1

Prüfen Sie danach vgdisplay und pvdisplay auf Konsistenz.

Schritt 7: RAID Array verkleinern

mdadm erwartet die Grösse in KiByte. 4 GiB entsprechen 4 × 1024 × 1024 KiB = 4194304. Achten Sie darauf, dass der Wert durch 64 teilbar ist.

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

Hinweis: Dieser Schritt verringert die Anzahl der verfügbaren Blöcke des md1 Arrays. Warten Sie gegebenenfalls auf Synchronisationen und prüfen Sie dmesg und /proc/mdstat.

Schritt 8: PV erneut resize und LVs wieder erstellen

Vergrößern Sie das PV wieder auf die größtmögliche Größe innerhalb des Arrays:

pvresize /dev/md1

Prüfen Sie vgdisplay. In unserem Beispiel hatten wir nach pvresize freie PE, deshalb wurde swap_1 neu erstellt:

lvcreate --name swap_1 -l 66 server1
mkswap /dev/server1/swap_1

Nun kann das root LV wieder erweitert werden, um den verfügbaren Platz zu nutzen:

lvextend -l +317 /dev/server1/root
resize2fs /dev/server1/root

Zum Schluss nochmals prüfen:

e2fsck -f /dev/server1/root
vgdisplay
cat /proc/mdstat

Schritt 9: Defekte Platte wieder einbinden und rebuild starten

Nach Reboot in das normale System die zuvor entfernte Platte vorbereiten und wieder hinzufügen:

mdadm --zero-superblock /dev/sda5
mdadm -a /dev/md1 /dev/sda5

Prüfen Sie sync-Status:

cat /proc/mdstat

Sie sollten sehen, dass /dev/sdb5 und /dev/sda5 synchronisiert werden.

Wichtige Prüfungen und Stopsignale

Stoppen Sie den Prozess und holen Sie Support, wenn einer der folgenden Fälle eintritt:

• e2fsck meldet nicht behebbaren Fehler
• pvresize schlägt fehl wegen fehlender freier PEs
• mdadm –grow verweigert die Operation wegen inkonsistenter Metadaten
• Beim lvreduce sehen Sie, dass Daten über den neuen Grenzwert hinaus liegen

In diesen Fällen Backups wiederherstellen und Ursachen analysieren.

Wann diese Methode nicht funktioniert

• Wenn das Array RAID5/6 mit Parität ist und Ambitionen auf Shrink bestehen, sind weitere Schritte nötig
• Bei verschlüsselten LVs müssen Sie vorab die Entschlüsselungsschritte im Rettungssystem durchführen
• Wenn mehrere LVs fragmentiert am Ende des PV liegen, kann ein einfacher Shrink nicht möglich sein

Alternative Ansätze

• Offline Klonen: Festplatte 1 klonen, neues Array mit kleinerer Größe erstellen und Daten zurückkopieren
• Backup & Restore: vollständiges Backup erstellen, Array neu anlegen in gewünschter Größe, Daten zurückspielen
• Migration auf neues Storage mit gewünschten Größen, dann LVM PV migrieren mit pvmove

Vorteile und Nachteile kurz

• In-place Shrink: schneller, weniger I/O, aber riskanter
• Backup/Restore: sicherer, aber zeitaufwendiger
• Migration: minimaler Risiko für Datenverlust, aber Hardware- und Zeitbedarf

Role-basierte Checkliste

Systemadministrator

• Backup verifizieren
• Zuverlässiges Rettungssystem vorbereiten
• mdadm.conf sichern
• Alle Schritte in einer Shell-Session dokumentieren

Operator

• RAID Status überwachen
• LVM- und FS-Checks durchführen
• Rebuild überwachen

Technischer Leiter

• Wartungsfenster genehmigen
• Stakeholder informieren

SOP Kurzversion

1. Backup validieren
2. mdadm –manage … fail und remove auf ausgefallener Partition
3. mdadm –zero-superblock auf der ausgefallenen Partition
4. Rettungssystem booten, Module laden, mdadm -A –scan, lvm starten
5. e2fsck -f auf root LV
6. resize2fs auf kleinere Größe
7. lvreduce auf neue LV Größe
8. Optional: lvremove für am Ende stehende LVs
9. pvresize –setphysicalvolumesize auf gewünschte PV-Größe
10. mdadm –grow auf gewünschte MD Größe
11. pvresize ohne Parameter
12. lvcreate/mkswap bei Bedarf
13. lvextend/resize2fs root LV
14. e2fsck erneut und reboot
15. mdadm –zero-superblock auf zurückgesetzter Platte und mdadm -a

Risikomatrix und Gegenmaßnahmen

Faktenbox

• Ziel-Array-Größe: 4 GiB (4194304 KiB in mdadm)
• Ursprungs-PV: ca. 4.75 GB
• Beispiel LV root nach shrink: 2.5 GB
• Swap LV Beispielgröße: 264 MB

Einzeilige Glossareinträge

• mdadm: Tool zur Erstellung und Verwaltung von Software-RAID auf Linux
• pvresize: Anpassung der PV-Größe an underlying Device
• resize2fs: Verkleinern/Vergrößern ext2/3/4 Dateienystem

Testfälle / Akzeptanzkriterien

• Nach allen Schritten startet das System normal
• /proc/mdstat zeigt zwei aktiv synchronisierende Geräte nach Re-add
• vgdisplay zeigt erwartete VG-Größe und freie PE
• e2fsck liefert keine Fehler

Kurze Ankündigung für Teamkommunikation (100 bis 200 Wörter)

Geplante Anpassung des RAID1 Arrays auf Server server1: Wir werden das degradiertes mdadm Array /dev/md1 verkleinern, da eine der gespiegelten Partitionen ausgefallen war. Vorgehen: Defekte Partition entfernen und Superblock löschen, im Rettungssystem Dateisystem und LVM anpassen, RAID auf neue Größe setzen, PV neu skalieren und LVs wiederherstellen. Abschließend wird die vorher entfernte Platte wieder dem Array hinzugefügt und der Rebuild gestartet. Maßnahme findet im Wartungsfenster statt. Bitte stellt sicher, dass Backups vorhanden sind und meldet Probleme an das Support-Team.

Zusammenfassung

• Verkleinern eines degradierten RAID1 ist möglich, erfordert aber genaue Reihenfolge und Vorsicht
• Immer Backup vor Beginn
• Dateisystem zuerst verkleinern, dann LV
• PV und RAID müssen konsistent angepasst werden
• Nach erfolgreichem Shrink kann die Platte wieder in das Array eingebunden werden

Wichtig: Diese Anleitung ist eine pragmatische Hilfestellung. Prüfen Sie jede Kommandoausgabe und halten Sie Rücksprache mit erfahrenen Kollegen bei Unsicherheiten.