Possible corruption de données sur serveurs NAS QNAP
Sur certains serveurs NAS de la marque QNAP, un bug fausse la reconstruction des données manquantes.
Sur certains serveurs NAS de la marque QNAP, quand un disque tombe en panne dans un volume RAID5, un bug fausse la reconstruction des données manquantes.
Il est possible que le bug touche également d'autres constructeur de serveurs NAS basés sur un noyau Linux.
-17 juillet 2017
Un blog rend public le problème
Article complet : www.sbsfaq.com
Traduction d'un extrait significatif : "-Si un disque tombe en panne dans un agrégat RAID5, le serveur QNAP doit reconstruire les données manquantes en utilisant les blocs de parité, mais va faire des erreurs dans les calculs, ce qui fournira des données incorrectes. Si vous remplacez le disque qui était tombé en panne, les mêmes erreurs auront lieu à la reconstruction de la redondance. En bref : si vous avez un volume RAID 5 sur un serveur NAS QNAP, et si un disque tombe en panne, alors vous aurez nécessairement une corruption de données" (aux conséquences plus ou moins graves -NDLR-).
-19 juillet (dans le blog), et 25 juillet (site QNAP) : réaction de QNAP
"Important QTS Update for Potential Silent Data Corruption on NAS Using RAID 5/6"
Article complet : www.qnap.com/fr-fr/technical-advisory/tec-201707-01
Le problème serait du à l'activation en juin 2016 d'un paramètre "Skip_Copy" dans le module Linux de gestion des RAID
Les matériels QNAP concernés sont ceux contenant des firmwares datés de début juin 2016 à fin février 2017
Solution : installer un nouveau firmware, puis exécuter une vérification de l'aggrégat (RAID scrubbing) ; cette vérification corrigera les éventuelles erreurs contenues dans les blocs de parité
Vous noterez la différence entre le blog et le communiqué de QNAP (bien que le résultat soit le même...) :
-Blog : les erreurs se produisent à la lecture sur un RAID5 dégradé
-QNAP : les erreurs se produisent à la génération des blocs de parité
Etant donné que QNAP demande à exécuter un "RAID scrubbing", on peut supposer que les erreurs se produisent bien dès le génération des blocs de parité (deuxième hypothèse), sinon, il aurait suffit de mettre à jour le firmware pour corriger le problème.
Moralité : au risque de radoter : un volume RAID5, quel que soit le matériel, n'est pas suffisant pour se protéger d'une pertes de données ==> faite des sauvegardes ;-)
Source : Veeam Community Forums Digest [Jul 24 - Jul 30, 2017]