Die Disk war wieder da. Der Incident war nicht vorbei.

Sichtbare Erholung ist noch keine Gewissheit#

In einem ZFS-Mirror fiel ein NVMe-Datenträger aus. Es kam zu keinem Datenverlust. Später erschien der Datenträger wieder. Das war ein positives Signal, aber kein ausreichender Grund, den Incident als beendet zu betrachten.

Die Rückkehr einer Komponente beantwortet zunächst nur eine enge Frage: Ist sie gerade wieder sichtbar? Sie beantwortet nicht automatisch, ob der Zustand des Gesamtsystems verstanden ist, ob die Absicherung greift oder ob die Bedingungen, unter denen der Ausfall beobachtet wurde, ausreichend untersucht sind.

Recovery einer Komponente ist nicht dasselbe wie Recovery des Vertrauens.

Vertrauen entsteht dabei nicht durch ein einzelnes beruhigendes Signal. Es entsteht aus mehreren überprüften Aussagen über Daten, Wiederherstellbarkeit und Betrieb. Solange eine dieser Aussagen offen ist, bleibt auch die Bewertung des Incidents offen. Das sichtbare Symptom kann verschwunden sein, ohne dass die technische Unsicherheit verschwunden ist.

Erst den Zustand sichern#

Der erste Schritt bestand darin, den Zustand zu sichern. Das ist wichtig, weil jede weitere Aktion die beobachtbare Lage verändern kann. Wer sofort korrigiert, verliert möglicherweise genau die Informationen, die später für eine belastbare Einordnung gebraucht werden.

Danach wurden die Backups geprüft. Kein Datenverlust im Mirror ist eine wichtige Feststellung, ersetzt aber nicht die Prüfung der unabhängigen Absicherung. Ein Incident betrifft nicht nur die aktuell sichtbaren Daten, sondern auch die Fähigkeit, einen belastbaren Zustand wiederherzustellen, falls sich die Lage verschlechtert.

Auch der laufende Betrieb wurde geprüft. Ein System kann oberflächlich erreichbar sein und dennoch in einem Zustand arbeiten, der weitere Aufmerksamkeit erfordert. Deshalb gehört die Betriebsprüfung neben die Daten- und Backup-Prüfung, nicht hinter eine vorschnelle Entwarnung.

Analyse nach der Absicherung#

Erst nachdem Zustand, Backups und Betrieb geprüft waren, wurde die Schreiblast analysiert. Diese Reihenfolge trennt zwei Aufgaben: Zuerst wird verhindert, dass Unsicherheit in einen unkontrollierten Zustand übergeht. Danach wird untersucht, welche Belastung im System wirksam war.

Die Analyse der Schreiblast führte zu gezielten Korrekturen. Mehr lässt sich aus dem dokumentierten Stand nicht seriös ableiten. Es gibt hier keine belegte konkrete Hardwareursache, keine veröffentlichten SMART-Werte und keine Grundlage für erfundene Poolnamen oder Kommandos.

Diese Begrenzung ist Teil einer sauberen Incident-Dokumentation. Eine plausible Geschichte über die Ursache wäre leichter zu erzählen, aber sie würde Gewissheit vortäuschen, die der belegte Ablauf nicht liefert.

Wann ein Incident wirklich weiter ist#

Ein Incident ist nicht allein deshalb abgeschlossen, weil das auffälligste Symptom verschwunden ist. Der technische Zustand muss gesichert, die Wiederherstellbarkeit geprüft und der laufende Betrieb verstanden sein. Danach kann Analyse gezielte Änderungen begründen.

In diesem Fall war das Wiedererscheinen der NVMe ein Ereignis innerhalb der Untersuchung, nicht ihr Endpunkt. Der Abschluss lag in der wiedergewonnenen Gewissheit: kein Datenverlust, geprüfte Backups, geprüfter Betrieb, analysierte Schreiblast und daraus abgeleitete Korrekturen.

Die praktische Lehre ist knapp. Wenn eine Komponente zurückkommt, ist die erste Frage nicht, ob man Entwarnung geben kann. Die erste Frage ist, welche Unsicherheit noch übrig ist.

Diese Frage verändert den Maßstab für Recovery. Nicht die bloße Anwesenheit der Komponente zählt, sondern die Menge der wieder belegbaren Aussagen über das System. Erst diese Aussagen machen aus Erholung wieder belastbare Gewissheit.