Bitrot et ZFS Scrubbing : quand les données pourrissent en silence
«Bitrot» a l'air d'un mythe internet – c'est pourtant réel, bien documenté et touche tout système de stockage. Le RAID seul ne protège pas. Voici l'explication avec probabilités réelles et comment ZFS scrubbing résout le problème.
Version courte
Bitrot est le changement silencieux de données stockées – bits qui basculent, secteurs lus incorrectement. Le RAID classique ne le détecte souvent pas. ZFS (et Btrfs) calcule un checksum par bloc à l'écriture. Scrubbing relit tous les blocs régulièrement, vérifie les checksums et répare depuis la redondance – la seule défense fiable contre le bitrot.
Ce qu'est vraiment le bitrot
Plusieurs causes physiques :
Drift magnétique. La magnétisation HDD s'affaiblit sur des années, peut causer des bit flips.
Rayons cosmiques / TID. Particules haute énergie qui basculent bits en DRAM ou flash. Rare mais statistiquement pertinent à grand volume.
Bugs de contrôleur. Firmware buggé HDDs/SSDs écrit occasionnellement de mauvaises données.
Bruit câble/alim. Erreurs de transmission SATA avec mauvais câbles. Normalement attrapé par l'interface, pas à 100%.
Fréquence réelle du bitrot
Les constructeurs annoncent des taux URE : ~1 sur 10^14 bits pour consumer, 10^15 pour entreprise. Sur 16 To :
- 16 To ≈ 1,28 × 10^14 bits
- Par lecture complète : ~12% de probabilité URE sur consumer
- Entreprise : ~1,2% par scan complet
C'est la limite basse – la corruption silencieuse qui ne remonte pas comme erreur de lecture n'atteint même pas la mécanique HDD. Backblaze estime 0,1-0,5% supplémentaire par an de bits réellement basculés non rapportés comme UREs.
Pourquoi le RAID classique ne suffit pas
RAID 5/6 calcule la parité, mais ne vérifie pas à la lecture si les données sont correctes. Un bit basculé sur un disque de données passe avec la mauvaise info – la parité reste mathématiquement cohérente car calculée depuis les (mauvaises) données.
Lors d'un rebuild ça devient catastrophique : le disque manquant est reconstruit depuis les autres, bits basculés inclus → fichier corrompu «restauré».
mdadm, contrôleurs RAID matériels, NTFS, ext4 – tous ont ce problème. Aucun mécanisme pour détecter la corruption silencieuse.
Comment ZFS résout ça
ZFS stocke un hash (Fletcher4 ou SHA256) pour chaque bloc de données (typiquement 128 Ko) dans le bloc parent – jamais sur le même disque. À la lecture :
- Le bloc est lu
- Le hash est recalculé
- Comparaison avec le hash stocké
- Si discordance : ZFS récupère la copie sur un autre disque (parité RAIDZ ou miroir), la valide, retourne les bonnes données, réécrit la version corrigée
Ça arrive de façon transparente à chaque lecture normale. Plus le scrubbing régulier le force proactivement.
Ce que fait le scrubbing
Un scrub lit tous les blocs alloués du pool, valide les checksums et répare là où c'est nécessaire. Tourne en parallèle de l'usage normal – pas de downtime.
Fréquence recommandée :
- Disques consumer : toutes les 2-4 semaines
- Entreprise : tous les 1-3 mois
- SSDs : toutes les 4-8 semaines (taux de bitrot inférieur)
Synology DSM, TrueNAS et Proxmox ont des planificateurs intégrés. CLI : zpool scrub tank
Btrfs comme alternative
Btrfs a un concept similaire (détection corruption + scrubbing). Mais : Btrfs RAID 5/6 est marqué instable depuis des années et n'est recommandé dans aucune distro actuelle. Btrfs uniquement pour RAID 1/10.
Plus de comparaison : ZFS vs ext4 vs Btrfs.
Configuration Synology DSM
DSM supporte Btrfs Data Scrubbing sur volumes Btrfs :
- Storage Manager → Volume → «Data Scrubbing»
- Planning : tous les 1-3 mois
- Type RAID : SHR/RAID-5/RAID-6 – scrubbing s'applique
Sur RAID 1 avec ext4, le scrubbing DSM aide moins car ext4 n'a pas de checksums. Vérifie seulement la parité au niveau bloc.
Configuration TrueNAS
Par défaut automatique tous les 35 jours. Ajuste sous Storage → Pools → Scrub Tasks. Recommandation : tous les 14-21 jours en home.
Configuration Unraid
Sur Unraid avec cache pool Btrfs/ZFS : plugin scrub disponible. Par défaut parity check tous les 7 jours (style RAID classique, pas checksum).
Ce que le scrubbing ne remplace pas
- Backup : Le scrubbing ne répare pas des données déjà perdues. Plusieurs pannes ou suppression accidentelle requièrent un backup. Le RAID n'est pas un backup.
- RAM ECC : Si le bitrot arrive en RAM (avant l'écriture), ZFS écrit des données corrompues avec checksum correct. RAM ECC l'empêche.
- Protection alimentation : En crash ZFS peut rollback le pool, mais les écritures non synchronisées sont perdues. Onduleur reste obligatoire.
Recommandation
Si l'intégrité des données compte vraiment :
- ZFS RAIDZ2 ou ZFS miroir comme filesystem
- RAM ECC (10-20% de surcoût, ça vaut le coup)
- Onduleur contre les soucis d'alim
- Scrub mensuel
- Backup off-site comme dernière ligne
Articles connexes
Articles connexes
Guide chiffrement ZFS : Native Encryption bien fait
Btrfs RAID 5/6 : Pourquoi il ne faut toujours pas l'utiliser en production en 2026
RAID pour utilisateurs domestiques: Tout ce qu'il faut savoir