ZFS Scrub : fréquence d’exécution et ce qu’il prouve

décembre 26, 2025 • février 3, 2026 • Lecture : 33 min • Views: 11

Cet article vous a aidé ?

Votre pool ZFS a l’air sain. Les applications tournent. SMART indique « PASSED ». Puis un disque meurt, un resilver commence, et soudain vous découvrez que vous viviez avec une corruption silencieuse depuis des mois.
C’est le moment où l’on comprend à quoi sert un scrub.

Un scrub n’est pas une « tâche de performance ». Ce n’est pas un rituel. C’est une manière contrôlée et reproductible de prouver que votre pool peut encore lire ce qu’il pense avoir écrit — avant d’avoir besoin de cette preuve en pleine panne.

Ce que fait réellement un scrub (et ce qu’il ne fait pas)

Un scrub ZFS est une vérification d’intégrité complète du pool. ZFS lit tous les blocs alloués, vérifie les checksums et — si une redondance existe — répare les données corrompues en réécrivant des copies valides.
Voilà l’essentiel : le scrub est une passe de vérification en lecture avec guérison optionnelle.

Ce que fait le scrub

Lit les données allouées à travers datasets/zvols/snapshots, pas l’espace libre.
Vérifie les checksums de bout en bout (le checksum ZFS est stocké séparément des données, donc « le disque a renvoyé quelque chose » ne suffit pas).
Répare quand c’est possible en utilisant les copies miroir/parité et en réécrivant les blocs corrigés (une lecture « auto-guérisseuse »).
Fait apparaître des erreurs de secteurs latentes et des chemins instables que les charges normales n’exercent pas forcément.
Accumule des preuves : compteurs d’erreurs, vdevs affectés, et si la corruption est permanente (aucune bonne copie) ou corrigeable.

Ce que le scrub ne fait pas

Il ne valide pas la sémantique de votre application. Si votre appli a écrit les mauvais octets de façon cohérente, ZFS les préservera fièrement.
Il ne prouve pas que les sauvegardes sont restaurables. Le scrub n’est pas un test de restauration.
Il ne corrige pas une « mauvaise conception matérielle ». Si votre HBA, expander ou backplane ment, le scrub peut révéler des symptômes mais pas guérir la cause.
Il ne lit pas nécessairement l’espace libre. La corruption de l’espace libre est en grande partie sans importance jusqu’à l’allocation, et ZFS ne perd pas de temps à valider des blocs qui n’existent pas.

Le scrub n’est pas non plus un resilver. Un resilver reconstruit les données manquantes pour un disque remplacé ou un périphérique rattachement. Un scrub valide les données existantes et les répare si la redondance le permet.
Confondre les deux mène à des incidents créatifs.

Blague #1 : Un scrub, c’est comme passer la soie dentaire — personne n’aime ça, et tout le monde promet d’en faire plus souvent après qu’il y ait du sang.

Ce que le scrub prouve (et ce qu’il ne peut que suggérer)

L’exploitation, c’est l’art de savoir ce que vos outils peuvent prouver. Le scrub vous donne des preuves solides, mais pas l’omniscience.
Traitez les résultats de scrub comme un signal de fiabilité avec des limites.

Le scrub prouve ces choses (avec une forte confiance)

ZFS peut lire les blocs alloués et les valider contre les checksums au moment du scrub. Si le scrub se termine proprement, les données du pool telles que lues correspondaient aux checksums enregistrés.
Les chemins de redondance peuvent fournir des données correctes pour des blocs incorrects sur un périphérique. Les comptes « repaired » signifient que ZFS avait au moins une bonne copie et l’a réécrite.
Votre système peut soutenir une charge de lecture séquentielle-ish sur l’ensemble du pool sans s’effondrer. Cela compte parce que les resilvers et les restaurations ressemblent beaucoup, d’un point de vue stockage.

Le scrub suggère ces choses (utiles, mais non garanties)

La santé des médias disque. Un scrub propre suggère que les médias vont bien pour l’instant, mais ne prédit pas les pannes futures. Les disques tombent en panne parfois sans prévenir.
L’intégrité du contrôleur/câblage. Si des erreurs apparaissent pendant le scrub, le chemin est suspect. Si aucune erreur n’apparaît, ce n’est pas pour autant un certificat de câblage impeccable — juste une absence d’échec observé.
Les marges de sécurité pour la charge. La vitesse et la latence du scrub révèlent des contentions, mais un « scrub rapide » ne garantit pas que vos I/O aléatoires sont sécurisées sous pression.

Ce qu’il ne peut pas prouver

Que les données sont « correctes » pour les humains. ZFS valide l’intégrité, pas le sens. Si vous avez stocké le mauvais tableur, il le protégera fidèlement.
Que qu’un futur resilver réussira. Le scrub réduit la probabilité de découvrir des erreurs latentes pendant un resilver, mais il ne peut pas éliminer les pannes multi-disques, bugs firmware, ou tempêtes de URE soudaines.

Un modèle mental utile : le scrub répond à « Puis-je lire tout ce qui m’importe maintenant, et sinon, puis-je le réparer avec la redondance ? »
C’est une très bonne question. Ce n’est pas la seule.

