LVM verständlich erklärt: logische Volumes, Snapshots — und was tun, wenn LVM zusammenbricht

Die Antwort vorab: Bei der Datenwiederherstellung aus LVM entscheidet nicht die Geschwindigkeit, sondern die Reihenfolge der Schritte. Stoppen Sie zuerst alle Schreibzugriffe und stellen Sie fest, in welcher Schicht der Fehler liegt — fehlt die physische Festplatte, der PV-Header, die VG-Metadaten, der Thin Pool, oder lässt sich nur das Dateisystem nicht einhängen? Wenn die Festplatte I/O-Fehler meldet, arbeiten Sie ausschließlich mit einer Sektorkopie: vgcfgrestore kann das LVM-Mapping wiederherstellen, bringt aber weder den Inhalt einer fehlenden Festplatte zurück noch repariert es die Metadaten des Thin Pools.

Für viele Administratoren ist LVM eine Blackbox, die sich jahrelang klaglos richtig verhält — und an dem Tag, an dem sie es nicht mehr tut, lernt man sie unter Zeitdruck kennen. Dieser Text ist zum einen eine verständliche Erklärung, was sich unter /dev/mapper/ eigentlich abspielt, und zum anderen ein Entscheidungsleitfaden für den Moment, in dem der Server Couldn't find device with uuid meldet und Sie nicht wissen, ob Sie zu vgcfgrestore greifen sollen oder zum Netzschalter.

LVM meldet einen Fehler: Was als Erstes zu tun ist

Der Server startet nicht, ein Datenvolume fehlt, oder vgs zeigt partial an. Bevor Sie mit einer Reparatur beginnen:

1. Stoppen Sie Schreibzugriffe auf die betroffenen Festplatten. Hängen Sie aus, was sich aushängen lässt, und lassen Sie keinen Dienst weiter auf ein Volume einprügeln, das sich merkwürdig verhält.
2. Starten Sie den Server nicht wiederholt „versuchsweise” neu. Bei einer sterbenden Festplattenmechanik ist jedes erneute Hochfahren ein Glücksspiel, bei einer virtuellen Maschine kann ein Neustart weitere Automatismen auslösen.
3. Führen Sie pvcreate, vgcfgrestore, lvconvert --repair, fsck -y oder xfs_repair nicht aus, solange Sie keine Kopie der Datenträger haben. Alle vier schreiben Daten.
4. Sichern Sie die Diagnoseausgaben und Systemprotokolle — aber außerhalb des betroffenen Speichersystems.
5. Sobald I/O-Fehler auftauchen, endet die Zeit für Experimente mit LVM, und die Zeit für eine Sektorkopie beginnt. LVM wird erst danach, auf Basis dieser Kopie, angegangen.

Stoppen Sie bei einem virtuellen Server automatische Snapshots und Replikation — alles, was das Festplattenabbild selbstständig verändert. Notieren Sie sich bei einem physischen Server die Seriennummern der Festplatten, die Ports und die Reihenfolge am Controller, solange sich das noch auslesen lässt.

LVM ist weder ein Dateisystem noch ein Backup. Es ist eine Übersetzungsschicht zwischen dem physischen Speicher und den logischen Blockvolumes. Sie blind zu reparieren, ohne die ursprüngliche Struktur zu kennen, ist, als würde man den Inhalt eines Buches anhand eines beschädigten Registers neu schreiben.

Wie LVM funktioniert, ohne überflüssige Theorie

Der übliche Aufbau eines Linux-Servers sieht so aus:

HDD / SSD / RAID / virtuelle Festplatte
                │
        PV – Physical Volume
                │
        VG – Volume Group
          ┌─────┴─────┐
          │           │
       LV Daten     LV System
          │           │
      ext4/XFS     ext4/XFS
          │
       Dateien

Schicht	Was sie darstellt	Typisches Beispiel
Physisches Gerät	Festplatte, RAID oder virtuelle Festplatte	/dev/sdb, /dev/md0, /dev/mapper/mpatha
PV	Für LVM markiertes Gerät	/dev/sdb2
VG	Gemeinsamer Bereich aus einem oder mehreren PVs	vg_server
LV	Logisches Blockvolume, erstellt innerhalb einer VG	vg_server/data
Dateisystem	Dateistruktur innerhalb des LV	ext4, XFS, btrfs

