So, I've got a USB hard drive, which automounts and is used for hourly-daily-weekly-monthly full-disk snapshots via snapshot.

It seems to have failed. I am leery of attempting to reformat entirely if recovery is possible since that would lose me all the old backups.


OS is Linux Mint 18.1. The drive is a WD MyPassport. The only reason for using a USB drive for this is that I already had it - I don't tend to unplug it.

I recently changed what power strips things were plugged into, which is the only recent event that might have caused power loss - the computer was off when I did that, though. I had some trouble booting after that, searching seemed to indicate a problem solvable by shorting the CLR CMOS pins on my motherboard to reset the BIOS. So apparently there might have been power issues, somehow. After that, I continued to have trouble booting past the emergency-recovery terminal until I removed the backup drive from my fstab.

Attempts to diagnose

(all commands with sudo)

fdisk -l /dev/sdb produces fdisk: cannot open /dev/sdb: Input/output error

blkid /dev/sdb outputs nothing.

fsck /dev/sdb outputs

fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?

ls /dev lists sdb

Attempting to mount it by UUID produces mount: can't find UUID=83dbb817-b194-4c83-bb3f-9b67163e1c5c

Attempting to boot the computer without commenting the drive out of my fstab results in the green-dots boot splash lasting a very long time, eventually turning orange and producing various error messages. The only one I transcribed started off with blk_update_request: critical medium error.

When I shut down before it finished turning off, I got the following terminal screen:

Linux Mint 18.1 Serena dt tty 1
dt login: [ 5840.759433] blk_update_request: critical medium error, dev sdb, sector 0
[ 5840.759523] Buffer I/O error on dev sdb, logical block 0, async page read

Those two error messages repeated (slowly, a significant delay between each) several times with increasing timestamps until the machine eventually powered off. The gap before the second time the message showed was approx. 17 seconds. Didn't get a picture any further on, but it went for maybe half a dozen more repeats. Those were roughly the errors seen on attempted boot, as well.

I've just noticed that the little light on the drive keeps flashing, and the drive keeps whirring softly when the computer is turned off. I am unable to recall whether this was the case when it was working properly.

Tried smartctl:

~ $ sudo smartctl -i -A /dev/sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.8.0-56-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Model Family:     Western Digital Elements / My Passport (USB, AF)
Device Model:     WDC WD20NMVW-11AV3S4
Serial Number:    WD-WX11E23AAA87
LU WWN Device Id: 5 0014ee 2b36180eb
Firmware Version: 01.01A01
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 3.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Jun 21 22:50:33 2017 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       207
  3 Spin_Up_Time            0x0027   222   216   021    Pre-fail  Always       -       3900
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1664
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   185   185   000    Old_age   Always       -       248
  9 Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       4855
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       182
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       56
193 Load_Cycle_Count        0x0032   199   199   000    Old_age   Always       -       5196
194 Temperature_Celsius     0x0022   126   105   000    Old_age   Always       -       26
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

dmesg pastebin: here

  • Look at dmesg for relevant error messages. Try to get SMART data with smartctl -i -A /dev/sda as root.
    – dirkt
    Commented Jun 21, 2017 at 5:02
  • dmesg has a very large amount of stuff and I can't discern the errors from the nonerrors. The two lines that showed on rebooting also show repeatedly there, though.
    – Vivian
    Commented Jun 22, 2017 at 2:40
  • you never check the drive with fsck, it is partition you shall check fsck /dev/sdb1 and so on Commented Jun 22, 2017 at 3:20
  • The SMART values look good, and because you can get these, it means communication with the drive works, which is also good. Please do dmesg > some_file and put it in a pastebin or similar, edit your question with the link. Don't attempt to do anything with fsck yet, the reads are failing for some reason, and using fsck will make it worse.
    – dirkt
    Commented Jun 22, 2017 at 6:11
  • @dirkt dmesg pastebin is in
    – Vivian
    Commented Jun 23, 2017 at 2:29

1 Answer 1


Partial answer: Here are the log messages when it tries to access the disk for the first time:

[   19.614242] sd 6:0:0:0: [sdb] 3906963456 512-byte logical blocks: (2.00 TB/1.82 TiB)
[   19.614484] sd 6:0:0:0: [sdb] Write Protect is off
[   19.614485] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[   19.614724] sd 6:0:0:0: [sdb] No Caching mode page found
[   19.614734] sd 6:0:0:0: [sdb] Assuming drive cache: write through

These are the normal messages for drive initialization. But 10 seconds later (probably the timeout span):

[   38.037295] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   38.037297] sd 6:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current]
[   38.037298] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error
[   38.037299] sd 6:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[   38.037300] blk_update_request: critical medium error, dev sdb, sector 0

So right from the beginning, the first read fails, and that read seems to be for the partition table. That means in the best case you have a bad block where the partition table is. Do you remember anything about the partition table? If it's one partition for the whole disk, recovery should be easy.

In the worst case, it can't read anything, so the first step is to run badblocks /dev/sdb and see how many read errors you get.

If it's only the partition table, the safe option (if the data is really valuable) is to get a second harddisk, use dd_rescue, ddrescue or whatever to try to read every single block, see where the read errors are (only partition table, or more?), make a new partition on the copy of the damaged harddisk, and see what you can recover.

The a little bit more unsafe option is to just make a new partition with fdisk, sfdisk (MBR) or sgdisk (GPT), depending on how you made the partition table and if you remember it. The reallocated sector count is zero, so it should have spare sectors to replace the damaged ones. Don't make new filesystem(s) in the partition(s), this will destroy your old data. Mount the partition read-only, and see what you can get.

I wouldn't use this drive to backup your data in the future, though.

  • So your judgement is that it's something wrong on the physical drive, not just data corruption? May be possible to get something back but the drive should be considered unreliable even in stable circumstances (no unusual power-loss)?
    – Vivian
    Commented Jun 23, 2017 at 12:15
  • 1
    I don't know. "Medium error" could be lots of things. Trying to read other blocks, with badblocks or otherwise, is the quickest way to find out. If you can't read any blocks, then there's definitely something wrong physically. Personally, I'm uncomfortable with using any drive that has had hickups as a backup drive - the next time it fails, it will be exactly when you need the data because your main drive failed, and then the data will be gone, forever. But the drive may work fine for years in another role.
    – dirkt
    Commented Jun 23, 2017 at 14:16
  • Well, I ran out of disk space trying to tee the output of badblocks, so I think I can safely say the disk is unusable.
    – Vivian
    Commented Jun 24, 2017 at 21:01
  • I know it was a single partition with btrfs filesystem. I think I made it with a GUI tool, can't remember which, it's been a while. Recovery plausible?
    – Vivian
    Commented Jun 24, 2017 at 21:09
  • It would have been helpful to see the first part of the badblocks output - if every block is unreadable (contigous list of numbers), there's indeed something physically wrong (loose connection, something out of alignment). Recovery impossible.
    – dirkt
    Commented Jun 25, 2017 at 7:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .