Bonjour à tous,
 
Je viens d'acheter un SSD MX500 4To sur lequel j'ai voulu copier le contenu de mon ancien SSD EVO 870 1To acheté en 2021.
 
Problème : je m'aperçois à cause d'erreurs du copieur de fichier Windows que certains fichiers stockés sur le SSD EVO sont corrompus. Ce sont quelques archives .rar, deux vidéos, quelques photos.
 
Je ne comprends pas comment c'est possible. Avant d'être sur ce SSD EVO, ils étaient sur un autre disque et les fichiers étaient normaux. Je n'ai rien fait de particulier depuis.
 
Ce SSD EVO est-il défectueux alors qu'il apparait en bonne santé dans Samsung Magician ?
 
Dois-je faire un checkdisk ?

hello,
 
installe crystaldisk info pour vérifier l'état des deux disques,
https://crystalmark.info/en/download/#CrystalDiskInfo
 
fais un screen, upload le sur imgbb.com et poste le lien BBCode sur le forum si t'as un doute sur l'interprétation des infos,

Tu peux aussi faire un error scan complet avec HD Tune , avec un SSD 1To c'est assez rapide...

Voici ce que ça donne, j'ai comme l'impression que ça sent mauvais...
 

 

 

 

Oui je pense qu'il faut commencer à penser à l'envoyer en SAV, avec plus de 100 blocs retirés et si peu d'écritures sur le SSD, il y a clairement un problème.

Mince, j'ai un deuxième SSD EVO 870 1To acheté en même temps qui a également quelques blocs retirés...
 
Concernant les données perdues, sont-elles récupérables en faisant un checkdisk de réparation ?

Je viens de refaire une analyse du disque et bizarrement, certaines zones qui étaient bonne sont devenues endommagées, et d'autres endommagées sont devenues bonnes...
 
Et comme la première fois, l'analyse ne va pas jusqu'au bout...
 

Il date de quand ?
Il y a une histoire de quelques batches de 870 Evo a priori de fin 2021, plutôt en 2 et 4Go mais probablement pas uniquement, avec un sérieux problème de durée de vie qui se manifeste comme le tiens après un certain temps.  
C'est bien documenté, pas mal de cas identifiés.

Ces EVO 1To ont été achetés en avril 2021 sur Amazon.
Effectivement, je me rends compte que maintenant que ce modèle était potentiellement défaillant...
Heureusement, j'ai des copies de la plupart des fichiers endommagés et ceux dont je n'ai pas de copie ne sont pas très importants.
Ca me motivera à avoir une politique de sauvegarde plus sérieuse et de vérifier la santé de mes disques de temps en temps.
Go le SAV maintenant !
 
Merci pour l'aide

Les 2 datent de 2021 c'est vraiment la mauvaise période   en tout cas sur le topic consacré au souci de ce SSD sur techpowerup, il n'y a peu près que ça, apparemment le process de fabrication aurait changé à partir de novembre 2022 d'après le changelog du firmware Samsung SVT02B6Q, donc perso je ne toucherais pas à un 870 evo fabriqué avant cette date.
 
Bon si tu as des sauvegardes comme il faut, ce n'est pas grave. Sinon un checkdisk ne donne rien, il faut utiliser des logiciels de récupération souvent payants, sinon il y a des solution de clonage vers un disque sain à base de live cd linux pour récupérer un maximum de données style ça : https://www.hddsuperclone.com/hddlivecd ça à l'air assez barbare dans tous les cas je trouve que c'est plus simple de faire des sauvegardes régulièrement.
 
Mais le résultat n'est jamais garanti donc pour des données de faible valeur je sais pas si ça vaut la peine.

Ma demande de RMA est en cours. Le SAV n'a posé aucun soucis
 
Bien que les fichiers corrompus ne soient pas importants, je vais voir pour les récupérer.  
 
Mais je ne vois pas trop comment un logiciel pourrait faire ce miracle, vu qu'ils ne pourront pas lire les secteurs défectueux... Je vois leur utilité pour des fichiers supprimés, une partition foirée, lorsque les données sont lisibles mais dont les pointeurs ont disparu, mais là il me semble qu'aucun logiciel ne pourra lire les secteurs abimés...
 
Je me trompe peut-être ?

Ce qui est corrompu n'est pas récupérable je pense, l'idée c'est de récupérer tout ce qui n'est pas corrompu. Après comme Samsung n'a jamais clarifié quel est le problème exactement on ne peut pas savoir si c'est le contrôleur qui pose problème ou la NAND qui est défaillante.
 