Daraus ergeben sich zwei Dinge, die im Krisenfall beide entscheidend sind. Ein LV kann über mehrere Festplatten verteilt liegen — der Verlust eines einzigen PV beschädigt daher typischerweise mehrere logische Volumes gleichzeitig, nicht nur das „auf der defekten Platte”. Und umgekehrt: Ein fehlendes LV muss keineswegs zerstörte Daten bedeuten. LVM findet das Gerät oft nur deshalb nicht, weil es umbenannt wurde, wegen eines Filters in lvm.conf, wegen Multipath oder wegen der über lvmdevices verwalteten Geräteliste.

LVM selbst bietet keine Ausfallsicherheit gegenüber einem Festplattendefekt — es sei denn, Sie verwenden eine redundante Variante, also LVM RAID. Liegt unter LVM ein klassisches Linux-MD-RAID oder ein Hardware-Controller, muss zuerst die darunterliegende Schicht korrekt zusammengesetzt werden; erst danach ergibt es Sinn, sich um PV und VG zu kümmern. Warum ein Rebuild eines degradierten Arrays nicht ohne Kopie auskommt, erklären wir im Artikel warum ein Rebuild ein RAID-Array zerstört, das gesamte Vorgehen beim Server im Text zur Datenrettung von einem Server.

Was Menschen als „kaputtes LVM” bezeichnen

Dasselbe Symptom kann mehrere unterschiedliche Ursachen haben — und jede erfordert ein anderes Vorgehen:

Symptom	Wahrscheinlicher Problembereich
VG wird überhaupt nicht angezeigt	Fehlendes PV, beschädigter LVM-Header, Gerätefilter
VG ist partial	Ein oder mehrere PVs sind nicht verfügbar
LV existiert, lässt sich aber nicht aktivieren	Fehlende Extents, beschädigter Thin Pool oder UUID-Konflikt
LV aktiviert sich, lässt sich aber nicht einhängen	Problem des Dateisystems, nicht zwingend von LVM
Thin Pool meldet einen Metadatenfehler	Beschädigte Metadaten des Thin Provisioning
Snapshot hat den Status Invalid	Der reservierte COW-Bereich des klassischen Snapshots ist voll
Nach einer Migration fehlen Festplatten	Pfade, Multipath oder die Liste zulässiger Geräte haben sich geändert
Nach dem Klonen gibt es doppelte PVs	Original und Klon mit derselben LVM-UUID hängen gleichzeitig im System

Entscheidend ist die Grenze zwischen drei Arten von Metadaten, denn genau hier entstehen die meisten fatalen Fehler:

• VG-Metadaten beschreiben PVs, LVs und deren Mapping.
• Thin-Pool-Metadaten erfassen, welche Blöcke zu welchem Thin-Volume gehören.
• Metadaten von ext4, XFS oder btrfs beschreiben Dateien und Verzeichnisse.

vgcfgrestore greift nur auf die erste Schicht zu. Es repariert weder den Thin Pool noch erst recht das Dateisystem. Wer sich dessen nicht bewusst ist, „repariert” LVM und wundert sich, dass sich das Volume immer noch nicht einhängen lässt.

Sichere Diagnose: Was man sich ausgeben lassen sollte

Die folgenden Befehle lesen nur den Zustand aus. Speichern Sie die Ausgabe außerhalb des betroffenen Speichersystems:

lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MODEL,SERIAL
blkid
pvs -o pv_name,pv_uuid,vg_name,pv_size,pv_free,pv_attr,devices
vgs -o vg_name,vg_uuid,vg_attr,vg_size,vg_free,pv_count
lvs -a -o lv_name,vg_name,lv_uuid,lv_attr,segtype,devices,data_percent,metadata_percent
dmesg -T

Achten Sie vor allem auf:

• die UUID, die in der Fehlermeldung auftaucht — und auf welchem Gerät sie (nicht) passt,
• unknown device oder das Attribut partial bei der VG,
• I/O-Fehler, Resets von SATA/SAS-Geräten und Meldungen über defekte Blöcke in dmesg,
• die Werte Data% und Meta% beim Thin Pool,
• den LV-Typ: linear, striped, raid, thin, thin-pool oder snapshot.

