Jeder Admin kennt diese Momente: Der Pager geht um 3 Uhr nachts, der Pool ist degraded, und das letzte Backup ist „wahrscheinlich okay". Über die Jahre sammeln sich Erfahrungen an, die sich am besten als Segen formulieren lassen — weil man sie sich so sehnlich wünscht, dass ein einfacher Best-Practice-Tipp nicht mehr ausreicht.
Hier sind die gesammelten Weisheiten aus dem Rechenzentrum-Alltag. Die besten davon mit einer kurzen technischen Einordnung, der Rest als stille Gebete für den nächsten Bereitschaftsdienst.
🗄️ Storage & ZFS#
„Möge deine ECC-RAM-Errors immer correctable sein!"
ECC-RAM erkennt und korrigiert einzelne Bitfehler (Correctable Errors) im laufenden Betrieb — völlig transparent. Uncorrectable Errors hingegen bedeuten: korrupte Daten im Speicher, die ZFS möglicherweise unbemerkt auf die Platten schreibt. Gerade bei Storage-Systemen, die auf Datenintegrität setzen, ist ECC-RAM kein Luxus, sondern Grundvoraussetzung. Häufen sich die Correctable Errors, ist das ein Frühwarnsignal: Das DIMM stirbt.
„Möge in deinem RAIDZ1 nie mehr als eine Platte ausfallen!"
RAIDZ1 toleriert exakt einen Plattenausfall. Fällt während eines Resilver eine zweite Platte aus, sind die Daten unwiderruflich verloren. Bei großen HDDs dauert ein Resilver gerne 20+ Stunden — eine Ewigkeit, in der das gesamte Array auf Messers Schneide steht. Für Produktivdaten ist RAIDZ2 oder RAIDZ3 daher Pflicht.
„Möge bei einem zfs send die Übertragung nie länger dauern als die Retention des Snapshots, der gerade übertragen wird!"
Ein klassisches Replikations-Dilemma: Der inkrementelle zfs send braucht als Referenz den letzten gemeinsamen Snapshot auf Quell- und Zielseite. Wird dieser Snapshot durch die Retention-Policy gelöscht, bevor die Übertragung abgeschlossen ist, schlägt der nächste inkrementelle Send fehl — und ein teurer Full-Send wird nötig.
„Möge dein ARC Hit Ratio nie unter 90% fallen!"
Der ARC (Adaptive Replacement Cache) ist das Herzstück der ZFS-Performance. Fällt die Hit-Ratio unter 90%, bedeutet das: Zu viele Lesezugriffe gehen direkt auf die Platten. Die Folge sind spürbare Latenz-Sprünge, besonders bei Random-Read-Workloads. Mehr RAM ist hier oft die einfachste Lösung.
„Möge RAID dich nie in die Illusion wiegen, du hättest ein Backup!"
RAID schützt vor Plattenausfällen — nicht vor versehentlichem Löschen, Ransomware, fehlerhaften Firmware-Updates oder Controller-Defekten. Wer RAID mit Backup verwechselt, merkt den Unterschied erst im schlimmsten Moment.
🔒 Security#
„Möge dein Backup nie von Ransomware verschlüsselt werden!"
Moderne Ransomware sucht gezielt nach Backup-Shares und NAS-Systemen, bevor sie zuschlägt. Immutable Snapshots, Air-Gapped Backups und getrennte Credentials für Backup-Systeme sind keine Paranoia, sondern Grundvoraussetzung.
„Möge deine ZFS-Encryption-Passphrase nie verloren gehen!"
ZFS-Native-Encryption schützt Daten at rest — aber der Schlüssel oder die Passphrase ist der einzige Weg zurück. Kein Recovery, kein Backdoor, kein Vendor-Support. Wer die Passphrase verliert, hat ein perfekt verschlüsseltes, perfekt unbrauchbares Dataset. Ein sicherer Passwort-Manager und ein offline hinterlegter Recovery-Key sind Pflicht.
„Möge dein rm -rf nie das falsche Verzeichnis treffen!"
Der Albtraum jeder Admin-Karriere. Ein fehlendes Leerzeichen, eine falsch aufgelöste Variable, und rm -rf / statt rm -rf ./$DIR löscht alles. ZFS-Snapshots können hier tatsächlich retten — sofern sie existieren und nicht auf demselben Pool liegen, der gerade pulverisiert wird.
„Möge im Notfall das Passwort, das du wirklich eintippen musst, immer so kurz sein, dass du nicht verzweifelst!"
Wenn im Rechenzentrum nichts mehr geht, bleibt nur die lokale Konsole — und dort gibt es kein Copy & Paste. Kein Passwort-Manager, kein Autofill, nur eine Tastatur und ein 40-stelliges, zufallsgeneriertes Passwort auf einem Zettel. Wer schon einmal X7$k9!mP@2qL... Zeichen für Zeichen auf einem US-Tastaturlayout abtippen durfte, weiß: Ein separates, kürzeres Notfall-Passwort für die Konsole ist kein Kompromiss, sondern Überlebensstrategie.
🔧 Hardware & BIOS#
„Möge dein RAID-Controller nie seine BBU verlieren, während er schreibt!"
Die Battery Backup Unit (BBU) eines Hardware-RAID-Controllers sichert den Write-Cache bei Stromausfall. Fällt die BBU während aktiver Schreibvorgänge aus, schaltet der Controller auf Write-Through — die Performance bricht ein. Schlimmer: Bei gleichzeitigem Stromausfall droht Datenverlust im Cache.
„Möge dein HBA immer im IT-Mode laufen!"
ZFS will direkten Zugriff auf die Platten. Ein HBA im RAID-Mode (IR-Mode) versteckt die physischen Laufwerke hinter einem virtuellen Volume — und raubt ZFS damit die Möglichkeit, seine eigene Fehlerkorrektur und Redundanz zuverlässig zu steuern. IT-Mode ist bei ZFS nicht optional, sondern Voraussetzung.
📊 Monitoring#
„Möge dein Monitoring dich um 10 Uhr warnen und nicht um 3 Uhr nachts!"
Natürlich ist 10 Uhr oder 3 Uhr nachts nicht steuerbar — aber die Eskalationsstufen schon. Ein intelligentes Alerting unterscheidet zwischen „Pool degraded, aber RAIDZ2 hält" (Info, nächster Werktag) und „Zweite Platte ausgefallen" (Pager, jetzt sofort). Wer alles als Critical einstuft, wird irgendwann gar nicht mehr hinschauen.
„Möge dein Dashboard nie alles grün zeigen, während der Storage brennt!"
Ein grünes Dashboard ist nur so gut wie die Checks dahinter. Fehlt ein Health-Check oder ist der Agent abgestürzt, zeigt das Dashboard „alles okay" — weil es schlicht keine Daten hat. Monitoring-Systeme sollten auch „keine Daten" als Alarm behandeln.
📋 Weitere Weisheiten#
Nicht jeder Segen braucht eine Erklärung — manche sprechen für sich.
Storage & ZFS#
- Möge die Hot Spare immer fehlerfrei sein!
- Möge dein
zpool statusimmerONLINEzeigen! - Möge dein Scrub nie einen Fehler finden, der nicht korrigiert werden kann.
- Möge dein
zfs receivenie an einem vollen Pool scheitern! - Möge dein
zpool importnie mit „no such pool available" enden! - Möge dein
zfs set copies=2nie die einzige Redundanz sein! - Möge dein Special VDEV nie volllaufen!
- Möge dein L2ARC die Latenz senken und nicht nur Strom verbrauchen!
- Möge dein Dedup-Ratio die RAM-Kosten rechtfertigen!
Security & Ops#
- Möge deine Firewall-Regel nie
any any allowlauten! - Möge der Pentest-Bericht kürzer sein als das Inhaltsverzeichnis!
- Möge dein 2FA-Key nie verloren gehen!
- Möge dein Passwort nie in einer Klartext-Config stehen!
- Möge nichts so dauerhaft sein wie dein temporärer Fix!
- Möge dein SSH-Key nie in einem Git-Repo landen!
Backup & Recovery#
- Möge dein Restore-Test nie der Moment sein, in dem du merkst, dass Backups nicht funktionieren!
- Möge dein Monitoring dich vor dem Kunden warnen!
- Möge dein Snapshot-Retention-Plan länger halten als die Kündigungsfrist des Admins!
Hardware#
- Möge dein BIOS-Update nie im Flashvorgang abbrechen!
- Möge dein Remote Server nie nach einem Update die Boot-Reihenfolge vergessen!
- Möge deine SSD nie kurz nach Ablauf der Garantie sterben!
- Möge dein IPMI immer erreichbar sein und kein Java im Browser öffnen!
- Möge das IPMI dein Passwort mit Umlauten und Sonderzeichen genauso an den Host weiterleiten, wie du es eingegeben hast!
- Möge dein SAS-Expander nie ein Phantom-Drive melden!
Monitoring#
- Möge dein SMART-Wert
Reallocated_Sector_Ctimmer auf 0 stehen! - Möge dein Alert nie im Spam-Ordner landen!
- Möge dein Disk-Temperatur-Sensor nie lügen!
Netzwerk#
- Möge dein DNS immer auflösen!
- Möge dein MTU auf beiden Seiten gleich sein!
- Möge deine Packete auf ihrem weg nie fragmentieren!
- Möge deine Pakete nie wegen einem VPN mit unterschiedlichen MTU verloren gehen!
- Möge dein Spanning Tree nie in eine Loop laufen!
Fazit#
Hinter jedem dieser Segen steckt mindestens eine wahre Geschichte — und meistens ein Incident-Ticket. Die besten Admins unterscheiden sich nicht dadurch, dass ihnen diese Dinge nie passieren, sondern dadurch, dass sie vorbereitet sind, wenn es soweit ist.
Welcher Segen fehlt in dieser Sammlung? Welche Weisheit hat der letzte Bereitschaftsdienst hervorgebracht?
Wim Bonis ist CTO bei Stylite AG und sammelt diese Weisheiten nicht freiwillig, sondern aus Erfahrung.