Tuto ddrescue https://www.malekal.com/ddrescue-co [...] endommage/
 
Récupérer un fichier précis qui est corrompu je pense pas que c'est possible, a moins qu'il y ait un vrai expert ici qui puisse nous renseigner mais les SSD pardonnent moins quand ils dysfonctionnent, c'est assez clair.

T'es dur là quand même .

J'ai deux 870 Evo, un 2 To et un 4 To, respectivement de janvier 2022 et septembre 2021, et les deux sont comme neuf. Par contre clairement ils n'ont pas une vie traumatisante, le premier fait du 24h/24 (serveur applicatif) mais chacun d'eux a à peine plus de 6To d'écriture dans les pattes.

A propos de la capacité à relire un secteur HS, ça dépend des cas. Généralement c'est plus une histoire de "pas fiable" ou "bizarrement trop lent à lire" que de "complètement illisible". En schématisant, sur un HDD par exemple, les logiciels de récupération peuvent demander à tenter de relire la zone jusqu'à arriver à en tirer quelque chose.
Sur un SSD, je ne sais pas si le contrôleur permet de forcer l'accès à un bloc "retiré", ou s'il est définitivement impossible de l'adresser, même en lecture à des fins de récupération de données, mais j'imagine qu'il y a le même genre de mécanismes bas niveau pour tenter de lire les données.
La question est intéressante, si quelqu'un qui connaît bien l'implémentation de la récupération de données et l'adressage direct des blocs passe, moi aussi je suis curieux des réponses !

(Doublon, désolé, message à supprimer)

Merci à tous pour vos réponses.
 
TotalRecall : ton idée de logiciel qui lirait les secteurs défectueux en boucle jusqu'à ce que ça fonctionne m'a donné l'idée de le faire manuellement... et ça marche !
 
J'avais même pas pensé à cliquer sur "recommencer" du copier/coller de Windows. Je viens de récupérer quelques fichiers comme ça et je pense pouvoir récupérer la totalité de 30 fichiers corrompus
 
Et ma demande de RMA a abouti, j'ai l'étiquette UPS.  
 
Donc j'ai vraiment de la chance sur ce coup ! Merci encore !
 
Edit : en fait non, ça marche pas totalement... Effectivement j'arrive à copier les fichiers en insistant, mais les données sont corrompues quand même : les photos ont des artefacts, les fichiers rar sont foirés (erreur CRC), etc... Mais les vidéos sont lisibles. Ca tombe bien, car les vidéos étaient celles que voulais récupérer. Le reste est vraiment sans importance.

Pour tes données, ce sont en effet les vidéos qui (selon le format etc) sont les plus tolérants aux erreurs. Pour un fichier JPG un seul bit de foiré au mauvais endroit va pourrir tout ce qui vient après dans le bitstream.

+1 pour en savoir plus sur les mécanismes bas niveau, mais au niveau fabriquants ça doit NDA++ et au niveau des boîtes de récup qui savent faire (suite à leurs propres recherches ou des infos "insider" ou ...) ils ne vont pas donner les détails non plus.

EDIT: Si tu as trop de temps et que t'y connais un peu en prog, on pourrait faire n copies de chaque fichier et comparer au niveau binaire pour essayer de reconstruire les données correctes par vote majoritaire ou un algo plus sophistiqué. Mais clairement ça ne vaut la peine que si on a des fichiers très importants et beaucoup de temps (et d'aspirine ).

J'avais justement pensé à la même idée que toi : mettons qu'il y ait 1 bit foireux, on essaie 0 et 1, et on regarde si le fichier devient cohérent. S'il y en a 2, on test les 2² possibilités, si 3, 3², etc...  
 
J'ai vraiment aucune idée de combien de bits déconnent, combien il y a de bits par secteur, etc...  
 
Je suis développeur mais plutôt Web. J'ai fait du C++ il y a trèèèès longtemps. Mais normalement un développeur peut s'adapter à tous les langages. Y'a une idée à creuser, et ça m'intrigue et m'intéresse  

Des bits par secteurs il y en a probablement beaucoup trop. Généralement les HDD modernes et je suppose aussi les SSD ont des secteurs de 4ko [EDIT: A priori non, 512 octets plutôt ], ça en fait des bits... Et les fichiers compressés c'est de la m*** à décoder à la main / à développer des algos de réparation ou autre. Les specifications, si elles sont ouvertes (comme pour le JPG), sont souvent assez indigestes ou franchement "imbittables" je crois qu'on dit (formats vidéos).

