Comment vérifier les sommes de contrôle après avoir remplacé un disque défaillant

Vérifiez les données après un remplacement de disque à deux niveaux : terminez le scrub ou la vérification de cohérence du RAID, puis comparez les sommes de contrôle des fichiers avec un manifeste créé avant la panne ou à partir d’une sauvegarde fiable.

Une reconstruction réussie prouve que la redondance a été reconstituée, pas que chaque fichier a été comparé à une valeur indépendante connue comme bonne. Le meilleur processus conserve le manifeste original des sommes de contrôle, vérifie la couche de stockage, contrôle les fichiers critiques, et enregistre toute discordance avant de reprendre les écritures normales.

Terminez la reconstruction avant de commencer la vérification

Confirmez d’abord que le remplacement est un membre actif, que le RAID n’est plus dégradé, et qu’aucune erreur de lecture, écriture, somme de contrôle ou média n’a augmenté pendant la reconstruction. Une cible qui reste en réserve, prête ou en cours de reconstruction n’est pas prête pour une décision finale d’intégrité des données.

Enregistrez le rapport final de reconstruction et les numéros de série des périphériques. Si la reconstruction a enregistré des secteurs illisibles sur un membre survivant, ne cachez pas cet événement derrière un écran de statut propre. Un RAID reconstruit peut toujours contenir une perte au niveau du fichier lorsque les données sources n’ont pas pu être lues.

Exécutez l’opération complète d’intégrité du RAID

Utilisez la vérification complète prise en charge par la plateforme : un scrub ZFS ou Btrfs, une vérification de parité md, ou la vérification de cohérence du contrôleur matériel. Cela lit des données que l’utilisation ordinaire peut ne pas toucher et les compare avec des sommes de contrôle, des miroirs ou de la parité selon l’implémentation.

Un resilver et un scrub ne sont pas interchangeables. La différence entre scrub et resilver est importante car le remplacement copie les données nécessaires pour le nouveau membre, tandis qu’un scrub examine l’ensemble du pool à la recherche d’erreurs silencieuses.

Utilisez un manifeste préexistant pour une preuve au niveau du fichier

Un hachage de fichier n’est utile que s’il peut être comparé à une valeur antérieure de confiance. Une somme de contrôle générée après le remplacement décrit le fichier actuel mais ne peut pas prouver que le contenu est resté inchangé depuis la panne.

Pour les fichiers Linux, la vérification du manifeste SHA-256 peut générer et vérifier une liste avec sha256sum. Conservez le manifeste sur un autre système ou une sauvegarde immuable afin qu’un incident de stockage ne puisse pas modifier silencieusement à la fois le fichier et son hachage attendu.

Vérifiez un ensemble représentatif lorsqu'aucun manifeste n'existe

Sans hachages antérieurs, commencez par les données irremplaçables et structurellement sensibles : dumps de base de données, archives, images de machines virtuelles, catalogues photo, conteneurs chiffrés et gros fichiers médias. Ouvrez ou testez le format natif en plus de calculer un nouveau hachage.

Un digest au niveau du répertoire peut révéler des modifications ultérieures, mais ce n'est pas une référence historique à moins qu'il ne précède l'incident. Les techniques pour un inventaire de somme de contrôle de répertoire montrent aussi pourquoi un tri stable et des chemins cohérents sont importants lorsque de nombreux fichiers sont inclus.

Séparez les contrôles de contenu des contrôles de métadonnées

Les hachages de contenu ignorent normalement la propriété, les permissions, les horodatages, les ACL, les attributs étendus, l'allocation parcimonieuse et les relations de liens physiques. Un fichier peut passer le SHA-256 alors que le comportement de l'application change encore parce que les métadonnées ont été perdues ou restaurées différemment.

Pour les services importants, validez depuis l'application vers l'extérieur. Un contrôle de cohérence de base de données ou un test d'archive peut détecter des problèmes logiques qu'un contrôle de somme de contrôle de bloc ne comprend pas.

Examinez chaque non-concordance avant de la réécrire

Ne régénérez pas immédiatement le manifeste après une vérification échouée. Conservez le fichier non conforme, le digest attendu, le digest actuel, le chemin, la taille, la date de modification et les journaux de stockage. Déterminez si le fichier a changé légitimement pendant le fonctionnement dégradé.

Un scrub de suivi propre après réparation est une limite utile : les erreurs corrigées doivent être suivies d'une autre exécution complète qui ne signale aucune nouvelle erreur. Des corrections répétées signifient que la cause n'est pas résolue.

Élaborez une procédure de vérification répétable

1. Gelez ou minimisez les écritures d'application et enregistrez le statut de reconstruction terminé.
2. Exécutez le nettoyage ou la vérification de cohérence au niveau du volume et enregistrez le rapport final.
3. Vérifiez le manifeste de sommes de contrôle de confiance avec le même algorithme et les mêmes règles de chemin utilisées à l'origine.
4. Validez les formats d'application critiques et comparez les métadonnées que les hachages de contenu omettent.
5. Relancez la vérification du stockage après toute réparation et exigez un résultat propre avant de clôturer l'incident.

Stockez le nouveau rapport d'incident séparément de la référence des sommes de contrôle. La référence ne doit changer que lorsque le contenu change intentionnellement, pas simplement parce qu'un disque de remplacement a été installé.

Enregistrez une nouvelle référence de confiance

Après la fin du nettoyage propre et des vérifications des fichiers, exportez un nouveau manifeste, un rapport de volume et un inventaire des membres. Étiquetez cela comme la référence post-remplacement plutôt que d'écraser les preuves plus anciennes, car les deux versions aident à expliquer toute discordance ultérieure.

Planifiez le prochain nettoyage de routine et un échantillon plus petit de sommes de contrôle tant que l'incident est encore récent. Un suivi précoce confirme que le remplacement, le chemin du câble et la redondance restaurée restent stables sous une charge de travail ordinaire.

FAQ

SHA-256 est-il meilleur que MD5 pour les vérifications de corruption accidentelle ?

Les deux peuvent détecter des modifications ordinaires, mais SHA-256 est le meilleur choix par défaut pour un nouveau manifeste et évite les faiblesses connues de collision de MD5. La cohérence de l'algorithme original est importante lors de la vérification d'un manifeste existant.

Un nettoyage réussi peut-il remplacer un manifeste de sommes de contrôle ?

Non. Un nettoyage vérifie selon les métadonnées du système de fichiers ou du RAID qu'il possède. Un manifeste indépendant compare le fichier actuel avec une valeur stockée en dehors du système de stockage affecté.

Faut-il ouvrir chaque fichier manuellement ?

Non. Hachez l'ensemble protégé complet lorsque c'est possible, puis effectuez des tests d'ouverture natifs ou de cohérence sur les formats à haute valeur et un échantillon représentatif de fichiers ordinaires.

La vérification est complète uniquement aux deux niveaux

Fermez l'incident de remplacement uniquement après que le volume ait passé une opération complète d'intégrité et que les fichiers critiques correspondent aux références externes de confiance. Un nombre sain de membres seul ne constitue pas un résultat de vérification de contenu.