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, sobald der Host wieder online kam. Komplett kaputt war nichts, und das war schlimmer: halb funktionierend. Die VM bootete, die Dienste liefen, und dann kamen leise und beharrlich die Fehler, als würde darunter schon 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, und scheiterte bei 14 %. Er versuchte, das Dateisystem zu prüfen, und wurde von einem Tool blockiert, das sein Setup schlicht nicht unterstützt.

Genau in diesem Moment trifft es einen. Es gibt keinen Absturz und keinen sauberen Fehler, nur die langsame Erkenntnis, dass man womöglich feststeckt.

Die grausamste Variante davon sieht man nie kommen: 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, und 5 kostenlose Uptime-Monitoring-Dienste zeigt den Unterschied zwischen dem Abfragen von etwas und dem Warten darauf, dass es sich meldet.

Das Tool, das Sie retten sollte, funktioniert nicht

Es ist einzigartig frustrierend, 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 weigert sich VOMA, NVMe-basiertes VMFS überhaupt anzufassen. Es gibt keinen Workaround und kein verstecktes Flag, nur eine Sackgasse.

Und der offizielle Rat lautet, die Metadaten zu dumpen und an den Support zu schicken. Als zahlender Enterprise-Kunde kann das funktionieren. Bei Nutzern mit kostenloser Lizenz kommt der Vorschlag anders an, weniger als Anleitung und mehr als Erinnerung daran, dass sie auf sich allein gestellt sind.

Manche zucken darüber nur mit den Schultern: „Das ist eben der Deal bei kostenlosen Tiers." Andere sehen darin 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." So übersetzt sich der NVMe-Statuscode. Kein Mysterium und kein Software-Bug, sondern Hardware, die nicht liefert, was von ihr verlangt wurde.

Damit verschiebt sich die Geschichte. Es geht nicht mehr um VMware, sondern um früher getroffene Entscheidungen: Consumer-NVMe-Laufwerke, kein Power-Loss-Schutz und vielleicht ein paar unsaubere Shutdowns zu viel.

Eine Perspektive darauf ist fast klinisch: „Sichern Sie, was Sie können, und machen Sie weiter."

Eine andere ist nachdenklicher. Consumer-Laufwerke jagen Benchmarks und nicht Integrität. Schnelle Zahlen sehen großartig aus, bis der Strom wegbleibt und die Daten darunter den Schlag nicht überstehen.

So einfach sehen das nicht alle. Manche halten dagegen, dass auch Enterprise-Setups unter den passenden Bedingungen ausfallen, weil Hardware nie perfekt ist. Die Fehlermarge ist dort aber eine völlig andere.

Das versteckte Risiko von „Es funktioniert doch"

Jetzt kommt der fast grausame Teil: Die VM läuft noch. Sie bootet, die Dienste laufen, und offensichtlich kaputt ist nichts. Diese Illusion von Stabilität macht die Lage 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."

Genau hier gehen die Meinungen auseinander. Manche halten die Situation für wiederherstellbar, also 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 die Neugier, den Wunsch zu verstehen, was schiefgelaufen ist, obwohl der sicherste Zug wäre, mit dem Graben aufzuhören.

Die Konfiguration, die den Schaden vervielfachte

Dann kommt die schmerzhafte Erkenntnis. Zwei SSDs, ein Datastore, zusammengespannt, damit man sich über die Platzierung keine Gedanken machen muss. Damals fühlte sich das effizient, sauber und flexibel an.

Heute verstärkt diese Design-Entscheidung das Problem. Ein Fehler bleibt nicht isoliert, er breitet sich über den ganzen Datensatz aus, und aus einem eingedämmten Problem wird ein systemisches.

„Verwenden Sie niemals VMFS-Extents", warnt jemand. Nicht weil Extents kaputt wären, 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.

Ganz so eindeutig ist es trotzdem nicht. Manche halten Extents für in Ordnung, solange man die Risiken versteht und entsprechend plant. Andere behandeln sie wie eine Falle, die nur darauf wartet zuzuschnappen.

Die leise Realität, ein Homelab zu betreiben

Irgendwann verblassen die technischen Details, und etwas Menschlicheres übernimmt.

Er gibt selbst zu, dass es Warnsignale gab. Die USV war nicht ideal, die Shutdowns nicht immer sauber, die Hardware keine Enterprise-Klasse. Genau das sind Homelabs aber: Kompromisse, Experimente und Abwägungen zwischen Kosten und Zuverlässigkeit. Meistens gehen diese Abwägungen auf, bis sie es eben nicht mehr tun.

Darin liegt die eigentliche Geschichte. Es geht um mehr als eine ausgefallene Disk oder eine fehlende Funktion, nämlich um das fragile Gleichgewicht zwischen „gut genug" und „einen Fehler davon entfernt, 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.