(Je sais un peu de quoi je parle. )

EDIT: Par contre ça ne coûte rien de tenter. Windows aucune idée, mais sous Linux faire disons 1000 lectures du fichier et stocker les résultats c'est 3 lignes de bash en gros.

Effectivement, je viens de lire un article qui explique les secteurs, et ça en fait des bits... 4096 octets, donc 32 768 bits, donc 1 073 741 824 combinaisons possibles... [Edit : calcul faux   ]
 
A moins que les secteurs soient divisés en groupes de 512 octets comme j'ai pu le lire, et que ces groupes soient foireux indépendamment, ça ferait moins de combinaisons...
 
Ou alors, quand on lit de très nombreuses fois un secteur foireux, chaque bit pris indépendamment aurait une probabilité un chouilla plus importante d'être juste plutôt que faux, et donc en faisant beaucoup d'essais, on pourrait retrouver les vrais bits...
 
Tout cela n'étant possible que si on peut lire un secteur, donc avoir un accès très bas niveau... J'ai aucune idée de si c'est possible en C++ par exemple.
 
Où juste lire le fichier comme tu le dis et retrouver les bits qui ne sont pas toujours les même comme tu le dis très justement
 
Edit : je me suis gourré dans les calculs, c'est pas n² mais 2^n possibilités... c'est encore pire  

A mon avis il suffirait de lire le fichier directement (beaucoup de fois) et au pire le diviser en blocs de 4096 octets, car un fichier commence toujours avec un bloc entier ("sector boundary" ) (sauf système de fichier bizarre ). Le soucis de descendre plus bas c'est qu'il faudrait déjà "traverser" le système de fichiers (genre NTFS) et ensuite on ne sait rien de comment les blocs sont organisés physiquement sur le SSD, car il y a abstraction à travers l'adressage LBA (logical block adress je crois). Aussi au pire il faudra se lancer dans les commandes SCSI ou ce genre d'emmerdes. Bref, on risque d'y passer du temps si on se lance sur cette piste et encore plus sous Windows. (Tu es familier avec Linux? Certaines choses y sont bien plus simples à faire.)

Tu peux toujours faire un truc basique pour voir: Tu prend un langage qui t'es familier et tu lis le fichier N fois en faisant attention de ne pas tomber dans un piège avec des caches de lecture ou similaire. Ensuite une bête comparaison binaire / un vote majoritaire pour chaque bit ça ne doit pas être sorcier à coder. Si jamais tu as une image que tu peux partager (genre une photo de paysage ou similaire), normalement la semaine prochaine j'aurais la fibre et je pourrais en télécharger des Mo, donc si tu as moyen de mettre les N copies en ligne quelque part je pourrais regarder aussi. Car la question m'intéresse, tu l'auras deviné.

EDIT: Par contre prudence, peut-être ton SSD finira par lâcher totalement et/ou les lectures et relectures vont encore empirer les choses. Je suppose que tu as déjà copié les choses importantes (vidéos)? Pour les images, fais tes tests sur un fichier qui n'est pas important. Le mieux serait encore de faire N copies binaires de tout le disque, mais là faut être la NSA pour avoir x To de stockage etc...

pour les vidéos , si elles étaient bien sur des secteurs défectueux et sont lisibles, tu auras certainement des passages avec des artefacts.  

Oui c'est vrai, ça peut aller du "à peine remarquable" à "catastrophe". Ca dépend notamment de l'espace entre les I-frames (des images entiers en gros) qui sont insérés entre les images "partielles" P et autres qui ne codent que les changements visibles. Faut tester...

Je vais devoir renvoyer ces disques, donc je n'aurais pas énormément de temps pour faire des tests. J'ai déjà copié tout ce que je pouvais, donc je peux m'amuser avec (d'autant qu'ils seront surement détruits par Samsung).
 
Je vais essayer de faire un bout de programme demain en PHP car c'est ce que je maitrise le plus !

Avant de me lancer dans une programmation, j'ai copié plusieurs fois le même fichier corrompu pour voir s'ils étaient différents : ils sont toujours identiques. En plus, une fois que la copie a marché une fois, toutes les suivantes fonctionnent. Je pense que le fichier est tout simplement mis dans la RAM du SSD et ils ne va donc plus chercher dans les secteurs.
 