Une citation à garder dans votre runbook, parce qu’elle est cruellement vraie :
« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

À quelle fréquence lancer un scrub : règles valables en production

La « bonne » fréquence de scrub est un compromis d’ingénierie entre latence de détection et coût opérationnel.
La latence de détection est le temps pendant lequel vous acceptez de porter une corruption silencieuse avant de la découvrir. Le coût opérationnel inclut l’impact sur les performances, l’usure et l’attention humaine.

Ma recommandation par défaut (et pourquoi)

Maison / petit NAS : scrub mensuel.
Pools fichier + VM en entreprise : toutes les 2–4 semaines, plutôt 2 semaines pour les gros pools.
Données critiques + snapshots longue rétention : toutes les 1–2 semaines.
Archive / stockage froid : mensuel à trimestriel, mais seulement si vous faites aussi des drills de restauration périodiques et conservez des disques de rechange compatibles.

Si cela semble agressif, souvenez-vous de ce que vous achetez : découverte plus précoce de corruption, et découverte plus précoce des disques marginaux.
Le scrub le plus cher est celui que vous n’avez pas exécuté avant qu’une panne de disque ne vous force la main.

Les deux variables qui devraient réellement modifier votre planning

1) Taille du pool et calcul de reconstruction

Les gros pools prennent plus de temps à scrubber. Des scrubs plus longs signifient une fenêtre plus étendue où une autre panne peut coïncider avec « on est déjà sous pression ».
De plus, les temps de rebuild évoluent avec la capacité et le comportement des périphériques sous charge. Si un resilver prend des jours, vous devriez scruber plus souvent, pas moins, car vous voulez que les erreurs latentes soient trouvées tant que vous avez encore de la redondance.

2) Turnover des données et rétention des snapshots

Le scrub lit les blocs alloués, y compris les blocs référencés uniquement par des snapshots. Une rétention longue de snapshots augmente les « données allouées » même si les datasets actifs sont petits.
Si vous conservez des snapshots sur plusieurs mois, vous portez plus de blocs historiques qui nécessitent une vérification périodique. Sinon, vous apprendrez l’existence d’une ancienne corruption au moment où il faudra restaurer d’anciennes données. Ce n’est pas un genre de surprise amusant.

Et les SSD ? Dois-je moins scruber ?

Non. Vous feriez mieux d’avoir au moins la même fréquence, parce que les SSD échouent de façons qui semblent correctes jusqu’au moment où elles ne le sont plus.
Les SSD disposent aussi d’une correction d’erreurs interne qui peut masquer une dégradation du NAND jusqu’à un effondrement soudain.
Le scrub est votre manière de demander à toute la pile, bout en bout, de prouver qu’elle peut encore lire et valider les checksums.

Impact sur les performances : n’en ayez pas peur, gérez-le

Le scrub concurrence les I/O. Sur des pools HDD, il devient souvent une grosse lecture séquentielle qui perturbe quand même la latence I/O aléatoire.
Sur des charges mixtes (VMs plus scrub), les utilisateurs ne se plaignent pas tant du débit que des pics de latence.

La réponse n’est presque jamais « ne jamais scruber ». La réponse est « scruber avec garde-fous » : planification, limitation, et supervision. Vous pouvez rendre les scrubs inintéressants. C’est l’objectif.

Scrubs déclenchés (en plus du planning)

Les scrubs planifiés sont l’hygiène de base. Les scrubs déclenchés servent pour des événements de risque spécifiques :

Après le remplacement d’un disque et la fin du resilver, lancer un scrub pour valider l’état stable.
Après déplacement de matériel (nouveau HBA/backplane/câbles), lancer un scrub pour faire apparaître les problèmes de chemin.
Après des événements d’alimentation ou des mises à jour kernel/driver stockage, lancer un scrub pendant une période de faible trafic.
Après toute apparition d’erreurs de checksum non nulles, scruber plus tôt plutôt que tard, après avoir stabilisé le système.

Faits et histoire intéressants : pourquoi le scrub existe

Le scrub n’est pas apparu parce que les ingénieurs s’ennuyaient. Il existe parce que le stockage ment — silencieusement, et parfois de façon convaincante.
Quelques éléments de contexte utiles quand vous définissez une politique :

ZFS a été conçu avec des checksums de bout en bout dès le départ (ère Sun), parce que contrôleurs et disques peuvent renvoyer des lectures « réussies » avec des données erronées.
Le terme « scrub » existait avant ZFS dans le stockage : les RAID et SANs d’entreprise utilisaient des patrol reads pour découvrir des erreurs de secteurs latentes avant les rebuilds.
Les erreurs de secteurs latentes sont devenues préoccupantes lorsque les capacités de disque ont dépassé les temps de rebuild ; plus le rebuild est long, plus il est probable de heurter un mauvais bloc pendant celui-ci.
ZFS stocke les checksums séparément du bloc qu’ils protègent (dans les métadonnées), évitant le mode de défaillance où la corruption corrompt aussi le checksum, fréquent dans des designs plus faibles.
ZFS ne peut réparer que s’il y a de la redondance. Un pool mono-disque peut détecter des mismatches de checksum, mais il ne peut pas inventer les données correctes.
Le scrub lit aussi les snapshots parce que les snapshots référencent d’anciens blocs ; c’est à la fois un bénéfice (vérification) et un coût (plus à lire).
Certaines erreurs sont « corrigeables » et d’autres permanentes. Cette distinction est opérationnellement cruciale : les erreurs corrigeables pointent souvent vers un périphérique ou un chemin défaillant ; les erreurs permanentes signifient perte de données sauf restauration depuis sauvegarde.
Les scrubs sont volontairement interrompables (pause/stop et reprise selon l’implémentation), reconnaissant les fenêtres de production du monde réel.
Les implémentations ZFS modernes exposent des tunables pour limiter l’impact du scrub, reflétant le passage des « fenêtres de maintenance big iron » aux systèmes multi-tenant toujours actifs.

