Le bitrot, comme l’idée d’un seul bit inversé passant inaperçu, est probablement un mythe basé sur une mauvaise lecture de la spécification commune des disques durs de 1 bit illisible tous les 1014 bits (ou parfois 1015). Il s’agit d’une statistique qui fait référence aux bits qui ne peuvent pas être lus du tout. Cela signifie peut-être que vous avez un secteur illisible de 512 octets tous les 400 PB. Peut-être les fabricants de disques durs font-ils simplement référence au secteur illisible standard qui apparaît dans SMART. L’idée qu’un seul bit puisse basculer et se glisser d’une manière ou d’une autre à travers chaque couche de vérification de parité matérielle et logicielle est assez peu plausible et je n’ai jamais vu de données empiriques ou un seul cas documenté de cela.
Mais il y a d’autres types de pourriture de données qui peuvent se produire à différents niveaux. Mais pourquoi parler de théories et d’anecdotes ? Nous sommes des datahoarders, non ?
J’ai pris 70 To de données (environ 300 000 fichiers) et stocké deux copies sur des ensembles distincts de disques durs. Un ensemble est allé dans le stockage froid, l’autre ensemble a été utilisé activement et déplacé / copié autour entre différents lecteurs et systèmes de fichiers. Le jeu stocké au froid était mis en rotation une fois par an pour empêcher le liquide de roulement de se déposer. Le jeu actif était déplacé/copié dans son intégralité peut-être 5 fois au total (disons 350 TB de transferts). Toute la RAM était non-ECC. Les disques durs étaient des modèles grand public de toutes marques. L’ensemble actif a passé un an dans ZFS sous FreeBSD (lorsque je me sentais particulièrement paranoïaque à propos de bitrot et que je voulais les CRC des fichiers), le reste du temps dans NTFS sous Windows 7.
Après 7 ans, j’ai effectué un contrôle MD5 sur les deux ensembles de données. Il y avait 12 fichiers qui ne correspondaient pas.
Fichier 1 – Fichier de données de jeu, 2 KB. Taille identique, contenu significativement différent, et la copie active avait une date plus récente. Il ressemble à un fichier cache de jeu et a été soumis à des modifications par le jeu lui-même. Aucun dommage.
Fichier 2 – Fichier de sauvegarde Steam, 832 Mo. Taille identique, contenu significativement différent, et la copie active était plus récente de 2 heures. Il semble que ce soit simplement une sauvegarde plus récente que j’ai faite. Aucun dommage.
Fichier 3 – Vidéo, 399 Mo. La copie de sauvegarde a les premiers 64K remplacés par des nuls, et ne joue pas. Taille et date identiques.
Fichier 4 – Vidéo, 19 Mo. La copie de sauvegarde a les premiers 64K remplacés par une section d’un texte qui était autrefois dans le presse-papier de mon bloc-notes, et ne joue pas. Taille et date identiques.
Fichier 5 – Vidéo, 11,7 Go. Les fichiers diffèrent de 232 octets à l’offset 9,693,699,010. Les deux contiennent des données compressées indiscernables. Les deux vidéos jouent.
Fichier 6 – Vidéo, 2.9 GB. Les fichiers diffèrent par 251 octets à l’offset 1,039,651,777. Les deux contiennent des données compressées indiscernables. Les deux vidéos sont jouées. Taille et date identiques.
Fichier 7 – Vidéo, 9,4 Go. Les fichiers diffèrent de 47 octets à l’offset 3 976 714 817. Les deux contiennent des données compressées indiscernables. Les deux vidéos sont jouées. Taille et date identiques.
Fichier 8 – Vidéo, 4,6 Go. Les fichiers diffèrent de 232 octets à l’offset 627,313,318. Les deux contiennent des données compressées indiscernables. Les deux vidéos sont jouées. Taille et date identiques.
Fichier 9 – Vidéo, 6,2 Go. Les fichiers diffèrent de 104 octets à l’offset 1 496 829 600. Les deux contiennent des données compressées indiscernables. Les deux vidéos sont jouées. Taille et date identiques.
Fichier 10 – Vidéo, 8,5 Go. Les fichiers diffèrent de 512 octets à l’offset 6 517 833 728. Les deux contiennent des données compressées indiscernables. Les deux vidéos sont jouées. Taille et date identiques.
Fichier 11 – Vidéo, 1 GB. La copie active a 54 784 octets corrompus à l’offset 684 589 056. Les données corrompues comprennent de gros morceaux de nuls, des octets répétitifs et des sections de texte incluant « root_dataset », « sync_bplist », « vdev » et « zpool create » qui semblent être liés à ZFS. Taille et date identiques.
Fichier 12 – Vidéo, 817 Mo. La copie active a 43 520 octets corrompus à l’offset 418 578 432. Les données corrompues sont du même type que celles trouvées dans le fichier 11. Taille et date identiques.
Nous avons donc 4 types de corruption de données ici.
Les fichiers 1 et 2 n’ont pas vraiment de corruption, ils ont juste échoué à correspondre parce qu’ils avaient été modifiés.
Les fichiers 3 et 4 avaient exactement 65 536 octets remplacés au début du fichier avec apparemment des trucs aléatoires de la mémoire. Je n’ai pas d’explication pour cela, mais cela a dû se produire au moment de la sauvegarde, car la version active était encore bonne. C’est peut-être parce que j’ai utilisé SuperCopier, qui n’est probablement pas complètement exempt de bogues. Une fois, je l’ai vu écraser un fichier parce que le nom de fichier long d’un fichier dans la file d’attente correspondait au nom de fichier 8.3 d’un fichier à la destination, mais c’est un cas assez rare. Je n’en suis pas sûr.
Les fichiers 5-10 ont tous le même type de corruption. Un petit morceau de données contiguës à un endroit aléatoire du fichier a été changé en une chaîne de données d’apparence similaire. C’est trop petit pour être détecté par lecture, donc je ne sais pas quelle est la bonne copie. Aucune idée de ce qui a provoqué cela.
Les fichiers 11 et 12 ont clairement des dommages dus au stockage sous ZFS. J’ai lancé un scrub chaque semaine et FreeBSD trouvait toujours quelque chose de « mauvais » et le réparait. Il n’était pas clair pour moi ce que ces erreurs étaient ou pourquoi elles se produisaient, mais cela m’a donné une mauvaise vibration. Je suis passé à FreeBSD en premier lieu pour les CRCs des fichiers de ZFS, mais après un certain temps j’ai pensé que si NTFS avait des fichiers corrompus partout, le monde entier le saurait. Mais la principale raison pour laquelle je suis revenu à Windows était que je n’aimais pas l’interface FreeBSD.
J’ai rencontré un 5e type de corruption. La plupart des vieux disques Seagate 1,5 To en chambre froide ont commencé à développer des secteurs défectueux. Cela a été détecté lorsque j’ai exécuté la vérification annuelle du spin-up, et les disques ont été remplacés avant que des données sur eux ne soient endommagées.
Je garde toujours un enregistrement de hachage MD5 de mes sauvegardes, mais je ne m’inquiète plus de bitrot. Je ne crois pas qu’il existe un phénomène qui retourne secrètement des bits individuels ici et là. Si c’était réel, j’aurais dû voir appox 28 bits isolés retournés entre les ensembles.
Pour des conseils pratiques, je recommande de garder une sauvegarde hors site de tout, plus une sauvegarde supplémentaire des choses importantes comme les photos de famille. Assurez-vous périodiquement que vos sauvegardes peuvent être restaurées. Je recommande également de générer des listes de fichiers afin que vous ayez un moyen de savoir ce qui doit être restauré en cas de panne de disque, et des hachages de fichiers afin que vous puissiez détecter les rares cas de corruption de fichiers. Je ne recommande pas le RAID pour tout ce qui concerne les sauvegardes.
Je pense personnellement que la stratégie de sauvegarde 3-2-1 est un peu lourde pour être utilisée dans tous les cas – je ne vais pas garder 3 copies d’un vieil ISO Linux.