En bref : notez une empreinte quand vous écrivez un fichier, et comparez-la plus tard. Si les empreintes diffèrent et que rien n'a modifié le fichier, les octets ont changé à votre insu.
Rien d'autre ne le trouve. Un disque atteint de corruption silencieuse passe S.O.S., affiche un état SMART sain et se monte parfaitement.
Le stockage est physique. Les domaines magnétiques d'un disque dur s'affaiblissent. La charge s'échappe des cellules de la mémoire flash, plus vite quand il fait chaud et plus vite encore quand le disque reste longtemps sans alimentation. Un câble peut perdre un bit en route. Les firmwares ont des bugs.
Les disques corrigent eux-mêmes l'essentiel, avec des codes correcteurs d'erreurs et en déplaçant les secteurs qu'ils voient se dégrader. La corruption qui compte, c'est celle qui passe au travers : une lecture qui renvoie d'autres octets que ceux écrits, et annonce un succès.
Le nom fait débat. Certains parlent de bit rot, d'autres de corruption silencieuse des données, d'autres de dégradation des données. Pour nous, c'est la même chose : le fichier est différent et rien ne l'a dit.
C'est la partie à comprendre, car elle explique pourquoi chaque outil auquel vous penseriez est le mauvais outil.
cp et le Finder lisent des octets et écrivent des octets. Si la lecture a renvoyé de mauvais octets, ils écrivent fidèlement les mauvais octets.La position honnête est donc : votre Mac n'a aucun mécanisme pour vous le dire. Le premier symptôme est une photo traversée d'une bande de pixels incohérents, une archive qui ne s'ouvre pas, ou une vidéo qui s'arrête à mi-chemin.
Rare par fichier, et pas rare sur une grande collection pendant longtemps, ce qui est justement le cas d'une sauvegarde. Deux choses augmentent nettement le risque :
Si cela compte plus dans une sauvegarde que sur votre disque de travail, c'est qu'un fichier de travail est ouvert, et un fichier corrompu ouvert est une corruption découverte. Une sauvegarde est écrite une fois et jamais lue, ce qui veut dire qu'une corruption dans une sauvegarde se découvre le jour où vous en avez besoin.
Notez ce que vous avez écrit :
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtPuis, des mois plus tard, demandez si c'est toujours pareil :
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Tout ce qui est affiché est un fichier dont les octets ont changé. Si vous ne l'avez pas modifié, vous avez votre réponse.
Deux remarques pratiques. Gardez le fichier d'empreintes ailleurs que sur le disque qu'il décrit, sinon vous perdrez les deux ensemble. Et cela prend autant de temps que la lecture du disque entier, programmez-le donc pour la nuit.
Tout ce qui précède est la raison pour laquelle l'app a la forme qu'elle a. Elle stocke chaque morceau d'une sauvegarde sous l'empreinte de son contenu, puis relit la sauvegarde selon un calendrier et vérifie chaque morceau par rapport à l'empreinte sous laquelle il a été stocké.
Une différence est donc une preuve : les octets ne sont pas ceux qui ont été écrits, et aucune interprétation ne rend cela acceptable. Un morceau supprimé sous la sauvegarde est signalé comme manquant. Et le score de l'écran principal ne compte que ce qui a été vérifié récemment, c'est pourquoi il est plus bas qu'on ne s'y attend, et c'est tout l'intérêt.
Avoir un second emplacement compte ici plus que partout ailleurs sur ce site. Une corruption dans une copie est un désagrément quand il y en a deux, et la fin du fichier quand il n'y en a qu'une.
Non. S.O.S. vérifie la structure du système de fichiers, pas le contenu de vos fichiers. Un disque aux fichiers corrompus en silence le passe sans problème, et c'est exactement ce qui fait la nature de ce problème.
Pas pour cela. SMART signale les erreurs que le disque a remarquées puis corrigées ou déplacées. La corruption silencieuse, c'est justement ce qu'il n'a pas remarqué. Cela vaut quand même la peine de vérifier pour un disque en train de lâcher, ce qui est un autre problème, bien plus visible.
Il contrôle ses propres métadonnées, pas les données de vos fichiers. ZFS et Btrfs contrôlent le contenu des fichiers et peuvent réparer à partir d'une copie redondante, et aucun n'est disponible comme volume de démarrage ou externe ordinaire sous macOS. C'est pour combler ce manque qu'une vérification au niveau de l'application vaut la peine.
Assez souvent pour qu'une copie abîmée soit trouvée tant qu'une bonne copie existe encore. Tous les trimestres est raisonnable pour une archive ; tous les mois si c'est la seule copie de quelque chose d'irremplaçable. La bonne réponse est la fréquence que vous ne sauterez vraiment pas, ce qui plaide pour l'automatisation.
Non. La vérification vous dit qu'une copie s'est abîmée. Elle ne peut pas vous rendre le fichier. La détection n'est utile que s'il existe une deuxième copie à partir de laquelle restaurer, et c'est tout l'argument de la règle 3-2-1.
À lire aussi : comment vérifier qu'une sauvegarde est lisible, le format du dépôt, et la règle 3-2-1.