Der letzte Punkt entscheidet über die Chancen. Ein fehlendes PV unter einem linear-LV bedeutet ein Loch in den Daten, aber der Rest des Volumes kann lesbar sein. Bei einem striped-LV ist jede Datei über mehrere Platten verteilt — ein fehlendes PV bedeutet, dass in jeder größeren Datei regelmäßig wiederkehrende Blöcke fehlen.

Schauen Sie auch in /etc/lvm/backup/ und /etc/lvm/archive/. Dort liegen Textsicherungen der VG-Konfiguration, die LVM bei jeder Änderung automatisch schreibt. Sie enthalten weder Benutzerdaten noch Thin-Pool-Metadaten — nur die Landkarte.

Und Vorsicht bei einem Punkt: Hat die Festplatte physische Fehler, kann jeder weitere Scan die Zahl der unlesbaren Sektoren erhöhen. In diesem Fall wird kontrolliert gelesen, etwa mit dem Tool GNU ddrescue, das mit einer Mapping-Datei arbeitet und einen unterbrochenen Lesevorgang fortsetzen kann. Ziel muss eine andere, ausreichend große Festplatte oder ein Image sein. Die Zusammenhänge rund um physisch beschädigte Datenträger erläutert der Text wie man Daten von einer beschädigten Festplatte rettet.

Entscheidungsablauf nach Fehlertyp

Gibt es I/O-Fehler auf der Festplatte?
├─ ja → Sektorkopie → nur mit der Kopie arbeiten
└─ nein
   ├─ ganzes PV fehlt → Gerät, RAID, Multipath und UUID prüfen
   ├─ PV ist sichtbar, VG nicht → LVM-Header und Metadatenarchiv prüfen
   ├─ VG ist partial → ermitteln, welche Extents auf dem fehlenden PV lagen
   ├─ Thin Pool lässt sich nicht aktivieren → Thin-Pool-Metadaten getrennt behandeln
   └─ LV funktioniert → Dateisystem ohne Schreibzugriff prüfen

Das Gerät ist verschwunden, aber die Festplatte ist in Ordnung

Der häufigste „LVM-Zusammenbruch”, der gar keiner ist. Nach einem Systemupdate, der Migration einer virtuellen Maschine oder einer Änderung am SAN sucht LVM die richtige UUID auf einem Pfad, an dem sie nicht mehr liegt. Geprüft werden Multipath, die Filterung in lvm.conf, die über lvmdevices verwaltete Geräteliste (Standard seit LVM2 Version 2.03.17) sowie die Frage, ob der Hypervisor überhaupt alle virtuellen Festplatten angebunden hat.

Das Schreiben einer reparierten LVM-Struktur ist hier überflüssig und gefährlich. Die Daten sind nirgendwohin verschwunden — das System durchsucht nur nicht das richtige Gerät.

Der LVM-Header ist beschädigt

Existiert die richtige archivierte Konfiguration, lässt sich auf einer Arbeitskopie zunächst die ursprüngliche PV-UUID und anschließend die VG-Metadaten wiederherstellen:

pvcreate --uuid <URSPRÜNGLICHE_PV_UUID> \
  --restorefile <KORREKTES_VG_ARCHIV> <GERÄT_DER_KOPIE>

vgcfgrestore --file <KORREKTES_VG_ARCHIV> <VG_NAME>

Beide Befehle schreiben Daten. Ein falsches Gerät, eine falsche UUID oder ein Archiv aus einem anderen Zeitraum können genau das überschreiben, was Sie für die Wiederherstellung brauchen. Führen Sie sie nicht auf dem einzigen Original aus.

Und vor allem: Die Wiederherstellung des Headers bringt den Inhalt einer verlorenen Festplatte nicht zurück. Ein PV mit derselben UUID auf einer leeren Festplatte anzulegen bedeutet, die Kennzeichnung und die Landkarte wiederherzustellen, nicht die Daten-Extents. Eine Landkarte ohne Gebiet.

