Bitrot & ZFS Scrubbing: Wenn Daten still verfaulen
"Bitrot" klingt nach Internet-Mythos – ist aber real, gut dokumentiert und betrifft jedes Storage-System. RAID alleine schützt nicht. Hier ist die Erklärung mit echten Wahrscheinlichkeiten und wie ZFS Scrubbing das Problem löst.
Die Kurzfassung
Bitrot ist die unbemerkte Veränderung gespeicherter Daten – einzelne Bits kippen, Sektoren werden falsch gelesen. Klassisches RAID merkt das oft nicht. ZFS (und Btrfs) berechnet beim Schreiben Checksums pro Block. Beim Scrubbing liest ZFS regelmäßig alle Blöcke, prüft die Checksum und repariert Abweichungen aus der Redundanz – die einzige zuverlässige Verteidigung gegen Bitrot.
Was Bitrot wirklich ist
Mehrere physikalische Ursachen:
Magnetisches Drift. HDD-Magnetisierung verschwächt über Jahre, kann zu Bit-Flips führen.
Cosmic Rays / TID. Hochenergetische Teilchen kippen Bits in DRAM oder Flash-Zellen. Selten, aber statistisch relevant bei großen Datenmengen.
Controller-Bugs. Firmware-Fehler in HDDs/SSDs schreiben gelegentlich falsche Daten.
Kabel- oder Stromrauschen. SATA-Übertragungsfehler bei schlechten Kabeln. Normalerweise von der Schnittstelle abgefangen, aber nicht zu 100%.
Wie häufig Bitrot wirklich vorkommt
Hersteller geben Unrecoverable Read Error (URE) Raten an: ~1 in 10^14 Bits für Consumer-Platten, 10^15 für Enterprise. Auf 16 TB übertragen heißt das:
- 16 TB ≈ 1.28 × 10^14 Bits
- Bei jedem vollständigen Lesen: ~12% Wahrscheinlichkeit eines URE bei Consumer-Platte
- Bei Enterprise: ~1.2% Wahrscheinlichkeit pro Vollscan
Das ist die untere Grenze – stille Korruption ohne Read-Error fängt gar nicht erst die HDD-Mechanik ab. Backblaze schätzt zusätzliche 0.1-0.5% pro Jahr für tatsächlich kippende Bits, die nicht als URE gemeldet werden.
Warum klassisches RAID nicht reicht
RAID 5/6 berechnet Parity, aber prüft beim Lesen nicht, ob die Daten korrekt sind. Ein gekipptes Bit auf einer Datenplatte wird mit der falschen Information weitergegeben – die Parity stimmt rechnerisch immer noch, weil sie aus den (falschen) Daten berechnet wird.
Bei einem Rebuild kann das katastrophal werden: Die fehlende Platte wird aus den anderen rekonstruiert, inklusive der gekippten Bits → korrupte Datei wird "wiederhergestellt".
mdadm, Hardware-RAID-Controller, NTFS, ext4 – alle haben dieses Problem. Sie haben kein Mittel zur Erkennung von stiller Korruption.
Wie ZFS das löst
ZFS speichert für jeden Datenblock (typisch 128 KB) einen Hash (Fletcher4 oder SHA256) im Parent-Block – nie auf derselben Platte. Beim Lesen:
- Block wird gelesen
- Hash wird neu berechnet
- Vergleich mit gespeichertem Hash
- Bei Abweichung: ZFS holt die Kopie von einer anderen Platte (RAIDZ-Parity oder Mirror), prüft diese, gibt korrekte Daten zurück, schreibt korrigierte Version
Das passiert transparent bei jedem normalen Lesen. Plus: regelmäßiges Scrubbing erzwingt das proaktiv.
Was Scrubbing macht
Ein Scrub liest alle belegten Blöcke des Pools, validiert die Checksums und repariert wo nötig. Bei normaler Betriebsweise nebenbei – keine Downtime.
Empfohlene Frequenz:
- Consumer-Platten: alle 2-4 Wochen
- Enterprise: alle 1-3 Monate
- SSDs: alle 4-8 Wochen (geringere Bitrot-Rate)
Synology DSM, TrueNAS und Proxmox haben Scrub-Scheduler eingebaut. CLI: zpool scrub tank
Btrfs als Alternative
Btrfs hat ähnliches Konzept (Datenkorruption-Erkennung via Checksums + Scrubbing). Aber: Btrfs RAID 5/6 ist seit Jahren als instabil markiert und wird in keiner aktuellen Distro empfohlen. Btrfs nur für RAID 1/10 empfohlen.
Mehr Vergleich: ZFS vs ext4 vs Btrfs.
Einrichtung in Synology DSM
DSM unterstützt Btrfs Data Scrubbing für Volume mit Btrfs:
- Storage Manager → Volume → "Data Scrubbing"
- Plan: alle 1-3 Monate
- RAID-Type: SHR/RAID-5/RAID-6 – Scrubbing wirkt
Auf RAID 1 mit ext4 hilft DSM-Scrubbing eingeschränkt, weil ext4 selbst keine Checksums hat. Block-level data scrubbing prüft nur Parity.
Einrichtung in TrueNAS
Standardmäßig automatisch alle 35 Tage. Anpassen unter Storage → Pools → Scrub Tasks. Empfehlung: alle 14-21 Tage für Heimnutzung.
Einrichtung in Unraid
Auf Unraid mit Btrfs/ZFS-Cache-Pool: scrub-Plugin verfügbar. Standardmäßig alle 7 Tage Parity-Check (das ist Plain-RAID-Style, nicht checksum-basiert).
Was Scrubbing nicht ersetzt
- Backup: Scrubbing repariert keine Daten, die bereits weg sind. Bei mehreren ausgefallenen Platten oder versehentlichem Löschen hilft nur Backup. RAID ist kein Backup.
- ECC-RAM: Wenn Bitrot im RAM passiert (vor dem Schreiben auf Disk), schreibt ZFS die korrupten Daten mitsamt korrekter Checksum. ECC-RAM verhindert das.
- Power-Schutz: Während eines Crashs kann ZFS den Pool zurückrollen, aber unsynced Writes sind weg. UPS bleibt Pflicht.
Empfehlung
Wenn dir Datenintegrität wirklich wichtig ist:
- ZFS RAIDZ2 oder ZFS Mirror als Filesystem
- ECC-RAM (10-20% Aufpreis, lohnt sich)
- USV gegen Power-Probleme
- Monatlicher Scrub-Job
- Off-Site-Backup als letzte Verteidigung
Weiterführende Artikel
RAID im Heimnetz – Kompletter Guide
Weiterführende Artikel
ZFS Verschlüsselung: Native Encryption richtig einrichten
ZFS vs ext4 vs Btrfs: Welches Dateisystem für dein NAS?
Btrfs RAID 5/6: Warum man es 2026 immer noch nicht produktiv nutzen sollte
RAID im Heimnetz: Alles was du wissen musst, ohne den Uni-Vortrag