Tâches pratiques : commandes, sorties et décisions

Cette section est volontairement pratique : commandes à exécuter, ce que la sortie implique, et quelle décision prendre ensuite.
Si vous ne devez en survoler qu’une partie, survolez celle-ci.

Task 1: Confirm pool health before you scrub

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0

errors: No known data errors

Sens : Le pool est online ; aucun scan en cours ; les compteurs d’erreurs sont à zéro.
Décision : Safe to start a scrub. Si le pool était DEGRADED, vous décideriez si le scrub est urgent (pour trouver plus d’erreurs) ou risqué (pour stresser les périphériques restants).

Task 2: Start a scrub (and know what it touches)

cr0x@server:~$ sudo zpool scrub tank

Sens : ZFS commence à lire les blocs alloués dans tank.
Décision : Faites-le dans une fenêtre où l’I/O additionnelle est acceptable. Si c’est un hôte VM à 10:00 le lundi, vous venez de vous offrir du feedback utilisateur.

Task 3: Watch scrub progress and estimate time-to-done

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:12:43 2025
        3.21T scanned at 612M/s, 1.04T issued at 198M/s, 18.7T total
        0B repaired, 5.57% done, 1 days 02:11:09 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0

errors: No known data errors

Sens : « Scanned » peut dépasser « issued » selon la comptabilité ; concentrez-vous sur le taux issued et la tendance de l’ETA. Repaired à 0, c’est bien.
Décision : Si l’ETA gonfle pendant les heures ouvrées, envisagez de limiter via des tunables système, déplacer la fenêtre de scrub, ou mettre en pause (voir tâches suivantes).

Task 4: Detect whether scrub is fighting your workload

cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server)  12/25/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.12    0.00    2.41   18.77    0.00   73.70

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
sda              92.0  184320.0     0.0   0.00   28.44  2003.5      6.2     512.0  12.21   3.42   98.7
sdb              89.5  179200.0     0.0   0.00   31.02  2002.8      6.0     480.0  14.10   3.64   99.1

Sens : Les disques sont saturés (~99% util), le read await est élevé (28–31ms). C’est normal pour un scrub HDD, mais potentiellement mortel pour des charges sensibles à la latence.
Décision : Si les utilisateurs se plaignent ou si la latence des VM grimpe, bridez l’impact du scrub ou planifiez-le la nuit. Si l’await est élevé même hors heures, investiguez la santé des disques/câblage.

Task 5: Find “real size” of what scrub must read (including snapshots)

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,refer,avail -r tank
NAME                 USED  USEDBYSNAPSHOTS  REFER  AVAIL
tank                18.7T             6.2T   128K  12.1T
tank/vm             11.4T             4.8T  6.6T   12.1T
tank/home            2.1T             1.2T  0.9T   12.1T
tank/backups         5.2T             0.2T  5.0T   12.1T

Sens : Le scrub lit les blocs alloués ; 6.2T provient uniquement des snapshots. C’est du temps de scrub supplémentaire que vous avez « oublié » de payer.
Décision : Si les scrubs prennent trop de temps, ajustez la rétention des snapshots ou séparez datasets/pools par criticité, pas par impressions.

Task 6: See scrub history and whether you’re actually doing it

cr0x@server:~$ zpool history -il tank | tail -n 12
2025-12-23.01:12:43 zpool scrub tank
2025-11-23.01:09:51 zpool scrub tank
2025-10-23.01:11:02 zpool scrub tank
2025-09-22.01:08:37 zpool scrub tank

Sens : Quelqu’un (ou un timer) a lancé des scrubs mensuels. S’il y a un trou, vous fonctionnez à l’espoir.
Décision : Placez les scrubs sous un ordonnanceur auditable (systemd timers, cron) et alertez sur « scrub en retard ».

Task 7: Catch checksum errors early and identify the guilty vdev

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
  scan: scrub repaired 0B in 05:41:10 with 2 errors on Mon Dec 23 06:53:53 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     2
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/vm@auto-2025-12-01:vm-103-disk-0

Sens : Deux erreurs de checksum et des erreurs permanentes : ZFS n’a pas pu réparer parce que toutes les copies étaient mauvaises ou la redondance insuffisante pour ces blocs.
Décision : Cessez de prétendre que tout va bien. Restaurez les données affectées depuis une sauvegarde/snapshots (si des snapshots propres existent), et lancez immédiatement une investigation matérielle/chemin.

Task 8: Clear error counters only after you’ve acted

cr0x@server:~$ sudo zpool clear tank

Sens : Réinitialise les compteurs d’erreurs et efface l’état « errors ». Cela ne répare pas magiquement les données.
Décision : N’effacez qu’après : (1) avoir capturé des preuves, (2) remplacé/confirmé le matériel, et (3) lancé un scrub de suivi pour valider la stabilité. Sinon vous supprimez la scène de crime.

Task 9: Pause or stop a scrub when it hurts (and resume later)

cr0x@server:~$ sudo zpool scrub -p tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub paused since Mon Dec 23 10:04:11 2025
        7.12T scanned at 590M/s, 2.98T issued at 248M/s, 18.7T total
        0B repaired, 15.9% done, scrub paused
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
...

Sens : Le scrub est en pause ; la progression est préservée selon l’implémentation et la version.
Décision : Si la latence tue la production, mettez en pause et reprenez pendant une fenêtre calme plutôt que d’abandonner complètement.

cr0x@server:~$ sudo zpool scrub -s tank

Sens : Arrête le scrub.
Décision : Utilisez stop quand vous devez changer du matériel ou quand le scrub lui-même déclenche des fautes que vous devez traiter d’abord (timeouts, resets).

Task 10: Differentiate scrub from resilver in status output

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Dec 24 02:01:17 2025
        1.44T scanned at 312M/s, 620G issued at 134M/s, 6.60T total
        620G resilvered, 9.16% done, 0 days 11:08:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0
            replacing-1             DEGRADED     0     0     0
              ata-WDC_WD80EAZZ-00BKLB0  FAULTED     0     0     0  too many errors
              ata-WDC_WD80EAZZ-00BKLB0  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Sens : C’est un resilver, pas un scrub. Profil de risque différent : vous reconstruisez la redondance.
Décision : Évitez de lancer un scrub pendant un resilver à moins que vous ne validiez intentionnellement un pool instable et puissiez gérer l’I/O. En général : laissez le resilver se terminer, puis scrubez.

Task 11: Check device error logs (Linux) when scrubs trigger resets

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Dec 23 03:18:11 2025] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Dec 23 03:18:11 2025] ata9.00: failed command: READ FPDMA QUEUED
[Mon Dec 23 03:18:11 2025] ata9: hard resetting link
[Mon Dec 23 03:18:12 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Mon Dec 23 03:18:14 2025] ata9.00: configured for UDMA/133

Sens : Resets de lien pendant des lectures intensives. Ça sent le câblage/backplane/HBA défectueux, pas « ZFS qui fait son difficile ».
Décision : Réparez le chemin physique. Le scrub n’est que le messager qui a forcé des lectures soutenues.

Task 12: Pull SMART data and decide whether to replace the disk

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours"
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       31254
 197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
 199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       14

Sens : Sectors pending/uncorrectable suggèrent un vrai problème média. Les erreurs UDMA CRC pointent souvent vers le câblage/backplane.
Décision : Si pending/uncorrectable > 0 et que le scrub a fait remonter des erreurs de checksum : remplacez le disque. Si seul le CRC augmente : reseatez/remplacez le câble/la voie du backplane et surveillez.

Task 13: Confirm ashift and why it matters for scrub time

cr0x@server:~$ zdb -C tank | egrep "ashift|vdev_tree" -n | head
42:        vdev_tree:
57:            ashift: 12

Sens : ashift=12 implique des secteurs 4K. Un ashift erroné (trop petit) peut causer une amplification read-modify-write et un comportement généralement mauvais.
Décision : Si ashift est incorrect, vous ne le « tunez » pas. Vous planifiez une migration vers un pool créé correctement. Le scrub ne vous sauvera pas d’une erreur de fondation.

Task 14: Identify whether a dataset is forcing pathological I/O during scrub

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,dedup tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  dedup        off

Sens : Valeurs par défaut raisonnables pour beaucoup de charges VM. Dedup off est un choix préservant la sanity pour la plupart des environnements.
Décision : Si vous voyez dedup activé et que scrubs/reslivers sont lents avec pression mémoire, investiguez ARC/mémoire et la pression DDT. Ne devinez pas ; mesurez.

Task 15: Verify scrub isn’t “fast” because it isn’t reading much

cr0x@server:~$ zpool list -o name,size,alloc,free,fragmentation,health
NAME  SIZE   ALLOC  FREE  FRAG  HEALTH
tank  29.1T  18.7T  10.4T   42%  ONLINE

Sens : Alloué est 18.7T. Un scrub qui « finit » en 15 minutes n’a probablement pas lu 18.7T ; vous lisez mal la situation (ou regardez le mauvais pool).
Décision : Vérifiez la durée du scrub par rapport à l’alloc et au débit réaliste des périphériques. Quand les nombres ne respectent pas la physique, supposez qu’il vous manque des informations.

Task 16: Use event logs to correlate scrub errors with timestamps

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                            CLASS
Dec 23 2025 03:18:12.123456789  ereport.fs.zfs.checksum
    zevent.fsname = tank
    zevent.vdev_path = /dev/disk/by-id/ata-WDC_WD80EAZZ-00BKLB0_XXXX
    zevent.vdev_guid = 1234567890123456789
