Sauver un disque dur mécanique

Posté par  . Édité par Benoît Sibaud, Pierre Jarillon, Julien Jorge, ZeroHeure et Davy Defaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
42
14
fév.
2020
Matériel

Nous savons tous qu’un disque qui a des secteurs défectueux n’est pas réputé fiable, que ça ne coûte rien un disque de remplacement, etc. Il n’empêche que c’est dommage de jeter le disque, certaines pannes sont contournables. Nous allons voir comment nous en servir pour nous familiariser avec la structure du disque, de ses partitions logiques (LVM) et de son formatage, tout en sachant que la fiabilité d'un disque abîmé reste très aléatoire et que la réparation sera précaire.

Il ne s’agit pas ici de récupérer des données (vous aviez des sauvegardes, n’est‑ce pas ?) mais uniquement de pouvoir réutiliser le disque. Voyons comment faire…

HS et HS

J’ai joué sur mon temps libre à essayer d’utiliser un disque de 1 To qui a énormément de secteurs défectueux suite à une chute allumé. Ce qui rend cette panne intéressante, c’est que le disque reste stable : les secteurs abimés n’augmentent pas dans le temps. Le disque est tout à fait fonctionnel si l’on utilise les « bonnes » zones. En revanche, il devient très lent et finit par réinitialiser l’interface SATA si on lit aux mauvais endroits.

Il nous faut donc choisir les bonnes zones et les assembler ensemble pour avoir quand même une « grosse » partition virtuelle utilisable. Une stratégie possible est de créer une partition logique par zone correcte, et de les assembler dans un seul volume logique avec LVM.

Travailler hors disque

Pour travailler sur le disque, il ne faut pas l’utiliser. J’utilise donc un média autonome de ma distribution préférée. Je commence par supprimer toutes les partitions, puis m’assure que le début du disque est correct car c’est là que sera stockée la liste des partitions avec dd.

dd if=/dev/sda of=/dev/null count=1000

Chercher les bonnes zones

Pour trouver les bonnes zones, il faut tâtonner. Cela veut dire essayer de lire le disque, jusqu’à ce que ça coince. Si la zone avant que ça coince est suffisamment grande, on en fait une partition logique.

Pour lire, on utilisera l’utilitaire dd combiné avec pv : ils permettent de lire des secteurs précis, tout en observant le débit constaté.

dd if=/dev/sda skip=nbSecteursSautés | pv > /dev/null

En faisant Ctrl + c dès que le débit baisse, j’évite de coincer trop longuement la lecture, et obtiens le nombre de secteurs lus. Ainsi, je trouve par exemple que la zone entre les secteurs 3 450 000 et 4 510 000 est correcte. Je le vérifie en la relisant précisément avec une commande similaire :

dd if=/dev/sda skip=3450000 count=4510000 | pv > /dev/null

Je peux alors créer ma partition. Comme il y en aura bien plus de quatre, j’utilise des partitions logiques dans fdisk, qui permet d’indiquer le secteur de début et le secteur de fin de chaque partition créée :

fdisk /dev/sda

Industrialiser (un peu)

Ce serait dommage de perdre tout ce travail sur une fausse manipulation, il est donc tentant de garder sous le coude la table des partitions prête à être recréée. L’outil sfdisk permet de générer un fichier avec les partitions existantes, et surtout on peut y ajouter les nouvelles partitions au fur et à mesure qu’on trouve des zones.

sfdisk -d /dev/sda > table_partitions.txt

En éditant ce fichier, on voit que les partitions sont simplement définies par un début, une longueur et un type. J’ajoute donc les lignes des zones trouvées :

/dev/sda6 : start=     4100000, size=  900000, type=8E
/dev/sda7 : start=     5100000, size=  900000, type=8E
/dev/sda8 : start=     6100000, size=  900000, type=8E

Ensuite on remplace la table de partitions :

sfdisk /dev/sda < table_partitions.txt

Oh, chouette ! On dirait bien que c’est tout le temps la même zone de 100 000 secteurs qui est HS, suivie de 900 000 corrects. Je peux extrapoler les partitions suivantes, tout en vérifiant avec la commande ci‑dessus que cette zone est bien lisible. En pratique, ça ne marche pas aussi facilement à tous les coups, les zones se décalent, mais, bon, tout dépend de l’espace disque requis. Pour ma part, une fois 10 Go trouvés, je pouvais m’installer un système sur le disque, et ajouter de l’espace plus tard.

