Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

When a SMART check on a disk reports a bad sector, it is important to be able to identify the file that has the bad sector - and restore it from backups. Below, I show how I did this for my Linux/ext3 VMWARE server - but does anyone know if this can be done for Windows/NTFS?

Here's how I did it for Linux/ext3: I first asked the drive to do a hardware surface scan (below the OS level, with the on-drive SMART circuits):

vserver:~# smartctl -t long /dev/sdc

I looked at the results:

vserver:~# smartctl -a /dev/sdc
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       9
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     27679         591363172

So, one sector was already marked bad, 9 were marked for replacing from the "staging" sector space. More importantly, the first logical block address (LBA) that is unreadable, was 591363172.

I found the partition (and the offset inside it) that this number "translated" to:

vserver:~# fdisk -lu /dev/sdc
Device Boot      Start         End      Blocks   Id  System
/dev/sdc1           32   976773119   488386544   83  Linux

The partition started at sector 32. So, the bad sector was...

vserver:~# bc -l
591363141 an offset of 591363141 sectors from the beginning of the partition.

Now I could find which file was "hosed":

vserver:~# tune2fs -l /dev/sdc1 | grep Block\ size
Block size:               4096

The block size of this EXT3 filesystem was 4096 bytes, so the bad sector destroyed this block in the filesystem:

vserver:~# bc -l

And the block number (73920392) corresponded into this file:

vserver:~# debugfs
debugfs 1.41.3 (12-Oct-2008)
debugfs:  open /dev/sdc1
testb 73920392
debugfs:  testb 73920392
Block 73920392 marked in use
debugfs:  icheck 73920392
Block           Inode number
73920392        18472967
debugfs:  ncheck 18472967
Inode           Pathname
18472967        /path/to/filewithbadsector

And I restored that file from my backups.

Is there an equivalent procedure I can follow for Windows/NTFS?

share|improve this question
FYI: the current pending count of 9 means that there are 9 bad sectors, not just one. The extended self test just stops at the first one it finds. Before you restore from backup, you also want to deal with the bad sector by writing zeros to it with dd. This will force the drive to either repair or reallocate it. – psusi Sep 14 '11 at 13:29
Yep, you are right. After the restore, I did another SMART check and found that all was OK - so the writing of the file apparently wrote over the 9+1 bad sectors (and the staging area provided substitutes). But what about Windows? :-) – ttsiodras Sep 14 '11 at 14:56
I think your calculation for the sector offset in a partition is incorrect. Sector numbers (other that physical, a.k.a. CHS) are all zero based, as sector 32 is partition sector 32-32==0, not 1. – user149657 Dec 14 '12 at 14:38
Shockingly nobody has said this yet on a year+ old question: When you start seeing bad sectors on the drive it means you've got so many the drive's automatic internal bad-block remapping can't compensate anymore. Rather than restoring from backups to a dying drive you should replace the drive and restore to the new drive. – voretaq7 Dec 14 '12 at 16:06

1 Answer 1

up vote 7 down vote accepted

I know you have an NTFS FS, and run windows on that FS. I don't know if you "could" boot a live Linux to work on that driver or not.

If you can boot Linux from CD or USB, you can use ntfsprogs. look at -



I believe ntfscluster tell you what file a particular cluster stores. I hope this puts you in the right direction.

share|improve this answer
I found this forum post which has a utility wrapper to do this over different filesystems, and uses ntfscluster too. – Lethargy Jul 5 '12 at 20:54
Yes, ddrutility feature: Finds the files related to bad sectors, Can also use a file with a sector list, maybe we could use "badblocks -nvs" + "ddrutility" – diyism Jul 19 '13 at 7:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.