Dec 23 2025 03:18:12.223456789  ereport.fs.zfs.io
    zevent.fsname = tank
    zevent.vdev_path = /dev/disk/by-id/ata-WDC_WD80EAZZ-00BKLB0_XXXX

Sens : ZFS vous dit quand et où il a vu des faults de checksum/I/O.
Décision : Corrélez avec dmesg et SMART. Si les événements coïncident avec des resets de lien, le « disque défectueux » peut être un chemin défaillant.

Mode d’action pour diagnostic rapide : trouver le goulot vite

Quand un scrub est lent ou génère des erreurs, vous pouvez passer des heures à philosopher — ou faire un triage rapide qui réduit le champ à : disque, chemin, CPU/mémoire, ou charge concurrente.
Voici l’ordre pratique qui fait gagner du temps.

First: what does ZFS say is happening?

Vérifier : zpool status -v tank
Regarder : « scrub in progress » vs « resilver » ; bytes repaired ; « errors: Permanent errors » ; quel vdev montre des incréments READ/WRITE/CKSUM.
Décision : Si des erreurs permanentes apparaissent, passez du mode « performance » au mode « récupération de données ». Capturez les preuves, identifiez les objets/datasets impactés, planifiez la restauration.

Second: is it hardware path instability?

Vérifier : dmesg -T | tail -n 200 pour resets/timeouts ; smartctl pour erreurs CRC ; logs HBA si disponibles.
Regarder : Resets de lien SATA, aborts SCSI, resets NVMe, spam « I/O error » qui n’apparaît que sous la charge du scrub.
Décision : Si des resets ont lieu : traitez d’abord comme un problème de chemin (câbles/backplane/HBA/expander/firmware). Remplacez le composant suspect le moins cher avant d’accuser ZFS.

Third: is it simple I/O saturation or contention?

Vérifier : iostat -x 5, plus votre télémétrie habituelle de latence.
Regarder : 100% util, await élevé, profondeur de file d’attente en hausse, et si les écritures souffrent aussi.
Décision : Si c’est une « saturation normale », gérez-la : planifiez, limitez ou isolez les workloads. Si l’await est extrême même avec faible util, suspectez firmware/problèmes de disque.

Fourth: is ZFS or the OS starved (CPU, RAM, ARC pressure)?

Vérifier : vmstat 5, pression mémoire, dimensionnement ARC, et si le système swappe.
Regarder : activité de swap ; storms kswapd ; CPU saturé en temps système.
Décision : Si vous swappez pendant un scrub, réparez la mémoire d’abord. Le scrub est une charge de lecture ; il ne doit pas transformer votre serveur en démonstration de pagination.

Fifth: is it “scrub is slow because it has a lot to read”?

Vérifier : zfs list (usedbysnapshots) et zpool list alloc.
Regarder : bloat de snapshots, allocation inattendue, ou fragmentation impliquant beaucoup de seeks.
Décision : Si le pool est simplement grand et occupé, acceptez des scrubs plus longs mais renforcez la planification et l’alerte. La fiabilité n’est pas gratuite ; elle se paie en IOPS.

Trois mini-récits d’entreprise depuis les tranchées du scrub

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne utilisait ZFS sur une paire de serveurs de stockage pour la virtualisation. Des mirrors partout. Ils se sentaient en sécurité, ce qui est une condition courante pour apprendre la leçon.
Les scrubs étaient « optionnels », parce que le stockage était « RAID1 et disques enterprise ».

Un disque est tombé en panne pendant une semaine chargée. Le resilver a commencé. À mi-chemin, le pool a commencé à journaliser des erreurs de checksum sur le côté survivant d’un mirror.
L’équipe a supposé : « ZFS fait son dramatique ; ça guérira. » Cette supposition est l’incident.

ZFS n’a pas pu guérir ces blocs parce que la seule copie restante était mauvaise. Les blocs corrompus étaient anciens — depuis des semaines — et reposaient tranquillement dans une zone disque VM rarement lue.
Personne n’a remarqué avant que le resilver force la lecture de tout et exige la correction.

L’échec opérationnel n’était pas « un disque est mort ». Les disques meurent. L’échec était d’accepter une intégrité inconnue pendant des semaines parce que les scrubs n’étaient ni planifiés ni monitorés.
Ils avaient des sauvegardes, mais les restaurations étaient lentes et politiquement pénibles. L’incident est devenu un événement au niveau exécutif.

Après coup, ils n’ont pas seulement ajouté un scrub mensuel. Ils ont ajouté une politique : toute erreur de checksum non nulle crée un ticket, exige un triage matériel, et se termine par un scrub propre avant clôture.
L’incident a cessé d’être une « corruption mystérieuse ZFS » et est devenu « nous avons trouvé un mauvais chemin avant qu’il ne nous coûte cher ».

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation avait un grand pool HDD qui scrubait lentement. Les utilisateurs se plaignaient du ralentissement le lundi matin.
Quelqu’un a proposé une optimisation : lancer le scrub en continu mais « nice » en limitant le CPU et le laisser couler. Ils ont aussi déplacé la fenêtre de scrub en heures ouvrées parce que « ce sera doux ».