Assembler l’espace

Les connaisseurs de LVM vous diront que c’est facile d’ajouter des volumes physiques à un groupe de volumes. Mais avec une soixantaine de partitions, un script aide bien. J’ai utilisé ça :

$i=5; while vgextend VG-disk-HS /dev/sda$i; do i=$(($i+));done

Et voilà, un beau disque tout prêt. Pour m’assurer de la qualité du résultat obtenu, j’ai créé une partition qui utilisait tout le volume VG-disk-HS, je l’ai formatée, puis je l’ai vérifiée en lecture‐écriture :

fsck.ext4 -cc /dev/mapper/VG-disk--HS-grosseBertha

Notez le double « c » qui permet un test non destructif en écriture.

Grappiller encore

Une fois le système installé, j’ai à nouveau du temps pour chercher des zones correctes, mais il est moins aisé d’ajouter des partitions : le disque est occupé en permanence. Qu’à cela ne tienne, on enlève un garde‐fou de sfdisk et ça passe :

sfdisk --no-reread  /dev/sda < table_partitions.txt
partprobe

J’en suis à soixante partitions, et cela ne met que huit secondes à l’allumage pour que LVM les rende disponibles. Le débit est très bon, puisque c’est le début du disque qui est sauvé.

Aller plus loin

  • # Une seule partition + e2fsck + badblocks ?

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Est-ce qu'il n'y aurait pas un moyen sensiblement plus simple de continuer à utiliser ce disque avec la procédure suivante :

    1. On vérifie que le début du disque est encore utilisable,
    2. On crée une partition sur tout le disque,
    3. On lance e2fsck avec l'option -c, ce qui devrait utiliser badblocks pour détecter les secteurs défectueux et les marquer comme tels dans le système de fichier.

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Une seule partition + e2fsck + badblocks ?

      Posté par  . Évalué à 5.

      Il me semble que badblocks va tester tous les secteurs défectueux, ce qui risque d'être très (mais vraiment très) chronophage et peu efficace pour l'objectif fixé.

      • [^] # Re: Une seule partition + e2fsck + badblocks ?

        Posté par  . Évalué à 1.

        Et badblocks risque surtout de détruire ce qu'il reste du disque.

        • [^] # Re: Une seule partition + e2fsck + badblocks ?

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Je comprends que ça soit chronophage. Mais pour ce qui est de détruire le disque ?

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Une seule partition + e2fsck + badblocks ?

            Posté par  . Évalué à 1. Dernière modification le 14 février 2020 à 13:32.

            Quand un disque est en train de mourir, la dernière chose qu'on veut faire c'est écrire des données dessus. On veut minimiser autant que possible toute opération dessus. Badblocks, surtout en mode écriture, lit puis réécrit les données puis les relit. Ça fait travailler intensément le disque et maximise les chances d'avoir encore plus de secteurs flingués. Puis surtout, ça ne vous avance à rien pour récupérer vos données.

            La meilleure stratégie reste de sortir dd if=/dev/votre-disque-mourrant of=/dev/votre-disque-sain pour sauvegarder en lecture seule, bloc à bloc, le disque mourrant vers un disque sain. Une fois que c'est fait, vous ne risquerez pas de perdre encore plus de données. Une fois que tout est sauvegardé, faites vous plaisir pour balancer badblocks ou ddrescue sur le disque, vous ne perdrez rien de plus.

            • [^] # Re: Une seule partition + e2fsck + badblocks ?

              Posté par  (site web personnel) . Évalué à 8. Dernière modification le 14 février 2020 à 15:37.

              La meilleure stratégie reste de sortir dd if=/dev/votre-disque-mourrant of=/dev/votre-disque-sain

              Je préfère copier dans un fichier dd if=/dev/votre-disque-mourrant of=fichier
              Ainsi on peut travailler sur la copie ou une copie de la copie (à condition d'avoir de gros disques). C'est ce que nous avions fait sur https://abul.org/Recuperation-de-donnees-sur-une.html

            • [^] # Re: Une seule partition + e2fsck + badblocks ?

              Posté par  (site web personnel, Mastodon) . Évalué à 9.

              Badblocks, surtout en mode écriture, lit puis réécrit les données puis les relit. Ça fait travailler intensément le disque et maximise les chances d'avoir encore plus de secteurs flingués.

              Du coup, oui c'est logique.

              Puis surtout, ça ne vous avance à rien pour récupérer vos données.

              Le postulat de départ, c'est qu'on a plus besoin de récupérer les données dudit disque.

              La connaissance libre : https://zestedesavoir.com

            • [^] # Re: Une seule partition + e2fsck + badblocks ?

              Posté par  . Évalué à 9.

              L'objectif ici n'est pas de récupérer les données sur le disque; mais d'obtenir un disque utilisable. Faire un test qui permet de s'assurer que le disque résiste un peu me semble donc une bonne idée.

  • # DDRescue

    Posté par  (site web personnel) . Évalué à 10.

    Ce ne serait pas plus simple, plus rapide et plus fiable de créer et d'utiliser la « map » de ddrescue ?

    C'est du texte avec les zones et leur état.

    Quelque chose du genre devrait être un bon début :
    ddrescue -n /dev/sdn /dev/null sdn.map

    Tu peux même pré-générer la « map » si tu connais certains secteurs morts.

    Et ensuite, reprendre la « map » pour faire les partitions de façon automatique.

    • [^] # Re: DDRescue

      Posté par  . Évalué à -4.

      tout comme badblocks, ddrescue va tester les secteurs 1 à 1, et prendre le temps nécessaire pour s'assurer que chacun d'eux est inutilisable, alors que la méthode décrite, si j'ai bien tout compris, décrète qu'un block entier de secteurs est inutilisable sans avoir à les tester individuellement

    • [^] # Re: DDRescue

      Posté par  . Évalué à 3.

      Ddrescue a même deux options qui peuvent identifier les zones rapides :

      • L'option --min-read-rate=bytes (par exemple --min-read-rate=10M). Le fichier mapfile résultant sautera les zones lentes. Seuls les 64 premiers kilo-octets de la zone seront récupérés. Il faudra alors trier les lignes du mapfile qui ont été lus avec succès (+ en fin de ligne) et ont une taille suffisante (deuxième nombre de la ligne moins 64 kio ; le premier nombre correspond à la position sur le disque).

      • L'option --log-rates=file. On obtient un autre fichier avec pour chaque zone, la vitesse de lecture. Attention, le fichier peut être volumineux.

      Cette signature est publiée sous licence WTFPL

      • [^] # Re: DDRescue

        Posté par  . Évalué à 4.

        Merci pour la piste, j'ai essayé au cas oú … mais c´est inutilisable avec ce problème de disque : il passe 4 minutes sur chaque zone abimée, je vais bien plus vite "à la main".

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # GPT

    Posté par  (site web personnel) . Évalué à 10.

    Plutôt que d'utiliser des partitions logiques avec MBR, autant partitionner au format GPT, qui permet d'utiliser un nombre arbitraire de partitions. Enfin presque : lorsqu'on crée une GPT, on alloue la place pour un nombre maximum donné de partitions. Ce choix est fait par défaut par l'outil de partitionnement, après quoi on ne pourra pas facilement le changer, mais je crois que la valeur par défaut est quelque chose comme 128.

    • [^] # Re: GPT

      Posté par  . Évalué à 3. Dernière modification le 16 février 2020 à 18:56.

      Merci, effectivement je viens de le passer en GPT et j'ai pu doubler le nombre de zones récupérées. Par contre j'ai pas encore trouvé comment faire plus de 128 partitions?

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Et DBAN ?

    Posté par  . Évalué à 7.

    Solution intéressante mais un peu fastidieuse à mon avis.

    Tu peux aussi utiliser un logiciel d'effacement de donnée comme DBAN, en faisant plusieurs passes d'écriture sur tout le disque avec des motifs différents (un peu comme un fsck -c sous stéroïde). Ça force le firmware du disque dur à marquer les secteurs défectueux et généralement ceux qui restent sont utilisable en un seul bloc, le firmware s'occupant d'éviter les trous.

    J'ai sauvé plusieurs disques comme ça, qui ont tournés quelques années de plus. C'est assez violent pour le disque et s'il est pas récupérable, ça fini de l'achever.

    • [^] # Re: Et DBAN ?

      Posté par  . Évalué à 8. Dernière modification le 14 février 2020 à 12:45.

      C'est ce que je fais aussi habituellement, mais de façon moins violente. Mais j'ai le même avis, si on veut continuer d'utiliser le disque il vaut mieux le stresser un peu pour savoir si il est encore fiable.

      J'utilisais l'outil MHDD (sous dos) disponible avec systemrescuecd, qui permet de faire un test de surface en lecture (avec des stats sur les temps d’accès pour chaque secteur) et un effaçage complet du disque (une passe d'écriture de '0x00').

      Maintenant, avec la disparation du BIOS remplacé par UEFI, j'ai trouvé un outil équivalent utilisable sous Linux : WHDD ( https://whdd.github.io ).

      • [^] # Re: Et DBAN ?

        Posté par  . Évalué à 3.

        Avec DBAN d'ultimate boot cd j'en ai sauvé aussi pas mal de disques durs, mais jamais quand il n'était plus détecté par le bios.

        Le cas d'un disque dur qui tombe allumé est assez rare, je ne connais pas la cause de l'apparition des secteurs défectueux, ce que fait DBAN c'est écrire des motifs aléatoire sur le disque dur et de continuer quoi qu'il arrive, il peut y avoir pas mal d'erreurs au premier passage, moins au deuxième.

        Sans avoir à graver un CD ou rebooter, dernièrement sur un deuxième disque sdb de 20Go le formatage se passait mal, badblocks trouvait plein de secteurs défectueux et c'est très long, dd coinçait très rapidement avec la commande dd if=/dev/zero of=/dev/sdb bs=512. J'ai donc créé une table de 3 partitions avec cfsisk 14/1/5Go, puis formaté sans vérif avec mkfs.ext4 -v -b 1024 /dev/sdb3, installé une distribution dessus. Au début les blocages avec reset du disque dur étaient fréquents, puis de moins en moins au bout d'une semaine plus rien. Même chose pour la première partition que j'ai utilisé pour compiler des sources, les arrêts avec reset du disques se sont espacés au point que je ne ferais même pas le bilan des secteurs défectueux, mais je suis à peu près sûr qu'un reformatage, un passage de badblocks ou la commande dd citée plus haut se passeraient mieux. J'ai pris 1024 pour taille des blocs c'est la plus petite avec ext4, jfs ou xfs permettent de descendre à 512 ce qui limite la casse, 1 byte fichu et c'est 1024 qui sont inutilisables.

    • [^] # Re: Et DBAN ?

      Posté par  . Évalué à 4.

      Tu peux aussi utiliser un logiciel d'effacement de donnée comme DBAN

      Hé non : tout accès "insistant" aux zones abimées du disque provoque un reset de l'interface SATA, avec /dev/sda qui disparaît puis réapparaît, et une interruption du coup du logiciel qui l'utiliserait.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # RAID 5

    Posté par  . Évalué à -1.

    Je pense que ce genre de disque, après sauvetage, peut être recyclé dans un RAID 5 : on ne perd rien s'il finit par lâcher et on peut reconstruire son contenu à l'aide des autres disques.

    Après, je suppose que ça impose de faire du RAID logiciel puisqu'on a pas accès au disque entier mais seulement à une partition elle-même composée de partitions… Je suppose aussi que ça limite l'espace total proposé puisque le RAID se limite à la taille du plus petit disque…

    Merci pour ton tuto en tout cas :-)

    • [^] # Re: RAID 5

      Posté par  (site web personnel) . Évalué à 10.

      A éviter absolument
      Si tu perds 2 disques sur les 3 de ton RAID 5 tu as tout perdu
      donc de mettre un disque "fragile" dans un RAID fragilise la totale

      La valeur d'un chaîne est égale à la valeur de l'élément le plus faible

      • [^] # Re: RAID 5

        Posté par  . Évalué à -2.

        La valeur d'un chaîne est égale à la valeur de l'élément le plus faible

        Le RAID 5 n'est justement pas une chaîne pour éviter ce problème de single point of failure !

        Si tu perds 2 disques sur les 3 de ton RAID 5 tu as tout perdu

        D'accord, mais si tu mets ton disque recyclé hors RAID, tu perds 1 disque tu as tout perdu. Donc mieux vaut l'utiliser dans un RAID non ?

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 7.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: RAID 5

          Posté par  (site web personnel) . Évalué à 7. Dernière modification le 15 février 2020 à 16:27.

          je comprends la volonté de recycler un vieux disque mais il ne peu servir que de disque temporaire et ne dois pas contenir de données importantes.

          C'est comme de faire du vélo en inversant les mains sur le guidon, tu sais que tu peu te faire mal

          Professionnellement un client me demanderais de le faire, je refuserais.

          Personnellement je ne le ferais certainement pas pour des amis / connaissances

          Le seul cas ou je vois l'utilisation d'un disque de ce style c'est pour une machine de test et depuis la virtualisation il n'y en a quasiment plus besoin.

  • # Relecture après l'heure

    Posté par  . Évalué à 2.

    Dans la partie "Industrialiser (un peu)", "tout besoin de l’espace disque requis" -> "tout dépend de l’espace disque requis" ?

    La partie "Aller plus loin" est volontairement vide ?

    Merci pour cette dépêche

  • # Forcer la réallocation

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 14 février 2020 à 14:28.

    On peut très bien forcer la réallocation des secteurs défectueux en écrivant dessus : le disque a normalement une réserve de secteurs non utilisés pour cet usage.
    soit avec dd (sans se tromper entre seek et skip, ça m'est arrivé), soit avec hdparm qui a une option --write-sector.
    On voit la différence avant/après dans l'état SMART avec Reallocated_Event_Count et Current_Pending_Sector.
    Le disque de mon T510 tourne depuis 2 ans avec 21 secteurs réalloués sans problème, il a 8 ans.

    J'ai d'ailleurs un article de prêt pour GLMF qui détaille ça ;-)

    • [^] # Re: Forcer la réallocation

      Posté par  (site web personnel) . Évalué à 1.

      (mais je fais des backups et j'ai un SSD prêt)

    • [^] # Re: Forcer la réallocation

      Posté par  (site web personnel) . Évalué à 5.

      Le disque de mon T510 tourne depuis 2 ans avec 21 secteurs réalloués sans problème, il a 8 ans.

      C'est un gros coup de pot ! Je n'ai vu que des disques où le nombre de secteurs réalloués augmentait de plus en plus vite.
      Ainsi un disque encore sous garantie avait quelques secteurs défectueux. Ce nombre augmentait assez doucement et restait dans les tolérances indiquées par smartctl (ou gsmartcontrol). Alors j'ai fait travailler le disque plus intensément et quand, au bout de quelques jours, j'ai eu dépassé la centaine de secteurs réalloués, j'ai pu renvoyer le disque au constructeur avant la fin de garantie, sans lui laisser la possibilité de la moindre contestation.

      Le retour n'étant pas instantané, il vaut mieux avoir un disque d'avance pour attendre le retour de chez le constructeur. J'ai envoyé le disque en France, il m'en est revenu un d'Angleterre…

      • [^] # Re: Forcer la réallocation

        Posté par  (site web personnel) . Évalué à 5.

        En effet ce n'est pas le cas le plus courant.

      • [^] # Re: Forcer la réallocation

        Posté par  . Évalué à 6.

        J'ai rencontré les deux cas: dans peut-être 10% des cas le nombre de secteur réalloué reste stable sur plusieurs années, et se limite à quelques secteurs ou quelques dizaines.

        Par contre, quand la somme des compteurs Current_Pending_Sector (avant réallocation) et Reallocated_Sector_Ct (après réallocation) augmente, ça annonce le mur en approche rapide, il est temps de passer commande d'un nouveau disque.
        Sur du SAS, smartctl remonte un compteur "Elements in grown defect list"

    • [^] # Re: Forcer la réallocation

      Posté par  . Évalué à 4. Dernière modification le 20 février 2020 à 16:00.

      On peut très bien forcer la réallocation des secteurs défectueux en écrivant dessus

      Oui, mais là on est bien après : le disque a déjà rempli tous les secteurs de réserve, et on ne peut plus compter sur cette réallocation automatique. On le voit avec les informations de smartctl : Offline_Uncorrectable est supérieur à zéro.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Avec le Device Mapper ?

    Posté par  . Évalué à 9. Dernière modification le 21 février 2020 à 01:13.

    Intéressant comme méthode, mais ta création de partition en masse m'a tout de suite fait penser à plutôt utiliser le device mapper, cf man dmsetup(8).

    Tu laisses ton disque non-partitionné, et tu crées un fichier qui contient la « table » des morceaux de disque que tu veux agréger dans un nouveau device, selon la syntaxe indiquée dans le manuel :

    0 900000 linear /dev/sda 4100000
    0 900000 linear /dev/sda 5100000
    …
    

    Ensuite tu crées le device :

    dmsetup create disque_aggrege --table ma_table.txt
    Sache que le Device Mapper est le mécanisme « bas-niveau » utilisé par lvm et dmraid (entre autres), c'est donc du « classique » mais que tu fais ici à la mano ! Par contre j'ai un petit doute sur l'imbrication de device (vu que tu va créer des mapping avec LVM sur ce device qui est déjà un aggrégat de mapping linéaire), mais je pense que ça passe normalement.

    Si tu veux voir comment ça fait avec tes devices LVM actuels, histoire de comprendre :

    dmsetup ls
    dmsetup table mon_device

    • [^] # Re: Avec le Device Mapper ?

      Posté par  . Évalué à 3.

      Ah oui, piste interéssante, mais je vais devoir faire de savants calculs puisqu'il me faut indiquer à chaque ligne le secteur de départ du dm, et celui de la partition.

      Voici la table avec des partitions pour le swap :

      0 892928 linear 259:100 2048
      892928 892928 linear 259:101 2048
      1785856 892928 linear 259:102 2048
      2678784 892928 linear 259:103 2048
      3571712 622592 linear 259:104 2048
      

      La quatrième colonne contient les majeur et mineur de la partition, qui ne changeront plus, tandis que le 2048 final est le décalage…

      J'explore ça, et je raconterai ici!

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Avec le Device Mapper ?

        Posté par  . Évalué à 4.

        Donc dmsetup ça marche, et ça m'a permis de ne plus créer une partition pour chaque bon bloc.
        Le gros avantage est le temps de boot, car 250 volumes physiques cela devenait un peu lent.
        J'ai donc seulement LVM pour le système, et home est monté à partir d'un tableau dm.

        La logique est : créer un partition dont le début et la fin sont dans de bonnes zones. On définit alors un fichier tableau des bonnes zones :

        0 544952 linear /dev/sda253 2048
        544952 311680 linear /dev/sda253 1208320
        856632 810960 linear /dev/sda253 2519040
        ...
        262530728 817152 linear /dev/sda253 447720320
        263347880 817152 linear /dev/sda253 449911680
        

        enfin on active ce disque virtuel :

        dmsetup create bondisque < fichier_tableau
        il est visible dans /dev/mapper/bondisque . Tout ceci m'aura appris comment LVM fonctionne, et même l'imbrication du RAID logiciel.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Avec le Device Mapper ?

          Posté par  . Évalué à 2.

          Merci pour ton retour, content que ça fonctionne. Par contre, je t'indique que les bricolages de ce genre (j'ai déjà bidouillé des trucs alambiqués avec) sont en général peu pérennes. Mais au moins c'est instructif et amusant.

          • [^] # Re: Avec le Device Mapper ?

            Posté par  . Évalué à 2.

            Le principal problème est une dégradaton du disque. J'ai abusé de badblocks en test de écriture/relecture, tout ça me semble fiable. J'ai un disque de 2010 dans un intel classmate avec seulement 3 zones abimées, et il ne m'a jamais trahi. D'expérience, je sais que quand le nombre de secteurs abimés n'augmente plus on peut expérer que le disque reste fiable.

            Enfin le second problème est de ne pas perdre mon travail en cas de réinstallation du système. J'ai stocké dans 3 partitions différentes des exemplaires des tables afin de limiter ce risque.

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.