A mon avis, c'est peine perdue...

Oui, cache du SSD et/ou de l'OS, mais probablement SSD. Faudrait voir si il y a une commande pour vider le cache, au pire lire quelque Mo/Go de données au pif? Mais ça prend du temps, forcément. Il est tard, faut que je me couche, je ne peux pas faire des recherches la, désolé.

Je réponds à l'arrache mais je pourrais élaborer plus tard.
 
C'est pas vraiment une histoire de langage de programmation, mais d'API mises à disposition par l'OS et de niveau auquel on veut descendre.
 
Il fut un temps où on pouvait faire de l'adressage direct, genre "lis moi tel C / H / S / T du disque" mais c'est fini. Maintenant entre le cache, le LBA et les couches d'abstraction insérées par l'OS, faut passer par des APIs assez cryptiques d'une part pour lire un bloc donné, d'autre part pour savoir ce qu'on va y trouver (tel bout de tel fichier).
Ex (non vérifié mais bon pour illustrer le côté imbitable ) : https://www.codeproject.com/Article [...] sk-Sectors
 
La plupart des langages permettent de faire du PInvoke, rien n'oblige à faire du C (mais ça peut vite devenir chiant avec un langage qui ne gère pas les types de données requis, etc).
Il est également possible que des wrappers plus ou moins haut niveau pour ces API aient été écrits dans des langages plus accessibles, genre en Python ou .Net.
 
En tout cas, si tu veux dépasser le simple "File.Read()" (donc fonction haut niveau) ça va vite devenir costaud, mais tu pourrais déjà commencer par ça.
 

 
Un secteur = 512 octets pour un HDD/SSD sauf exception exotique qu'on va zapper (notion liée au découpage physique disque)
Un cluster = généralement 4096 octets, mais potentiellement carrément autre chose (notion introduite par le file system qui dépend donc du FS et bcp de la taille du volume, que ce soit en FAT, exFAT ou NTFS ou autre : il y a des valeurs types par taille et par FS)

Pour les Samsung, Magician permet de faire des Diag avec tentative de réparation

Il me semblait qu'on était passé à 4096 octets? J'ai pris au pif une doc d'un HDD Seagate Barracuda ( https://www.seagate.com/content/dam [...] 04656f.pdf ), mais ça doit être l'heure , je ne comprend pas très bien:

 
 
Sinon oui, si on veut faire autre chose que du haut niveau faut prévoir de l'aspirine.  
 
Après je suppose que le SSD en question est déjà reparti ou repartira demain vers le fabriquant, mais la question reste intéressante. Y'avait d'ailleurs un article assez intéressant sur les soucis de récup' de données (sur les HDD encore), faudrait que je vois si je le retrouve.
 
EDIT: Ah ben non, tu as raison (forcément, t'es modo ). Pour mon SSD interne smartctl me dit clairement

 
Autant pour moi

J'avoue que j'ai un peu lâché l'affaire...
 
J'ai mon étiquette de retour UPS, je vais envoyer les disques aujourd'hui !
 
En tous cas merci à tous de vous être penchés sur mon problème  

Ahah je ne m'attendais pas à autre chose.
Ecrire un script qui lit des fichiers c'est très facile (et potentiellement instructif si tu fais juste du dév web front habituellement), le faire en bas niveau que ce soit en passant par l'OS ou par le système (à condition de booter hors windows donc, mais tout en ayant accès aux drivers du hardware récent et cie ) c'est carrément autre chose.
Mais comme tu l'as signalé plus haut en ayant suivi indirectement ma suggestion de "tenter jusqu'à ce que ça marche", ça peut déjà aider à récupérer des fichiers sur un disque un peu mou de façon plus efficace qu'en passant par le copier/coller de fichiers Windows.
Si à la fin t'as pu tout récupérer en insistant avant de renvoyer le SSD c'est l'essentiel !

 
Hello,
 
Je me permets de rebondir sur vos posts, mon EVO 870 (acheté en juin 2021) m'ayant lâché, j'ai fait une demande auprès de Samsung mais ça fait une semaine sans réponse, j'ai relancé ce jour avec une nouvelle demande mais sur leur site, il n'est fait mention nulle part de matériel informatique, à part de l'audio, vidéo, tablette...
Le chat étant impossible à ce sujet.
 
J'espère avoir une issue favorable mais j'ai des doutes
 
Merci