Bin ich geliefert? Der Moment, in dem ein Homelab zur Horrorgeschichte über Datenverlust wird
„Bin ich geliefert?" — Der Moment, in dem ein Homelab zur Horrorgeschichte über Datenverlust wird
Der Moment, in dem alles anfängt auseinanderzufallen
Er wusste, dass etwas nicht stimmte, in dem Moment, als der Host wieder online kam. Nicht komplett kaputt — schlimmer als das. Halb funktionierend. Die VM bootete. Dienste liefen. Aber dann kamen die Fehler, leise und beharrlich, als würde darunter bereits etwas zusammenbrechen.
Ein Stromausfall. Eine tote USV. Und plötzlich schlichen sich Lesefehler von einem NVMe-Datastore ein, der früher bombenfest war. Er versuchte, die Disk zu klonen — scheiterte bei 14 %. Versuchte, das Dateisystem zu prüfen — blockiert von einem Tool, das sein Setup schlicht nicht unterstützt.
Das ist der Moment, in dem es einen trifft: kein Absturz, kein sauberer Fehler — nur die langsame Erkenntnis, dass man vielleicht feststeckt.
Die grausamste Version davon ist die, die man nie kommen sieht: ein Backup-Job, der schon vor Monaten aufgehört hat zu laufen und es nie gemeldet hat. Eine konventionelle Uptime-Prüfung erkennt das nicht, weil der Server läuft. Eine Push-basierte Prüfung schon — siehe 5 kostenlose Uptime-Monitoring-Dienste für den Unterschied zwischen dem Abfragen von etwas und dem Warten darauf, dass es sich meldet.
Das Tool, das Sie eigentlich retten sollte … funktioniert nicht
Es gibt etwas einzigartig Frustrierendes daran, das richtige Tool zu haben — und es trotzdem nicht benutzen zu können.
Er tat, was jeder sorgfältige Admin tun würde: Datastore aushängen, VOMA laufen lassen, auf Beschädigung prüfen. Nur dass VOMA sich weigert, NVMe-basiertes VMFS überhaupt anzufassen. Kein Workaround. Kein verstecktes Flag. Nur eine Sackgasse.
Und der offizielle Rat? Metadaten dumpen und an den Support schicken.
Das könnte funktionieren — wenn man zahlender Enterprise-Kunde ist. Aber für Nutzer mit kostenloser Lizenz landet dieser Vorschlag anders. Er fühlt sich weniger wie Anleitung an und mehr wie eine Erinnerung: Sie sind auf sich allein gestellt.
Manche zucken nur mit den Schultern. „Das ist eben der Deal bei kostenlosen Tiers", könnte eine Stimme sagen. Andere sehen darin etwas Schlimmeres — ein stilles Im-Stich-Lassen der Enthusiasten-Community, die das Ökosystem überhaupt erst mit aufgebaut hat.
„Es ist wahrscheinlich die Disk … und das ist das Problem"
„Das ist ein Lesefehler. Die SSD konnte die Daten nicht wiederherstellen." Das ist die Übersetzung des NVMe-Statuscodes. Kein Mysterium. Kein Software-Bug. Nur Hardware, die nicht liefert, was von ihr verlangt wurde.
Und plötzlich verschiebt sich die Erzählung. Hier geht es nicht mehr um VMware. Es geht um Entscheidungen, die früher getroffen wurden — Consumer-NVMe-Laufwerke, kein Power-Loss-Schutz, vielleicht ein paar unsaubere Shutdowns zu viel.
Eine Perspektive ist fast klinisch: „Sichern Sie, was Sie können, und machen Sie weiter."
Eine andere ist reflektierter. Consumer-Laufwerke jagen Benchmarks, nicht Integrität. Schnelle Zahlen sehen toll aus — bis der Strom ausfällt und die Daten darunter den Schlag nicht überleben.
Trotzdem sind nicht alle einer Meinung, dass es so einfach ist. Manche argumentieren, dass sogar Enterprise-Setups unter den richtigen Bedingungen ausfallen können. Hardware ist nicht perfekt. Aber die Fehlermarge ist eine ganz andere.
Das versteckte Risiko von „Es funktioniert doch"
Hier kommt der Teil, der fast grausam wirkt: Die VM funktioniert noch.
Sie bootet. Dienste laufen. Nichts ist offensichtlich kaputt. Genau diese Illusion von Stabilität macht es gefährlich. Denn darunter schlagen Lesevorgänge fehl. Blöcke sind unzuverlässig. Und der nächste Zugriff könnte der sein, der endgültig alles zerstört.
Eine Stimme brachte es perfekt auf den Punkt: „Es ist ein Segen, dass Sie noch darauf zugreifen können — sichern Sie es also, bevor Sie irgendetwas anderes tun."
Das ist die Kluft.
Manche sehen darin eine wiederherstellbare Situation — Daten rausholen, neu aufbauen, weitermachen. Andere sehen eine tickende Zeitbombe, bei der jede zusätzliche Minute Troubleshooting die Chance erhöht, alles zu verlieren.
Und dann gibt es noch eine dritte Perspektive: Neugier. Der Wunsch zu verstehen, was schiefgelaufen ist, selbst wenn der sicherste Zug wäre, aufzuhören zu graben.
Die Konfiguration, die den Schaden vervielfachte
Dann kommt die schmerzhafte Erkenntnis.
Zwei SSDs. Ein Datastore. Zusammengespannt, um sich keine Gedanken über die Platzierung machen zu müssen. Es fühlte sich damals effizient an. Sauber. Flexibel.
Aber jetzt? Diese Design-Entscheidung verstärkt das Problem. Ein Fehler bleibt nicht isoliert — er breitet sich über den gesamten Datensatz aus. Was ein eingedämmtes Problem hätte sein können, wird systemisch.
„Verwenden Sie niemals VMFS-Extents", warnt jemand. Nicht, weil sie kaputt sind, sondern weil sie den Blast Radius vergrößern, wenn unweigerlich etwas schiefgeht.
Das ist eine dieser Lektionen, die erst hängen bleiben, nachdem sie wehgetan haben.
Trotzdem gibt es hier Nuancen. Manche argumentieren, Extents seien in Ordnung, wenn man die Risiken versteht und entsprechend plant. Andere behandeln sie wie eine Falle, die nur darauf wartet zuzuschnappen.
Die stille Realität, ein Homelab zu betreiben
Irgendwann verblassen die technischen Details, und etwas Menschlicheres übernimmt.
Er gibt es selbst zu — es gab Warnsignale. Die USV war nicht ideal. Die Shutdowns waren nicht immer sauber. Die Hardware war keine Enterprise-Klasse. Aber genau das sind Homelabs: Kompromisse. Experimente. Abwägungen zwischen Kosten und Zuverlässigkeit.
Und meistens funktionieren diese Abwägungen. Bis sie es nicht mehr tun.
Das ist die eigentliche Geschichte hier. Nicht nur eine ausgefallene Disk oder eine fehlende Funktion — sondern das fragile Gleichgewicht zwischen „gut genug" und „einen Fehler entfernt davon, alles zu verlieren".
Denn am Ende hat die Frage „Bin ich geliefert?" keine saubere Antwort.
Es hängt davon ab, was Sie gesichert haben. Und was nicht.