Sur le papier, doux. En réalité, cela a créé une contention permanente de bas niveau. Le scrub n’a jamais eu assez de temps contigu pour finir rapidement, il a donc chevauché chaque pic.
Les pics de latence n’étaient pas dramatiques ; ils étaient constants. C’est pire. Les gens tolèrent les tempêtes ; ils quittent à cause de la bruine.

Pendant ce temps, des scrubs qui prennent une éternité augmentent l’exposition. Plus le pool est scanné longtemps, plus vous risquez de rencontrer des pannes non liées :
hiccups de contrôleur, quirks de firmware, ou juste le disque malchanceux qui choisit cette semaine pour commencer à timer out.

Ils sont finalement revenus à un scrub strict hors heures avec un arrêt net à la fin de la fenêtre de maintenance, puis reprise la nuit suivante.
Même travail total, moins de douleur utilisateur, finition plus rapide, et moins d’incidents « scrub coïncidence étrange ».

La leçon : « toujours activé mais lent » n’est pas automatiquement plus sûr. Finir un scrub est un jalon de fiabilité. Injecter un scrub au goutte-à-goutte pendant les heures ouvrées est la façon d’inventer une nouvelle norme de médiocrité.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers utilisait ZFS sur des vdevs mirror pour le stockage VM. Rien d’extraordinaire. Ce qu’ils avaient, c’était une routine terne :
scrubs bi-hebdomadaires, alertes sur l’achèvement, et un ticket si tout mouvement de CKSUM apparaissait.
Ils notaient aussi la durée du scrub et la comparaient aux baselines historiques.

Un cycle, le scrub s’est terminé mais a mis sensiblement plus de temps. Pas d’erreurs, juste plus lent. L’alerte n’a pas déclenché d’astreinte, mais elle a créé un ticket d’investigation parce que la durée dépassait un seuil.
Un ingénieur a regardé iostat pendant le scrub suivant et a vu un disque avec un await supérieur à son partenaire mirror.

SMART ne montrait pas de secteurs réalloués, mais montrait une augmentation des erreurs CRC. Ils ont changé un câble et repositionné le disque dans le backplane.
Le scrub suivant est revenu à la vitesse normale. Toujours pas d’erreurs.

Deux semaines plus tard, ce même emplacement backplane a commencé à envoyer des resets de lien pendant une fenêtre de trading IOPS élevée — sauf que maintenant l’équipe avait déjà identifié l’emplacement comme suspect.
Ils ont basculé le trafic, remplacé le backplane, et évité la corruption de données et un incident plus vaste.

La pratique ennuyeuse n’a pas seulement « trouvé de la corruption ». Elle a trouvé un chemin en dégradation avant qu’il ne franchisse la ligne vers la perte de données.
Voilà à quoi ressemble la maturité opérationnelle : moins de restaurations héroïques, plus de corrections silencieuses.

Erreurs courantes : symptômes → cause racine → correction

La plupart des problèmes de scrub ne sont pas exotiques. Ce sont les mêmes quelques modes de défaillance qui se déguisent.
Voici la liste courte que j’aimerais voir dans plus de runbooks.

1) Le scrub montre des erreurs de checksum, SMART semble « OK »

Symptôme : zpool status montre CKSUM > 0, parfois « Permanent errors ». SMART overall-health dit PASSED.
Cause racine : SMART « PASSED » n’est pas une garantie de santé. De plus, la corruption peut provenir du chemin (câble/HBA) ou de la RAM, pas seulement du média.
Correction : Corrélez les events ZFS avec dmesg. Vérifiez les erreurs CRC. Lancez un scrub de suivi après avoir reseaté/remplacé câbles ou changé le disque de port. Si les erreurs persistent sur le même disque via différents ports, remplacez le disque.

2) Les scrubs « mettent une éternité » après augmentation des snapshots

Symptôme : Le temps de scrub a doublé sur des mois ; aucun changement matériel ; le pool semble sinon normal.
Cause racine : La rétention des snapshots a augmenté les blocs alloués. Le scrub lit les blocs référencés par les snapshots, même si le dataset actif est petit.
Correction : Inspectez usedbysnapshots. Ajustez la rétention, ou déplacez les snapshots longue rétention sur un pool/tiers média différent. Re-basez la durée du scrub une fois la politique de snapshot raisonnable.

3) Le scrub provoque des pics de latence VM et des tickets « stockage lent »

Symptôme : Pendant le scrub, la latence monte ; les utilisateurs se plaignent ; BD bloque ; VMs « gèlent » brièvement.
Cause racine : Les HDD sont saturés par les lectures du scrub ; la profondeur de file augmente ; les écritures synchrones attendent derrière les I/O du scrub.
Correction : Planifiez les scrubs hors heures. Envisagez le throttling via des tunables OS/ZFS disponibles sur votre plateforme. Si chronique, la vraie correction est plus de spindles, des SSD, ou séparer les pools par workload.

4) Le scrub continue de « réparer » une petite quantité à chaque passe

