Am 7. August um 23:10 meldete der Proxmox-Host I/O-Timeouts. Kurz darauf war eine NVMe aus dem Pool verschwunden. Controller-Resets brachten sie nicht zurück. ZFS tat in diesem Moment genau das, wofür der Mirror gebaut war: Der Pool lief auf dem zweiten Datenträger degradiert weiter.
Alle Gäste waren erreichbar. Die aktuellen Sicherungen im Proxmox Backup Server waren geprüft. Ich musste also nicht zwischen Datenrettung und Ursachenanalyse entscheiden.
Erst den Zustand sichern
Ich habe zuerst festgehalten, welcher Datenträger fehlte, wie der Pool aussah und ob die Fehler weiter zunahmen. Danach wurden alle Gäste sauber heruntergefahren. Erst dann trennte ich den Host vollständig vom Strom.
I/O-Timeouts und fehlgeschlagene Controller-Resets. Eine NVMe verschwindet aus dem Mirror.
Pool-Zustand und Sicherungen werden geprüft. Die Gäste fahren kontrolliert herunter.
Die NVMe erscheint wieder. Das ist ein neuer Zustand, aber noch keine Entwarnung.
ZFS verarbeitet 133 MB und korrigiert fünf Checksum-Abweichungen.
Nach dem Neustart tauchte die NVMe wieder auf. Das ist keine Entwarnung. Ein Datenträger, der nach einer Stromtrennung zurückkehrt, hat immer noch einen Fehler gezeigt. Der Pool war anschließend wieder online, der Vorfall aber noch nicht erklärt.
event: NVMe timeout
pool: DEGRADED -> ONLINE
resilvered: 133 MB
corrected: 5 checksum discrepancies
data loss: none knownDie unmittelbare Bilanz lautete: kein Datenverlust, kein Gast aus dem Backup wiederhergestellt, keine hektische Migration auf neue Hardware. Mirror und Backups waren vorher da.
Wer schreibt hier eigentlich wie viel?
Der einfache Reflex wäre gewesen, die NVMe auszutauschen und das Thema zu schließen. Ich wollte vorher wissen, welche Last der Datenträger im Alltag sieht. Also habe ich die geschriebenen Daten pro Container über Zeit gemessen.
Ein Docker-Host lag bei ungefähr 8 GB pro Tag und war damit der deutlich größte Einzelschreiber. Darauf liefen neben wichtigen Diensten auch Anwendungen, die zu diesem Zeitpunkt keinen entsprechenden Nutzen hatten. Einige davon habe ich gestoppt und aus dem Autostart genommen.
| Beobachtung | Belegter Wert | Folge |
|---|---|---|
| Resilver | 133 MB, fünf korrigierte Checksum-Abweichungen | Pool online, Datenträger bleibt Austausch-Kandidat |
| Größter Einzelschreiber | Docker-Host, ungefähr 8 GB pro Tag | Unnötige Dienste gestoppt und aus dem Autostart entfernt |
| TRIM | autotrim lief dauerhaft | Durch wöchentlichen Pool-Timer ersetzt |
| Restore-Vertrauen | Aktuelle Einzelbackups geprüft | Vollständiger Restore-Test bleibt offen |
Auch autotrim lief dauerhaft. Das habe ich durch einen wöchentlichen Trim-Timer ersetzt. OpenZFS beschreibt automatische und periodische TRIM-Läufe als getrennte Betriebsweisen und weist darauf hin, dass dauerndes Trimmen je nach Gerät relevante Last erzeugen kann.1
Die Messung führte zu einer konkreten Änderung, statt pauschal weniger Dienste zu betreiben. Die unnötigen Writes ließen sich einem Verursacher zuordnen.
Was der Vorfall geprüft hat
Ein Homelab kann auf dem Papier sauber aussehen. Interessant wird die Architektur, wenn ein Teil wirklich ausfällt.
- Der Mirror hielt den Host verfügbar.
- Die Backups waren aktuell, bevor ich etwas am Storage änderte.
- Der kontrollierte Shutdown vermied zusätzliche Fehler.
- Das Resilver zeigte, was ZFS tatsächlich korrigieren musste.
- Die Messung danach führte zu kleineren, nachvollziehbaren Änderungen.
Die NVMe bleibt ein Austausch-Kandidat. Wieder aufgetaucht heißt nicht wieder vertrauenswürdig. Offen ist außerdem ein vollständiger Restore-Test über die ganze Kette. Einzelne Backups zu verifizieren ist wichtig, ersetzt aber keine geprobte Wiederherstellung.
Seitdem behandle ich Storage-Vorfälle in zwei Phasen: erst Stabilität und Wiederherstellbarkeit belegen, dann die Last messen, die zum Zustand beigetragen haben könnte. In dieser Reihenfolge bleibt aus einem Hardwarefehler ein kontrollierter Incident.
- OpenZFS: TRIM, automatische und periodische Ausführung sowie die geräteabhängige Last. Abgerufen am 19.08.2026. ↩