Des redémarrages soudains de votre serveur Windows Server 2022 accompagnés de l’événement ID 153 indiquent que le sous‑système de stockage ne répond pas assez vite. Découvrez comment diagnostiquer, isoler et corriger la panne sans remplacer inutilement tout le matériel.
Event ID 153 : corruption de données ou panne matérielle ?
L’avertissement « The I/O operation at logical block address XXXX for Disk N was retried » signifie que Windows a dû relancer une requête I/O après l’expiration d’un délai d’attente (timeout). Contrairement aux ID 7, 55 ou 157 qui signalent déjà une corruption ou un arrêt d’I/O, le 153 représente un ralentissement critique plutôt qu’une faute irrémédiable. Plus le nombre d’occurrences est élevé, plus le risque de voir apparaître des ID 129 (reset de bus) ou un BSOD 0x0000009E DISK_QUEUE_INITIALIZATION_FAILED augmente.
Comprendre la pile de stockage Windows
À partir de Windows Server 2012, la pile StorPort remplace largement SCSIport pour profiter du multithreading et de la mise en cache côté contrôleur. Un délai d’attente (30 s par défaut) sur un chemin SCSI, SAS, SATA ou NVMe déclenche un SRB_STATUS_TIMEOUT. StorPort signale alors l’ID 153 dans le journal Système pendant qu’il relance la commande. Si la commande échoue encore, un reset de bus produit un ID 129, puis l’éventuel arrêt du périphérique (ID 157). Cette mécanique protège les données, mais alerte l’administrateur qu’un composant de la chaîne (disque, câble, HBA, contrôleur RAID, backplane, baie SAN, réseau iSCSI/FC, microcode) ne respecte plus les temps de réponse contractuels.
Méthodologie de diagnostic en 8 étapes
| Étape | Objectif | Commandes / actions | Commentaires utiles |
|---|---|---|---|
| Examiner les journaux | Confirmer que l’ID 153 n’est pas isolé et repérer d’autres erreurs SCSI / StorPort | Observateur d’événements → Journaux Windows → Système ; filtre disk, ntfs, storport, scsi | Des grappes d’ID 153 espacés de quelques secondes dessinent un pattern virtuel de congestion. |
| Vérifier l’état SMART et firmware | Détecter un disque physiquement défaillant | Outils constructeur (HPE SSA, Dell OMSA, Lenovo XClarity) ou Get-PhysicalDisk, smartctl -x | Un unique disque en erreur SMART peut ralentir tout un RAID5/6. |
| Contrôler le chemin de stockage | Écarter un câble ou un port HBA défectueux | Inspection visuelle, échange croisé des câbles, vérification LED contrôleur/baie | Sur SAN : analyser zoning, qualité fibre, latence réseau iSCSI, microcode switch. |
| Mettre à jour pilotes & firmware | Corriger des bugs de micro‑code | Pilotes StorPort/RAID, firmware SSD/HDD, BIOS, patchs Microsoft (ex. KB5030208) | Un pilote obsolète peut raccourcir ou allonger abusivement les timeouts. |
| Tester le volume logique | Réparer la structure NTFS et marquer les blocs défectueux | chkdsk C: /f /r ; ReFS : refsutil /c salvage <volume> | Planifier la maintenance hors production ; prévoir redémarrage. |
| Exécuter un stress‑test I/O | Reproduire les erreurs sous charge contrôlée | diskspd -d120 -r -w40 -t8 -b64K -o32 c:\test.dat, Iometer | Des ID 153 immédiats sous charge prouvent la nature matérielle. |
| Mettre en place des alertes proactives | Être averti avant la panne critique | SCOM, Nagios, Zabbix, iDRAC/iLO e‑mail traps | Surveiller température, latence disque, réallocations SMART, queues I/O. |
| Plan de remplacement | Changer les pièces plutôt que le serveur entier | Remplacer d’abord le disque suspect, puis le contrôleur, câblage, backplane | Conserver la même version de firmware entre anciens et nouveaux composants. |
Détail étape par étape
1. Scruter le journal Système
Utilisez un filtre par Source = Disk et ID = 153 OR 157 OR 129 OR 7 OR 55. Exportez ensuite au format .evtx pour un suivi hors‑ligne. Un pic d’ID 153 pendant la nuit peut correspondre à la fenêtre de sauvegarde, révélant une saturation du back‑end plutôt qu’un composant matériel isolé.
2. Collecter les compteurs Performance Monitor
Ajoutez \PhysicalDisk(*)\Avg. Disk sec/Transfer, Current Disk Queue Length et \LogicalDisk(*)\Split IO/Sec. Une latence > 20 ms soutenue ou une file d’attente > 2 × nombre de cœurs HBA indique un goulet d’étranglement. Corrélez‑les avec les horodatages des événements.
3. Analyser les données SMART
Concentrez‑vous sur les attributs 05 (Reallocated Sectors), C5 (Pending Sector) et C7 (UDMA CRC Error Count). Un fort incrément du compteur C7 sans réaffectations peut pointer un câble SAS vrillé ou un connecteur SATA encrassé. Sur SSD NVMe, surveillez l’usure (Percentage Used) : au‑delà de 80 %, les contrôleurs internes réduisent la vitesse d’écriture, provoquant des timeouts.
4. Inspecter le chemin SAN
En Fibre Channel, exécutez fcstat ou porterrshow sur les switchs Brocade/Cisco afin de repérer les Link Resets et Enc CRC. En iSCSI, validez le MTU constant (9000 B ou 1500 B) entre carte, switch et baie ; un manque d’alignement crée une cascade de retransmissions TCP interprétées par StorPort comme un délai d’attente I/O.
5. Mettre à jour sans risque
Avant toute mise à jour firmware, capturez un inventaire Get-WindowsDriver -Online et exportez la configuration RAID (.XML ou .INI selon le constructeur). Documentez précisément la version précédente ; un rollback mal préparé expose à un firmware mismatch empêchant le volume de remonter.
6. Vérifier le système de fichiers
chkdsk /f /r agit à deux niveaux : phase 4 (vérification des données) et phase 5 (recherche de secteurs défectueux). Sur un volume de 4 To, prévoyez plusieurs heures ; une maintenance planifiée évite un nouveau redémarrage brutal qui corromprait davantage le MFT. Pour ReFS, refsutil salvage isole la corruption sans scruter physiquement chaque bloc.
7. Simuler la charge I/O
Avec diskspd, jouez sur la profondeur de file (-o), le ratio lecture/écriture (-w) et la taille de bloc (-b) pour reproduire le profil applicatif (ex. 4K random SQL, 1 M séquentiel sauvegarde). Lancez au moins 2 minutes – les contrôleurs cachent souvent la latence durant les 30 premières secondes grâce au cache DRAM.
8. Orchestrer le remplacement des pièces
Adoptez une démarche itérative : commencez par swapper le disque suspect (ID physique le plus sollicité ou celui dont le compteur SMART est le plus élevé). Si l’anomalie persiste, échangez la carte RAID/HBA ; enfin, si nécessaire, la backplane ou le tiroir SAN. Reporter tous les échanges dans votre CMDB – les futurs incidents croisés seront plus rapides à corréler.
Études de cas
Serveur tour avec RAID 5 SAS
Après l’ajout d’un second processeur, le flux d’I/O a doublé et un des disques SAS 10K montrait 87 secteurs réalloués. Les ID 153 surviennent lors de la compression nocturne des sauvegardes. Remplacement du disque puis mise à jour du pilote HPE Smart Array ont supprimé les alertes.
Cluster Hyper‑V sur SAN iSCSI
Un firmware obsolète sur les switchs 10 GbE limitait la taille de fenêtre TCP à 64 KB, provoquant une latence variable (2–120 ms) et des ID 153 pendant le live‑migration. Après upgrade du micro‑code, activation de Jumbo Frames et équilibrage du MPIO (round‑robin), la latence est retombée à 1,5 ms.
Bonnes pratiques pour éviter la récurrence
- Isoler la charge de sauvegarde sur un réseau ou un HBA distinct pour éviter la contention.
- Activer le cache écriture protégé par batterie (BBWC/FBWC) sur les contrôleurs RAID pour absorber les pics.
- Sur VM résidentes, désactiver les snapshots persistants ; une longue chaîne .AVHDX rallonge les chemins I/O.
- Planifier un redémarrage trimestriel du serveur : les firmwares SAN et les pilotes StorPort récupèrent souvent de petites fuites de mémoire.
- Conserver 20 % d’espace libre sur chaque volume ; NTFS fragmenté multiplie les I/O et risque les timeouts.
Checklist post‑remédiation
- Aucun nouvel ID 153 dans
eventvwr.mscdurant 7 jours. - Latence moyenne
\PhysicalDisk(*)\Avg. Disk sec/Transfer< 20 ms en production, < 5 ms hors charge. - Current Disk Queue Length stable < 2.
- Statut SMART « OK » pour tous les disques.
- Backups testés : restauration incrémentale & bare‑metal réussies.
FAQ rapides
Dois‑je remplacer tout le serveur ? Non : dans 80–90 % des cas, un disque ou le chemin HBA/SAN suffit à expliquer l’ID 153. Procédez incrémentalement et vérifiez après chaque changement. Puis‑je ignorer quelques ID 153 isolés ? Un événement unique après un hot‑remove de baie ou un patch peut être bénin. Un pattern régulier ou croissant impose une action immédiate. Le correctif Windows réduit‑il la latence ? Certains cumulative updates ajustent les timeouts StorPort ou corrigent des fuites de mémoire kernel. Tenez votre OS à jour, mais ciblez surtout le firmware du contrôleur et le micro‑code disque. Quid des volumes ReFS ? ReFS est résilient, mais un périphérique lent déclenche aussi l’ID 153. Utilisez refsutil pour réparer, puis identifiez le matériel fautif.
Points clés à retenir
- ID 153 = réessai I/O, pas encore perte de données.
- La cause est majoritairement matérielle : disque, câble, contrôleur, firmware.
- Vérifiez et restaurez vos sauvegardes avant toute action intrusive.
- Une approche incrémentale limite les coûts et le downtime.
- Surveillez 7–14 jours pour valider la stabilité après correctif.
En suivant ce guide, vous pourrez distinguer une simple congestion logique d’une panne matérielle, rétablir un fonctionnement stable et prolonger la durée de vie de votre infrastructure sans remplacement complet du serveur.