Symptôme : Chaque scrub rapporte quelques bytes réparés, mais rien n’escalade jamais en faute claire.
Cause racine : Matériel marginal ou chemin provoquant des lectures intermittentes mauvaises ; ZFS guérit avec la redondance, masquant la pourriture sous-jacente jusqu’à aggravation.
Correction : Traitez les réparations récurrentes comme un incident matériel. Identifiez le vdev avec des erreurs en hausse. Changez câbles/ports, lancez des tests SMART longs, remplacez le périphérique si le comportement le suit.

5) Le scrub « finit instantanément » sur un énorme pool

Symptôme : Scrub terminé en minutes ; le pool a des dizaines de To alloués ; personne ne croit aux chiffres.
Cause racine : Vous avez scrubbed le mauvais pool, vous lisez le statut depuis un autre hôte, ou le pool a très peu de données allouées (allocation fine, majoritairement libre).
Correction : Confirmez zpool list alloc, confirmez le nom du pool, confirmez que vous êtes sur la bonne machine, vérifiez l’historique et validez les timestamps de status.

6) Des erreurs permanentes apparaissent, et quelqu’un les efface immédiatement

Symptôme : « errors: Permanent errors » apparaît, puis disparaît après zpool clear, mais aucune restauration n’a eu lieu.
Cause racine : Traiter l’état d’erreur comme cosmétique ; pression pour rendre les dashboards verts.
Correction : Politique : ne jamais clear avant d’avoir capturé zpool status -v, identifié les objets impactés, et tenté la restauration. Exiger un scrub propre après remédiation avant de fermer les tickets.

7) La vitesse de scrub s’effondre après ajout d’un cache « plus rapide » ou d’un device spécial

Symptôme : Après changements (L2ARC, special vdev), temps de scrub et latence empirent.
Cause racine : Le placement des métadonnées et l’asymétrie des périphériques peuvent changer les patrons I/O. Un special vdev trop petit ou stressé peut devenir le point d’étranglement.
Correction : Mesurez l’utilisation au niveau device pendant le scrub. Si un special vdev est saturé, agrandissez-le correctement ou redessinez. Ne greffez pas « accélération » sur un pool sans planifier le comportement scrub/resilver.

8) Le scrub déclenche des timeouts périphériques seulement sous charge

Symptôme : Les charges normales vont bien. Le scrub provoque des erreurs I/O, des resets, des offlines.
Cause racine : Firmware marginal, surchauffe, problèmes d’alimentation, ou chemin qui échoue sous débit soutenu.
Correction : Vérifiez les températures, l’alimentation, le câblage, le firmware HBA. Lancez des tests SMART longs. Envisagez de réduire la charge concurrente (planifier les scrubs) pendant que vous réparez le problème matériel sous-jacent.

Blague #2 : Le scrub ne « cause » pas la panne de vos disques ; il leur demande juste de faire leur travail pendant plus de cinq minutes.

Listes de contrôle / plan étape par étape

Checklist A : Définir une politique de scrub défendable

Choisissez une fréquence basée sur le risque : commencez par toutes les 2–4 semaines pour les pools de production.
Définissez un seuil « en retard » (p. ex. 2× votre intervalle) qui déclenche une alerte/ticket.
Définissez l’impact acceptable du scrub : fenêtre max, planning hors heures, règles de pause.
Rédigez ce que signifie opérationnellement « erreurs non nulles » : qui est alerté, qui enquête, comment prouver la clôture.
Établissez une baseline de durée et de débit de scrub ; alertez sur les régressions, pas seulement sur les échecs.

Checklist B : Runbook opérationnel pour chaque cycle de scrub

Avant de démarrer : zpool status (confirmer ONLINE et noter les compteurs d’erreurs existants).
Démarrer le scrub : zpool scrub tank.
Pendant le scrub : surveiller zpool status -v et iostat -x pour l’impact.
En cas de douleur perf : pause (zpool scrub -p) et reprise pendant les heures calmes.
Après achèvement : capturez la sortie zpool status -v pour les archives.
Si repaired > 0 ou CKSUM > 0 : ouvrez un ticket d’incident ; collectez SMART + dmesg + zpool events ; planifiez la remédiation.
Après remédiation : lancez un scrub de suivi et exigez qu’il se termine proprement.

Checklist C : Quand le scrub rapporte des erreurs permanentes

Cessez de faire des changements. Capturez : zpool status -v, zpool events -v, dmesg -T, données SMART pour tous les membres.
Identifiez les objets/fichiers impactés listés dans status ; mappez-les aux datasets/services.
Décidez du chemin de récupération : restaurer depuis sauvegarde, restaurer depuis un snapshot plus ancien, ou reconstruire la VM/dataset affecté.
Traitez la cause probable (remplacez un disque, réparez un chemin, vérifiez la mémoire si le pattern de corruption le suggère).
Lancez un scrub après réparations et n’effacez les erreurs qu’après.

Example: scheduling with systemd timers (boring, effective)

cr0x@server:~$ cat /etc/systemd/system/zfs-scrub@.service
[Unit]
Description=ZFS scrub on %i

[Service]
Type=oneshot
ExecStart=/sbin/zpool scrub %i

cr0x@server:~$ cat /etc/systemd/system/zfs-scrub@tank.timer
[Unit]
Description=Run ZFS scrub on tank monthly

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