Die VG ist nur teilweise verfügbar

Die Aktivierung im partial-Modus macht jene LVs zugänglich, deren benötigte Extents erhalten geblieben sind. Bei einem LV, das sich über ein fehlendes PV erstreckt, sind einige Blöcke unlesbar — das Ergebnis sind beschädigte Dateien und weitere Dateisystemfehler.

Ist die teilweise Aktivierung für die Extraktion notwendig, erfolgt sie auf Kopien, und das Volume wird nur lesend eingehängt, mit unterdrückter Journal-Wiedergabe: bei ext4 über ro,noload, bei XFS über ro,norecovery. Ein einfaches mount -o ro stoppt bei manchen Dateisystemen das Schreiben ins Journal nicht.

Ein Snapshot ist kein Backup

Ein klassischer LVM-Snapshot speichert die ursprüngliche Form der Blöcke, die sich nach seiner Erstellung verändert haben — das sogenannte Copy-on-Write-Verfahren. Sobald der reservierte COW-Bereich aufgebraucht ist, wird der Snapshot ungültig. Das ursprüngliche LV wird dadurch allein nicht zerstört, aber den Snapshot können Sie dann nicht mehr als Wiederherstellungspunkt nutzen.

Thin-Snapshots funktionieren anders: Sie teilen sich Blöcke im Thin Pool und hängen sowohl von dessen Daten- als auch von dessen Metadatenkapazität ab. Die Metadaten-LV des Thin Pools ist meist um Größenordnungen kleiner als der Datenteil — und ihre Beschädigung oder Auslastung kann ein gewaltiges Datenvolumen auf einen Schlag betreffen. Das ist das unangenehme Missverhältnis, weshalb es sinnvoll ist, Meta% genauso sorgfältig im Auge zu behalten wie Data%.

Zur Kontrolle der Thin-Pool-Metadaten dienen thin_check und thin_dump aus dem Werkzeugpaket des Device-Mappers. Der Befehl:

lvconvert --repair <VG>/<THIN_POOL>

erstellt eine reparierte Kopie der Metadaten und setzt sie bei Erfolg anstelle der ursprünglichen ein. Das ist ein verändernder Vorgang. Er gehört auf eine Kopie des Speichers, nicht auf das einzige Produktivexemplar. Und selbst ein erfolgreich wiederhergestellter Pool garantiert nicht, dass die Dateisysteme innerhalb der Thin-Volumes konsistent sind.

Noch eine Falle: vgcfgbackup sichert die Thin-Pool-Metadaten nicht. Deshalb reicht bei Thin Provisioning die reine Datei aus /etc/lvm/archive/ nicht aus — Sie haben die Landkarte der VG, aber nicht die Landkarte der Blöcke innerhalb des Pools.

Wann Sie die Wiederherstellung nicht mehr selbst versuchen sollten

Ein professioneller Eingriff ist sinnvoll, wenn:

• eine Festplatte I/O-Fehler meldet oder sich abmeldet,
• die VG auf mehreren PVs steht und eines davon fehlt,
• unter LVM ein zerstörtes RAID liegt,
• Sie nicht wissen, welches Metadatenarchiv der letzten funktionierenden Konfiguration entspricht,
• es sich um einen Thin Pool mit beschädigten Metadaten handelt,
• bereits jemand pvcreate, vgcfgrestore, lvconvert --repair oder eine Dateisystemreparatur ausgeführt hat,
• die Daten einen höheren Wert haben als die Ausfallzeit und Versuche nach dem Prinzip Versuch und Irrtum.

Der Preis richtet sich nicht nach der Kapazität des LV, sondern nach der Schicht des Fehlers, der Anzahl der Datenträger, ihrem physischen Zustand und danach, wie viel Mapping rekonstruiert werden muss. Ein seriöses Angebot trennt Diagnose, Arbeit mit defekten Datenträgern, LVM-Rekonstruktion und Zielspeicher für die geretteten Daten. Eine allgemeine Übersicht zur Preisgestaltung finden Sie im Artikel was die Datenrettung von einer Festplatte kostet.

