Eine Platte war weg – und keiner hat es gemerkt

Ausgangslage

Auf dem Verbund liegen unsere Haushaltsdokumente und die Sicherungen. RAIDZ1 verkraftet den Ausfall genau einer Platte – und genau diese eine war bereits weg. Der Verbund lief also seit unbekannter Zeit ohne jedes Sicherheitsnetz, ohne dass ich je eine Meldung bekommen hätte.

Die unangenehme Erkenntnis war für mich nicht die defekte Platte, sondern die fehlende Überwachung: Ohne Benachrichtigung merkt man den ersten Plattenausfall erst beim zweiten – und dann ist es zu spät.

Vorgehen

1. Werkzeug ausschließen, bevor man der Hardware misstraut

   Abgefragt habe ich zuerst die beiden gesunden Platten als Kontrollgruppe. Erst als dort saubere Werte zurückkamen, war für mich klar: Weder Controller noch Abfragewerkzeug sind schuld. Bei der betroffenen Platte lief anschließend ein Lesetest ins Leere – sie antwortete nicht mehr.

2. Erst sichern, dann schrauben

   Vor dem Öffnen des Gehäuses habe ich die Nutzdaten und die betroffene virtuelle Maschine gesichert. Gearbeitet wird nie am einzigen Exemplar – gerade dann nicht, wenn die Redundanz schon weg ist.

3. Ursache: kein Defekt, ein Kabel

   Beim Prüfen der Verkabelung fand ich eine gelöste Steckverbindung. Nach dem erneuten Anschließen erkannte das System die Platte sofort wieder und startete die Wiederherstellung der Redundanz von allein.

4. Nachweis statt Bauchgefühl

   Nach der automatischen Wiederherstellung habe ich einen vollständigen Prüflauf über den gesamten Datenbestand gestartet. Ergebnis: keine reparierten Blöcke, keine Fehler – die Daten waren unversehrt.

5. Die eigentliche Lehre: Sicherungen einrichten

   Ein reparierter Verbund ersetzt kein Backup. Eingerichtet habe ich deshalb automatische Sicherungen mit Aufbewahrungsregeln. Mein erster Versuch schlug fehl, weil ich das Ziel versehentlich auf die Systempartition gelegt hatte und diese volllief – erkennbar an der Fehlermeldung, behoben durch Umstellen auf den dafür vorgesehenen Speicher.

6. Aufräumen

   Im gleichen Zug habe ich den Speicherverbrauch eingegrenzt und ausgemistet: veraltete Sicherungen, Zwischenspeicher und ungenutzte Abbilder. Die Systemplatte fiel dabei von 84 % auf 50 % Belegung.

Beleg

# zpool status
  pool: dokumenten
 state: ONLINE
  scan: scrub repaired 0B in 00:16:06 with 0 errors
config:

        NAME                        STATE     READ WRITE CKSUM
        dokumenten                  ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-ST4000NE0025-…-###  ONLINE       0     0     0
            ata-ST4000NE0025-…-###  ONLINE       0     0     0
            ata-ST4000NE0025-…-###  ONLINE       0     0     0

errors: No known data errors

Ergebnis

• Verbund wieder redundant, Datenbestand nachweislich unversehrt
• Wöchentliche automatische Sicherungen mit Aufbewahrungsregeln
• Systemplatte von 84 % auf 50 % Belegung
• Offener Punkt, den ich lieber benenne als verschweige: Eine Überwachung mit Benachrichtigung fehlt mir noch – sie steht als nächstes Vorhaben auf meiner Liste

Was ich daraus mitgenommen habe

• Erst die Kontrollgruppe testen. Funktioniert ein Werkzeug bei den gesunden Geräten, liegt der Fehler nicht am Werkzeug.
• „Kaputt" ist selten alles. Meist ist genau ein Glied der Kette defekt – hier ein Kabel, keine Platte.
• Ohne Überwachung merkt man den ersten Ausfall erst beim zweiten.
• Wie wichtig ein Backup wirklich ist. Vorher war das für mich ein Punkt auf der Liste, den man irgendwann mal angeht. In dem Moment, als mir klar wurde, dass der Verbund ohne Sicherheitsnetz läuft und keine Sicherung existiert, war es der einzige Punkt, der zählte. Ein RAID schützt gegen eine kaputte Platte – nicht gegen versehentliches Löschen, Feuer oder Diebstahl.