Warum Proxmox-Umgebungen eigene Regeln haben
Proxmox VE ist ein Debian-System mit eigenem Kernel, das virtuelle Maschinen über KVM und QEMU betreibt und Container über LXC. Der Hypervisor selbst ist selten das Problem. Entscheidend ist die Speicherart darunter, denn sie bestimmt, wo eine virtuelle Festplatte physisch liegt und welche Metadaten für den Zugriff nötig sind. Wie sich das in die übrigen Ebenen einordnet, zeigt unsere Übersicht zur Datenrettung virtueller Maschinen.
Zum Stand der Technik: Aktuell ist Proxmox VE 9.2 vom Mai 2026 auf Debian 13 mit QEMU 11 und ZFS 2.4. Die 9er-Reihe begann im August 2025, der letzte Stand der 8er-Reihe war 8.4 vom April 2025. Wichtig für den Schadensfall: Seit Version 9.0 sind Snapshots als Volume-Ketten auch auf LVM über SAN sowie auf NFS und CIFS möglich, was vorher nicht ging. Wer von einer 8er-Installation kommt, hat also unter Umständen eine andere Snapshot-Mechanik vor sich als der Nachbar.
Die vier Speicherarten und wo Ihre Daten liegen
| Speicherart | Wo die virtuelle Platte liegt | Snapshots | Typischer Ausfall |
|---|---|---|---|
| LVM-thin | logisches Volume im Thin Pool, keine Datei | ja | Metadaten des Pools defekt, Pool aktiviert nicht mehr |
| ZFS | zvol im Pool, keine Datei | ja, ohne Kopie | Pool degradiert oder importiert nicht |
| Verzeichnis (ext4, XFS) | Datei vm-<ID>-disk-<N>.qcow2 oder .raw | nur bei qcow2 | Dateisystem beschädigt oder Datei gelöscht |
| Ceph RBD | Image, verteilt als Objekte über die Knoten | ja | Monitore ohne Quorum oder zu viele OSDs ausgefallen |
| NFS und CIFS | Datei auf einem entfernten Speicher | seit Version 9 möglich | Freigabe nicht eingebunden, Disks scheinbar verschwunden |
Der Unterschied ist praktisch bedeutsam: Bei einem Verzeichnisspeicher lässt sich die virtuelle Platte im günstigen Fall als Datei sichern. Bei LVM-thin und ZFS gibt es keine Datei, sondern ein Blockgerät, dessen Zuordnung vollständig in den Metadaten des Pools steckt. Bei Ceph liegen die Daten in kleinen Objekten über den Cluster verteilt, und ohne die Zuordnung des Clusters ist nicht bekannt, welches Objekt wohin gehört.
Innerhalb der virtuellen Festplatte kommt dann noch das Dateisystem des Gastes hinzu, meist NTFS, ext4 oder XFS. Liegen die darunterliegenden Laufwerke selbst im Argen, geht die Reparatur im Reinraum allem anderen voraus: Erst wenn ein Laufwerk stabil liest, hat eine Rekonstruktion Sinn.
- Eigenes Reinraumlabor & Ersatzteillager
- 95% Datenrettungsgarantie
- Qualitätssicherung nach ISO 9001:2015
- Diskretion & Datenschutz nach DSGVO
- Persönlicher Ansprechpartner
Datenrettung anfragen
Fehlerbilder und was sie tatsächlich bedeuten
Die folgenden Meldungen sehen Administratoren im Task-Log der Weboberfläche, in journalctl oder auf der Konsole. Sie sagen mehr über den Fall aus als jede Beschreibung, deshalb halten Sie den genauen Wortlaut bitte fest, bevor Sie irgendetwas unternehmen.
| Meldung | Was dahintersteckt | Erste Maßnahme |
|---|---|---|
| activating LV 'pve/vm-100-disk-0' failed | Das logische Volume lässt sich nicht aktivieren, meist wegen des Thin Pools darunter | Keine Reparatur starten, Zustand sichern |
| Check of pool ... failed. Manual repair required! | Die Metadaten des Thin Pools sind beschädigt | Auf keinen Fall blind reparieren, siehe unten |
| device-mapper: thin: 253:2: switching pool to read-only mode | Der Kernel hat den Pool stillgelegt, meist nach vollem Metadatenbereich | Host nicht neu starten, Platz schaffen hilft hier nicht mehr |
| The pool metadata is corrupted and cannot be opened. | ZFS findet keine gültigen Pool-Metadaten mehr | Keinen Import mit Rewind versuchen, zuerst klonen |
| zpool status meldet DEGRADED oder FAULTED | Ein oder mehrere Laufwerke fehlen, bei FAULTED reichen die Repliken nicht mehr | Kein Resilver, keinen Plattentausch starten |
| qcow2: Image is corrupt; cannot be opened read/write | QEMU hat die Abbilddatei als beschädigt markiert | VM nicht erneut starten, Datei unverändert sichern |
| directory is expected to be a mount point but is not mounted | Eine NFS- oder CIFS-Freigabe fehlt. Die Disks sind nicht gelöscht, nur unerreichbar | Freigabe prüfen, nichts neu anlegen |
| cluster not ready - no quorum? | Der Cluster hat keine Mehrheit, /etc/pve ist nur lesbar | Keine Knoten entfernen, keine Konfiguration erzwingen |
| mon.a ... is down (out of quorum) | Ceph-Monitore fehlen, der Cluster kann keine Zuordnung liefern | OSDs unangetastet lassen |
| 78/3778 unfound (2.065%) | Ceph fehlen Objekte, für die kein vollständiges Replikat existiert | Keine Objekte als verloren markieren |
Was den Schaden vergrößert
Fast alle aussichtslosen Fälle, die uns erreichen, sind nicht durch den ursprünglichen Ausfall entstanden, sondern durch die Reaktion darauf. Diese Eingriffe sind die häufigsten und die folgenreichsten:
- Den Thin Pool blind reparieren. Die Reparatur ersetzt den Metadatenbereich durch eine rekonstruierte Kopie. Die alten Metadaten bleiben nur erhalten, wenn dafür Platz vorhanden ist. Ohne vorherige Sicherung ist der einzige Zeuge weg.
- Einen ZFS-Pool mit Rewind importieren. Die Dokumentation ist hier ungewöhnlich deutlich: verworfene Transaktionen sind unwiederbringlich verloren, und die weitergehende Variante wird als äußerst gefährlich und letztes Mittel bezeichnet.
- Auf einem degradierten Pool ein Resilver starten. Das bedeutet Volllast auf allen verbleibenden Laufwerken, und genau die sind meist gleich alt und gleich belastet.
- Eine Abbilddatei am Original reparieren lassen. Die QEMU-Dokumentation weist selbst darauf hin, dass die automatische Korrektur das Risiko birgt, die falsche Reparatur zu wählen oder eine bereits eingetretene Beschädigung zu verdecken.
- Ceph beruhigen wollen. Fehlende Objekte als verloren zu markieren oder die Mindestzahl der Repliken auf eins zu setzen, macht den Cluster wieder schreibfähig und die Daten endgültig weg. Die Ceph-Dokumentation warnt davor ausdrücklich.
- Aufräumvorgänge auf einem beschädigten Backup-Speicher laufen lassen. Die Bereinigung entfernt Datenblöcke, auf die keine Indexdatei mehr verweist. Sind Indexdateien beschädigt, verschwinden damit auch noch intakte Daten.
- Eine VM mit derselben ID neu anlegen. Die neuen Volumes tragen denselben Namen und belegen genau den Platz, der gerade freigegeben wurde.
- Den Knoten neu starten. Damit gehen Laufzeitzustand und ein eventuell noch offener Zugriff auf ein bereits gelöschtes Volume verloren. Beim Start führen ZFS und LVM zudem eigene Aktionen aus.
Sofortmaßnahmen: die ersten dreißig Minuten
- Betroffene VMs und Container anhalten, den Knoten aber nicht neu starten
- Backup- und Replikationsaufträge deaktivieren, ebenso Scrub, Balancing und automatische Bereinigung
- Den genauen Wortlaut der Meldungen sichern: Task-Log,
journalctl,zpool status,ceph -s - Bei Verdacht auf gelöschte Daten den Speicher aushängen, statt weiterzuarbeiten
- Keinen Reparaturbefehl ausführen, der Metadaten schreibt
- Uns anrufen, bevor der zweite Versuch beginnt
Wenn Sie uns anrufen, helfen uns diese Angaben am meisten: Speicherart, Anzahl und Typ der Laufwerke, ob ein Cluster im Spiel ist, die letzte Meldung im Wortlaut und was seit dem Ausfall bereits unternommen wurde. Der letzte Punkt ist der wichtigste, und er kostet Sie nichts außer Offenheit. Die telefonische Erstberatung ist kostenlos, den weiteren Ablauf haben wir gesondert beschrieben. Steht der Betrieb still, geht es über den 24h-Express-Service.
Container statt virtueller Maschine
Ein LXC-Container hat keine virtuelle Festplatte im gewohnten Sinn. Sein Wurzeldateisystem liegt je nach Speicherart als eigenes Volume im Thin Pool, als ZFS-Dateisystem oder als Abbilddatei im Verzeichnis. Für die Wiederherstellung ist das oft der einfachere Fall, weil eine Ebene weniger zu rekonstruieren ist: Es gibt kein zweites Dateisystem im Inneren, sondern direkt die Verzeichnisstruktur.
Wenn das Backup selbst betroffen ist
Der Proxmox Backup Server zerlegt Sicherungen in einzelne Datenblöcke und legt sie nur einmal ab. Das spart erheblich Platz, hat im Schadensfall aber eine Folge, die viele unterschätzen: Ein einzelner beschädigter Block kann an mehreren Sicherungen und mehreren virtuellen Maschinen gleichzeitig hängen. Meldet ein Prüflauf beschädigte Blöcke, ist die erste Maßnahme deshalb, jede Bereinigung und jeden Aufräumlauf abzuschalten, bevor irgendetwas anderes passiert.
Liegt der Backup-Speicher auf einem defekten RAID, gilt dieselbe Reihenfolge wie überall: erst die Laufwerke instandsetzen und klonen, dann lesen. Wie das abläuft, steht auf unserer Seite zur RAID-Datenrettung.
Nach der Migration von VMware
Viele Proxmox-Installationen sind in den vergangenen zwei Jahren aus einer Migration entstanden. Genau in dieser Phase häufen sich Datenverluste: Die Umgebung ist neu, die Sicherungskette noch nicht eingespielt, die alte Plattform vielleicht schon abgebaut. Falls Sie noch mitten in der Umstellung stecken und der Ausfall die Quellseite betrifft, sehen Sie sich unsere Seite zur VMware-Datenrettung an. Beide Umgebungen zusammen zu betrachten ist in dieser Situation der schnellere Weg.
Fragen und Antworten zur Proxmox-Datenrettung
Das ist zunächst eine Aussage über die Verwaltungsebene, nicht über die Laufwerke. Meist steckt der Thin Pool dahinter, dessen Metadatenbereich beschädigt oder vollgelaufen ist. Die Nutzdaten liegen in diesem Moment noch vollständig auf den Platten. Entscheidend ist, dass jetzt kein Reparaturbefehl läuft, der die Metadaten überschreibt.
Nicht ohne vorherige Sicherung. Die Reparatur schreibt einen rekonstruierten Metadatenbereich an die Stelle des alten. Gelingt sie nicht, fehlt danach die einzige verbliebene Zuordnung zwischen Volume und Datenblöcken. Sichern Sie zuerst die Datenträger vollständig, dann ist der Versuch gefahrlos.
Solange der Pool intakt genug ist und Sie eine aktuelle Sicherung haben, ist das der normale Weg. Fehlt die Sicherung, raten wir ab: Der Wiederaufbau bedeutet stundenlange Volllast auf allen übrigen Laufwerken, die meist gleich alt sind. Fällt dabei ein zweites aus, ist der Pool verloren. Sicherer ist, vorher Klone anzulegen.
Nicht zwangsläufig. Die Daten liegen weiter auf den OSDs, es fehlt die Zuordnung, welches Objekt wohin gehört. Solange keine OSD neu formatiert, entfernt oder als verloren gemeldet wurde, bestehen gute Aussichten. Genau diese drei Schritte sind es, die den Fall endgültig machen.
Es gibt keine feste Frist. Die Blöcke bleiben so lange lesbar, bis sie neu belegt werden. Deshalb zählt jeder Schreibvorgang: Legen Sie keine neue VM mit derselben ID an, deaktivieren Sie Sicherungen und Replikation, und hängen Sie den Speicher wenn möglich aus. Je eher das geschieht, desto vollständiger ist das Ergebnis.
Bei LVM-thin, ZFS und Ceph immer alle beteiligten Laufwerke, auch die scheinbar heilen. Die Zuordnung entsteht erst aus dem Zusammenspiel, eine einzelne Platte allein trägt sie nicht. Bei einem Verzeichnisspeicher reicht der Datenträger, auf dem das Dateisystem liegt. Rufen Sie im Zweifel vorher an, das erspart eine zweite Sendung.
Ihre Proxmox-Umgebung gibt keine Daten mehr frei? Schildern Sie uns kurz die Speicherart und die letzte Meldung im Wortlaut. Wir sagen Ihnen, was jetzt sinnvoll ist und was Sie unbedingt lassen sollten. Nach der Analyse erhalten Sie einen Festpreis und entscheiden erst dann. Wie sich die Kosten zusammensetzen, steht in der Übersicht; größere Umgebungen behandeln wir wie eine Server-Datenrettung, und für Microsoft-Umgebungen gibt es die Seite zur Hyper-V-Datenrettung.