Erkennungsmerkmal eines guten Anbieters: Er erstellt zuerst Kopien, kann die Reihenfolge RAID → LVM → Thin Pool → Dateisystem erklären und schreibt ausschließlich in Arbeits-Images. Lassen Sie sich vor der Wiederherstellung den Umgang mit den Daten, die Möglichkeit einer NDA, die Art der Übergabe bestätigen sowie, ob Sie eine Liste der tatsächlich verifizierten Dateien erhalten — nicht nur eine Rechnung für einen „Versuch”.

Wie sich das Risiko eines weiteren Zusammenbruchs verringern lässt

• Sichern Sie /etc/lvm/backup/, /etc/lvm/archive/ sowie die Ausgaben von pvs, vgs und lvs außerhalb des jeweiligen Servers. Eine Textdatei von wenigen Kilobyte kann darüber entscheiden, ob die Rekonstruktion eine Stunde oder eine Woche dauert.
• Überwachen Sie die Kapazität der VG sowie die Werte Data% und Meta% des Thin Pools — ein voller Thin Pool ist keine Warnung, sondern ein Ausfall.
• Ersetzen Sie ein Backup nicht durch einen Snapshot. Der Snapshot liegt in derselben VG und fällt mit ihr aus.
• Testen Sie die Dateiwiederherstellung auf einem anderen Server, nicht auf dem ursprünglichen.
• Dokumentieren Sie die Speicherschichten: Controller, RAID, LUKS-Verschlüsselung, PV, VG, LV und Dateisystem. Wenn es brennt, werden Sie sich nicht mehr daran erinnern.
• Bewahren Sie Recovery-Schlüssel und Verschlüsselungskonfiguration getrennt vom Server auf — bei einem verschlüsselten Volume ohne Schlüssel hilft auch ein perfekt wiederhergestelltes LVM nicht.
• Sichern Sie bei virtuellen Servern auch die Konfiguration der virtuellen Festplatten, nicht nur den Inhalt des Betriebssystems.

Häufig gestellte Fragen

Lässt sich LVM ohne eine Datei aus /etc/lvm/backup/ wiederherstellen?

Manchmal ja. Kopien der VG-Metadaten werden auch im Metadatenbereich der verfügbaren PVs gespeichert und lassen sich mit LVM-Werkzeugen daraus auslesen. Ohne die korrekte Landkarte ist die Rekonstruktion jedoch deutlich riskanter — besonders bei mehreren Festplatten und striped LVs, wo Reihenfolge und Offsets eine Rolle spielen.

Löscht pvcreate Daten?

Die normale Verwendung schreibt neue LVM-Header und -Metadaten, überschreibt also die Kennzeichnung des Volumes. Die Recovery-Variante mit exakter UUID und korrektem --restorefile ist direkt für die Rekonstruktion eines PV gedacht, kann die Wiederherstellung aber bei einer fehlerhaften Konfiguration beschädigen. Führen Sie sie nicht auf dem einzigen Original aus.

Kann ich fsck verwenden, wenn sich das LV nicht einhängen lässt?

Prüfen Sie zuerst, ob das LV vollständig und korrekt gemappt ist. fsck repariert das Dateisystem, nicht LVM. Bei einem unvollständigen LV kann es Verweise auf Daten entfernen, die nur momentan nicht verfügbar sind — und macht damit aus einem vorübergehenden Problem ein dauerhaftes.

Was bedeutet Volume group is missing PV?

Die VG erwartet ein physisches Volume mit einer bestimmten UUID, das LVM nicht sieht. Die Ursache ist meist eine defekte Festplatte, ein zerstörtes RAID, eine nicht angebundene virtuelle Festplatte, eine Änderung am Multipath oder ein beschädigter PV-Header. Bevor Sie mit dem Schreiben beginnen, finden Sie heraus, welche dieser fünf Möglichkeiten zutrifft.

Rettet ein LVM-Snapshot Daten?

Ein Snapshot stellt einen älteren Zustand der Blöcke wieder her, solange er gültig bleibt und solange der zugrunde liegende Speicher funktioniert. Er schützt weder vor dem Verlust von Festplatten noch vor der Beschädigung der gesamten VG noch vor dem Ausfall des Thin Pools — deshalb ersetzt er kein separates Backup.