Re: disques!!

Hello

> A ma connaissance non, mais peut etre est-ce possible si tu fais tes 
> sauvegardes en clonant le disque avec "dd", a confirmer/infirmer par
> d'autres 
> guildiens.

Effectivement, je confirme qu'un SSD "en fin de vie" fournit volontiers
de données aléatoires sans erreur franche à la lecture (en écriture
oui)... Enfin c'est ce que j'ai constaté avec un SSD de laptop au
boulot. Avec Windows trop tolérant et silencieux vis-à-vis des erreurs
disque, un agent de contrôle SMART avec suivi du event viewer est quasi
obligatoire pour dormir tranquille.



On Wed, 2017-07-19 at 17:29 +0200, samuel veyre wrote:
> Merci ALD pour tes explications limpides !
>
> Concernant le risque de contamination du disque de sauvegarde par le
> disque principal défaillant, voici mes suppositions :
>
> Le système d'exploitation est suffisament "intelligent" pour
> reconnaitre les endroits perdus du disque principal et ne les utilise
> plus pour enregistrer de nouvelles données. Le système d'exploitation
> agit alors comme une sorte de policier interdit l'accés à une zone de
> crime et qui réorganise la circulation : Les nouvelles données sont
> donc "détournées" de leur zone de stockage prévues pour étre
> orientées
> ailleurs vers une zone de stockage saine et sécurisée.

Effectivement, le système d'exploitation dispose d'une gestion de
"badblocks" au niveau des systèmes de fichiers. Encore faut-il
l'activer, tourner fsck avec l'option, et ça n'a de sens qu'avec du
disque classique à plateau.

Cependant ce mécanisme peut être considéré comme "obsolète" puisque le
contrôleur d'un disque supportant SMART réalise souvent cette opération
avec redirection des zones défectueuses vers des secteurs de réserve...
à suivre dans les mesures SMART.


> La sauvegarde (par rsync dans mon cas) n'est donc pas concernée par
> la
> défaillance du disque dur principal car elle ne travaille que sur les
> nouvelles données rangées proprement en sécurité. Le problème  est
> donc réglé EN AMONT par le système d'exploitation.

Effectivement avec un système en fonction, un rsync devrait échoué au
premier problème d'accès au disque, à l'exception des fichiers en cache
mémoire. Mais globalement avec "errors=remount-ro", tu constates
rapidement qu'il y a eu un soucis. Personnellement, j'ai un check de
monitoring qui lève une alerte dès qu'un file system se retrouve en
read-only.

Un risque significatif apparaît surtout au reboot - c'est là que l'on
découvre que la table de partition ou les superblocks/MFT sont
corrompus. Et c'est en général trop tard.

Mais tout est possible. Comme Patrick dont les trois disques ont reçu
des écritures sur la table de partitions... est-ce que l'alimentation
défaillante a introduit de erreurs dans les messages SATA, dans les
calculs du contrôleur ou les mouvements des bras ? on ne le saura
probablement jamais.


Quelques points à retenir d'après moi:
- inclure un dump des tables de partitions par sfdisk dans le backup
- monter les systèmes de fichiers avec errors=remount-ro
- monitorer les valeurs SMART, l'absence de FS read-only
- monitorer les logs du kernel
- vérifier l'intégrité des backups régulièrement
- ne faire aucune confiance à un SSD en fin de vie
- pratiquer un peu testdisk / photorec pour se faire la main
hors stress et constater que ce n'est pas miraculeux

--
Yves Martin