So I have this external 2.5" drive salvaged from an old laptop of mine. I was trying to use it to backup/store data but the transfer to the drive fails repeatedly at the ~290GB mark leading me to believe that maybe there is a bad sector on the drive. I tried to inspect the drive using smartmontools and smartctl but since it is an external drive, i was not allowed to do so. Is there anyway for me to inspect and fix this drive? I am on fedora ublue-main. The HDD is a 1TB seagate drive.

Edit : I am a linux noob so some hand holding will be appreciated. Also i am looking to use this drive only for low priority media files which i dont mind losing so please help even though it is not the greatest idea to use a failing drive

Edit 2 : It seems my post is not clear of what i am doing. I dont want to recover data from the drive. I want to try to use more of the drive for storing data

  • _thebrain_@sh.itjust.works
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    8 months ago

    You should be able to use smartctl on a USB drive. I’ve never had an issue anyway. You may need to specify the transport type tho. I had a drive that it couldn’t figure out on its own, but since it was an sata drive in an external enclosure, atapi is the transport protocol to use

    sudo smartctl -a -d ata /dev/<devid>

    Using the same switch you can run a long test. It’s sort of a pain as it will kill the test on finding a bad sector. But you can take that sector number and plug it into hdparm to rewrite the sector hoping it will remap it. You won’t be able to recover the data in a bad sector, But There are these extra sectors on the drive that firmware can replace the bad one with. It does this on a forced write command.Something along the lines of

    hdparm --repair-sector --yes-i-know-what-i-am-doing </dev/<driveid> <sector number from smartctl>

    Again, you have data loss, you can’t go back to no loss. All you can do is rescue anything important. You may (probably) need to run a long smartctl test again, and fix another sector. I have saved data off of drives with 100+ bad sectors this way… It’s tedious and eventually I scripted it but it does work.

    • fuckwit_mcbumcrumble@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      Older/shittier enclosures don’t support smart pass through. But this is an issue that’s largely been fixed for 10+ years at this point so I’m surprised op has this.

      • Sentau@discuss.tchncs.deOP
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        8 months ago

        The funny thing is that the cheaper throwaway enclosure i bought supports smart pass through but the newer sata 3 capable connector does not. I am as surprised as you that this turned out to be the issue

    • Sentau@discuss.tchncs.deOP
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      thanks for the help but i am unfortunately getting a Read Device Identity failed: scsi error unsupported field in scsi command error for that particular drive. A different external drive also in an enclosure returns the appropriate information. I used the smartctl --scan command to find out the device types in both cases (both are sat)

      • _thebrain_@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        8 months ago

        Can you plug the drive in directly and test it? You might also just have a dead drive. Either way if you were planning on using it as a backup medium I would tell you it’s probably not a good idea. If you are trying to recover data from it, good luck. Is it making any sound? You could try buying the same, old but good hard drive and swapping the control board on it. You may also have to swap the nvram chip on it to make sure you have the same sector mappings. Either way there is a lot of stuff you can try, but hopefully this is an educational experience for you (as in learning how to recover a dead drive, not as in learning about the need for proper backup methods) as opposed to a desperate attempt to recover data that is most likely unrecoverable.