cr0x@server:~$ sudo systemctl enable --now zfs-scrub@tank.timer
Created symlink /etc/systemd/system/timers.target.wants/zfs-scrub@tank.timer → /etc/systemd/system/zfs-scrub@tank.timer.

Sens : Vous avez maintenant un planning auditable. « Persistent=true » exécute les timers manqués après une indisponibilité.
Décision : Ajoutez de la supervision qui vérifie la dernière complétion et le dernier résultat de scrub. Planifier sans visibilité, c’est de l’optimisme horodaté.

FAQ

1) Dois-je lancer un scrub sur un pool dégradé ?

Parfois. Si vous suspectez une corruption silencieuse, un scrub peut révéler l’étendue. Mais il stresse aussi les périphériques restants.
Si le pool est dégradé parce qu’un disque manque et que vous avez un remplaçant prêt, priorisez le remplacement/resilver d’abord, puis le scrub.

2) Le scrub est-il la même chose qu’un test SMART long ?

Non. Les tests SMART longs sont des diagnostics au niveau périphérique. Le scrub est une validation d’intégrité bout en bout via filesystem, contrôleur et disque.
Faites les deux. Ils détectent des classes de pannes différentes.

3) Le scrub valide-t-il l’espace libre ?

Généralement non ; il lit les blocs alloués (y compris les snapshots). L’espace libre n’est pas des données. Le risque porte sur les blocs que vous pourriez avoir besoin de lire plus tard, c’est-à-dire les blocs alloués.

4) Pourquoi le scrub ralentit-il vers la fin ?

Le scrub initial frappe souvent de grandes régions contiguës et des caches ; les phases finales peuvent impliquer des métadonnées plus fragmentées et des blocs dispersés, ce qui augmente les seeks et réduit le débit — surtout sur HDD.

5) Si le scrub a réparé des données, suis-je en sécurité maintenant ?

Plus en sécurité, pas sûr. Les réparations signifient que la redondance a fonctionné, mais quelque chose a causé des lectures mauvaises. Traitez les réparations comme un avertissement que votre pool consomme de la redondance pour masquer un problème.
Investiguer le matériel et lancez un scrub de suivi.

6) Puis-je scruber trop souvent ?

Vous pouvez scruber si souvent que vous êtes constamment en concurrence avec votre propre maintenance. Ce n’est pas « plus sûr », c’est simplement une latence auto-infligée.
Si vos scrubs se chevauchent continuellement, soit le pool est trop occupé, trop lent, ou votre rétention de snapshots est hors de contrôle.

7) Quelle est la différence entre READ/WRITE/CKSUM dans `zpool status` ?

En gros : READ/WRITE suggèrent des échecs I/O (timeouts, erreurs périphériques). CKSUM suggère que les données ont été lues mais ne correspondent pas au checksum attendu (peut être média, chemin, contrôleur, RAM).
Les erreurs CKSUM sont celles qui doivent vous rendre particulièrement sceptique face à « mais le disque dit qu’il va bien ».

8) Dois-je scruber après avoir remplacé un disque ?

Oui, après la fin du resilver. Le resilver reconstruit la redondance ; le scrub valide l’exactitude bout en bout sur tout ce qui est alloué.
C’est la différence entre « on l’a reconstruit » et « on l’a vérifié ».

9) Ai-je besoin de scruber si j’ai des sauvegardes ?

Oui. Les sauvegardes servent à la récupération, les scrubs servent à la détection précoce. Sans scrubs, vous risquez de ne découvrir la corruption qu’au moment de restaurer — souvent bien après la dernière copie connue bonne.

10) Comment savoir si je dois remplacer un disque après des erreurs de scrub ?

Si les erreurs suivent le disque à travers ports/câbles, remplacez le disque. Si les erreurs suivent le port/câble/emplacement du backplane, réparez le chemin.
Les erreurs correctables répétées ne sont pas « acceptables ». C’est un compte à rebours dont la durée est inconnue.

Conclusion : prochaines étapes à réaliser aujourd’hui

Un scrub ZFS est un contrôle de réalité. Il prouve que ce que vous avez stocké peut encore être lu et validé — bout à bout — maintenant.
Cette preuve compte surtout juste avant qu’un incident n’arrive, c’est pourquoi vous la planifiez avant d’avoir l’impression d’en avoir besoin.

Faites ceci

Choisissez une fréquence : par défaut toutes les 2–4 semaines pour les pools de production ; resserrez si les pools sont grands ou si les resilvers sont lents.
Planifiez les scrubs avec un outil auditable (systemd timer/cron) et alertez sur « en retard » et « erreurs ».
Baselinez la durée et le débit des scrubs, puis alertez sur les régressions — la lenteur est souvent le premier symptôme.
Rédigez une politique d’escalade pour toute erreur de checksum non nulle ou bytes réparés.
Après tout changement matériel (disque, câble, HBA), lancez un scrub dans une fenêtre contrôlée et confirmez qu’il se termine proprement.

Votre futur post-mortem dira soit « nous l’avons trouvé pendant un scrub de routine » soit « nous l’avons découvert pendant une reconstruction ».
L’une de ces phrases est plus agréable pour la direction. Plus important : l’une est généralement récupérable.