Need A CentOS 6 USB Hard Drive Recovery Procedure

Home » CentOS » Need A CentOS 6 USB Hard Drive Recovery Procedure
CentOS 34 Comments

My 15GB backup USB drive somehow got “corrupted” such that a “chkdsk /f E:” on WinXP removed the file allocation table
(or whatever) making the NTFS drive appear empty.

I tried Windows Recuva freeware to recover the files, and it has been working for 24 hours; but it has dumped about
65,000 files into a separate flat Windows directory.

Since none of the files were deleted or written over, is there a method on Linux that will simply recover the missing file allocation directory structure instead of dumping a hundred thousand files into a single directory?

34 thoughts on - Need A CentOS 6 USB Hard Drive Recovery Procedure

  • the FAT contains all the file linkage. if it was overwritten, then there’s no file structure left at all on the disk.

  • How can I tell?

    All I know is the following:
    a) The WinXP PC had a virus or something making it slow b) So I decided to re-install the WinXP OS
    c) I connected the 150GB USB drive to the WinXP PC
    d) I backed up all the data files onto the 150GB USB drive e) I disconnected the 150GB USB drive f) I repartitioned & re-installed Windows XP on the PC
    g) Then I plugged the backup 150GB USB drive back in

    It gave a message that it was unrecognized or corrupted. So I googled, & found a Microsoft Support page saying to run:
    chkdsk /F E:
    So I ran that, and now the USB drive was recognized. But it “appeared” empty.

    So I asked how to recover and people said use “Recuva”. So I installed Recuva 24 hours ago; it’s still running, on the hard disk drive:

    In fact, even though it has said there were only 10 minutes to go for the past 20 hours or so, the file count keeps climbing.

    The problem is that, even though Recuva lists the hierarchy where the files are coming from, it is putting all 70,000
    files in the same directory!

    Given that information, which is really all that I know, what would you recommend for file recovery if I plug the USB drive into my CentOS 6 laptop?

  • Is it already “putting” your files somewhere? If so it’s almost certainly too late to throw a linux recovery tool at it.


  • Never run chkdsk if you are not 100% sure!
    there are good softwares out-there which do better job then recuva. I dont remeber the name of it but you can try to look up and find these softwares.

    I had a linux issue and I bought this kind of software for ext2/3 which saved my life.


  • I’m afraid that’s where you lost it – I’d strongly suspect that the virus has some kind of self-protection to avoid being studied, and that’s when it hit the USB drive.


  • I think that the user was too quick to assume that the computer “had a virus or something”. If he thought it might have a virus, why didn’t he try an anti-virus program first?

    It sounds very much like the user had the reaction many inexperienced users have: “The computer doesn’t do what I think it should be doing: it must be a virus!”

  • I used to have that problem all the time. turns out I was just running windows. then again, maybe the virus diagnosis is right in that case…
    :D :>

  • You may try these out:
    some are able to scan entire surface and able to recover file, some can give you back entire FAT as well, but trial version will be limited with certain files only, or files-only, etc:

    Power Data Recovery. Paragon Hard Disk Manager. EASEUS Data Recovery Wizard. Active Partition Recovery. DataNumen Data Recovery. Spinrite.
    (Sometime, HBD by Hiren is also useful, but usage is allowed only if you really have licensed copy of those software, and care need to be taken from altered, rootkit based releases).

    Most of these are Windows based software.

    – — Bright Star.

    Received from Rock, on 2013-05-09 5:56 PM:

  • Here’s one I used several years ago to recover a drive I had stupidly attempted to format while it contained a couple hundred gigs of data, without which my son would have committed patricide…

    my specific drive was either ext3 or ext4, and I had used mtools to write a DOS filesystem onto it, but hadn’t done anything else. Using this tool I was able to recover what we believe to have been everything important.

    I had the Linux version, and I found it to be somewhat flaky, UI-wise, but with some repeated poking at it I managed to do what I needed. I
    attempted to contact their help desk but they didn’t reply to any of my emails. So, buyer beware.

    They also have a windoze version that I haven’t seen, and it’s **possible**
    that it is less flaky.

    their web page says it can recover lost data from NTFS and FAT filesystems, so it’s possible it would work for you… YMMV.

    It’s non-free, but not terribly expensive. Good luck!

    I’d be interested in hearing if it works for you, should you wish to try it.


  • Nothing, to my knowledge, is being written to the external NTFS
    USB hard drive.

    The files are being put on the C:\ drive of the Windows machine.

    So, I don’t see why the USB drive isn’t in the same shape as it was when this happened.

    Did I do something wrong?

  • Good question. The Windows XP machine is an old Dell B130 which, every year or so with the kids using it, develops a “slowness” that is interminable. The CPU stays at 100% with nothing overtly going on, and just clicking to open a folder takes 20 seconds.

    Every time that happens, I merely back up the data (which all the kids know to put in c:\data) and then I wipe out the machine and rebuild Windows from scratch.

    Populating the data is trivial usually, simply because all data, no matter what it is, goes in C:\data; and then all applications, no matter what they are, go in C:\apps; and all menus, no matter what a program creates, go in a single location (which is the ONLY thing ever stored in a Microsoft-created menu, simply because they’re always polluted):
    C:\Documents and Settings]All Users\Start Menu\Programs\menu

    I have them save all installation programs in c:\apps\installers, so, in the end, backup is trivial because I only back up three things:
    And the menus (which follow the same hierarchy as the apps, by design)

    Note: The apps are *never ever* stored by brand name!
    Apps are stored by function, e.g., c:\apps\archivers c:\apps\browsers c:\apps\cleaners c:\apps\editors c:\apps\games etc.

    And, these functions are well thought out over the many years I’ve been organizing PCs. For example, “misc”, “etc”, “utils”, “system”, etc., lazy catchalls are never allowed. All applications have a definable function, and that’s how they’re stored. Lazy people can’t find stuff on their machines, and lazy people have messy machines.

    Anyway, suffice to say that it’s trivially easy to back up the data on any of our Windows machines, simply because we designed the file system hierarchy from scratch to be easy to rebuild.

    After rebuilding the OS, I simply copy everything back to the same locations (which is consistent across all our Windows machines) and even the menus work when I copy them back.

    Of course, I re-install all the programs; but they’re all saved in the installation directory – so that’s trivial (except for the stupid programs such as iTunes & the CutePDF Writer & the Adobe Acrobat Writer, etc.. These badly written programs are easy to find simply because I store *nothing* in C:\Program Files, so, anything that goes in there, went there despite our entreaties otherwise during the installation process (the kids know the rule to *never* allow a program to do its own thing – always choose
    “custom” and always tell program to go where it belongs). They know to describe it as a “dog pooping” when a program, such as iTune’s Bonjour insists on “pooping” wherever it wants, instead of being well behaved and going where we tell it to go.

    As a side note, we avoid at all costs the use of any directory that has a space in the file name, as special characters make a mess of scripts and UNIX backups. In addition, I delete any directory that has a “My” in front of it, as they get polluted by other programs
    (e.g., My Vides, My Pictures, My Documents, etc.).

    In summary, we only use four directories on Windows:
    C:\apps (this is the program installation directory tree)
    C:\data (this is where all user data goes, with no exceptions!)
    C:\tmp (this is where all temporary downloads go, for example)
    C:\{horrid Microsoft path}\menus (the menus reflect the app hierarchy)

    I must say that I disagree with your assessment of the knee-jerk reaction; but I do still appreciate your help and advice.

    Of course I did run a virus scan (I’m using AVG) and I even added a Trend Micro Housecall scan. Both found minor things such as BHOs and both found heuristic problems with some of the installers, but nothing overt popped up as especially worrying.

    And, I did google for the solution for a corrupt disk and I did follow Microsoft Support instructions.

    Of course, in hindsight, I *should* have run a dd first … but I had not expected the chkdsk to damage anything so I hadn’t gone to the trouble. Lesson learned!

  • Rock wrote:

    Yes. What you should have done was buy or burn (ON ANOTHER MACHINE!!!) a virus checking/cleaning tool, and ->boot from that< -, NOT from your h/d, and let it work. Dunno if you missed my earlier post, but I'd guess that whatever infected your system had a protection mechanism, so that if you tried to backup the whole drive, it would mangle something on the recipient drive, so that *it* couldn't be examined easily. mark

  • I understand.

    What you’re saying was that I shouldn’t have backed up my
    (perhaps compromised) WinXP data onto the external hard disk *from* that very same compromised Windows OS.

    This makes sense.

    In hindsight, I should probably have booted to Knoppix, and then used Knoppix to copy the c:\data hierarchy over to the hard drive.


    Now all I need to do is recover the Master File Table, because this Microsoft KB was what I had followed prior:

  • In hindsight, I should *not* have followed Microsoft instructions. I should have made a ‘dd’ of the hard drive from CentOS. And, I should have booted the Windows machine to Knoppix to make the backup of the C:\data hierarchy from there. f

    Lessons learned…

    Now I’m just trying to figure out how to rebuild the Master File Table of the USB NTFS disk from CentOS 6.

    Any suggestions on how to just rebuild the MFT?

  • Since I may only get one shot, and since I’ve never formatted a USB hard drive, nor ever even mounted one, how does this procedure look for my 149GB NTFS disk?

    Recuva says the cluster size = 4096 & file record size = 1024.

    0. {should I boot off a CentOS CD or should I use my normal OS?}
    1. Connect the new >0GB hard drive to the CentOS 6 laptop Note: Presumably that will be on /dev/sda0 (right?)
    2. Format the new hard drive with fdisk (is this step needed?)
    Note: What fdisk command is recommended?
    3. Connect the old 150GB compromised USB NTFS disk to CentOS 6
    5. Copy data, verbatim, from the old disk to the new disk with dd

    Key questions:
    Q0. Should I boot to my normal CentOS 6 OS?
    Q1: Should I format the new USB hard disk with Fdisk?
    Q2: What dd command should I use?

    Googling, and looking at fdisk options, should I run?
    # fdisk /dev/sdb
    # fdisk -l /dev/sdb

    Googling, I find multiple dd examples {which block size should I use?}
    # dd if=/dev/sda of=/dev/sdb
    # dd if=/dev/sda of=/dev/sdb bs=1M
    # dd if=/dev/sda of=mbrbackup bsQ2 count=1; dd if=mbrbackup of=/dev/sdb bsD6 count=1

  • Having read your earlier posts, I believe you are quite capable of sorting out Q0 and Q1. For Q0 though, I normally use pmagic live CD.
    For Q2, I once ran some tests to determine the optimum blocksize to use with dd and discovered that anything over 4096 didn’t increase throughput much. However, I still use 4M when working with dd to dump a hdd image:
    dd if=/dev/sda of=/path/to/hdd-image-file.img bs=4M

    After dumping the image, refer to testdisk wiki [0] on how to mount the image file. If you require some hand holding working with testdisk, please contact me off-list.

    Cheers, ak.

    [0] –

  • I had to recover a Red Hat Raid array after a motherboard failure…

    This did it:

    During the recovery it rebuilt the previous Windows installation as well. It not free but it worked for me several years ago.

    Hope it helps. There are some linux solutions I had at the time and I
    am trying to dig up my notes.


  • Just for the record, Recuva finished at 66 hours:

    It’s odd that I’m having trouble finding a good tutorial for Linux recovery of the master table of contents, since it must be happening to others day in and day out.

    Fundamentally, the procedure is to “dd” the disk and then work off the backup but I don’t want to make a mistake so that’s why an exact procedure is so critical to find.

    It’s expensive being a pioneer; yet I shouldn’t have to be a pioneer for this task, since it happens every day.

    Will read everything written and try to find a tutorial.

  • ok, here is a quick list of what to do:

    1) connect your spare disk (USB) (not the bad disk!!!!!) and as root check what device id it got (tail /var/log/messages) look for detected partitions there or do fdisk -l /dev/sdx where the sdx is what you found from /var/log/messages

    2) As root Mount the disk:
    mount /devsdxy /mnt
    (where y is the partion number you want to mount)
    if mounted goto 3
    This may fail if it is ntfs

    2B) If it fails format the disk as ext4:
    mkfs /dev/sdxy and then mount it as under 2

    3) I assume here that your bad disk is already connected (as sdz check first what the real name is)

    dd if=/dev/sdz of=/mnt/image.dd bs=1M

    This will copy the contents of your bad disk to image.dd

    4) just to be sure, make the image read-only chmod uog=r /mnt/image.dd

    5) install testdisk from the epel repo yum install testdisk

    6) now run photorec from a directory where you have sufficient space, ifg your usb disk is big enough do it there (hint create a sub-directory mdkdir /mnt/recover cd /mnet/recover

    but any dorectory would do photorec /mnt/image.dd

    The copy to an image is not really required, but better safe then sorry I have written this from Louis

  • I’m not sure how to figure out what to put into that dd command.

    Q: Is this the right sequence given the disk information below?
    1. Boot to CentOS 6
    2. Plug in the old (500GB) & new (2TB) USB drives Note: I’m trying to test this on a test 500GB drive;
    once it works, I’ll use it on the real 150GB drive.
    3. $ sudo parted –list (this finds /dev/sdb & /dev/sdc)
    Note: In this case, sdb is the 500 GB test drive; and
    sdc is the 2TB brand new drive for the dd copy to reside.
    4. su root (do we need to be root?)
    5. # dd if=/dev/sdb of=/dev/sdc/hdd-image-file.img bs=4M

    Q: Is that the right sequence given the disk information below?

    — see below for my attempt finding the logical disk name –

  • Thanks. I needed this step-by-step procedure; and I’ll report back. I bought a new 2TB disk, named “My Passport”. I will test the procedure with a spare 500GB disk, named “Signature Mini”.

    0. $ sudo tail -f /var/log/messages
    1. I plugged in the 2TB new disk.
    ==> May 31 20:52:37 ntfs-3g[4213]: Mounted /dev/sdb1 (Read-Write, label “My Passport”, NTFS 3.1)
    2. $ sudo fdisk -l /dev/sdb
    ==> Disk /dev/sdb: 2000.4 GB, 2000365289472 bytes
    ==> /dev/sdb1 1 243198 1953480704 7 HPFS/NTFS

    3. $ sudo mount /dev/sdb1 /mnt
    ==> Mount is denied because the NTFS volume is already exclusively opened.
    ==> The volume may be already mounted, or another software may use it which
    ==> could be identified for example by the help of the ‘fuser’ command.

    Should I now format the 2TB disk using this command?
    $ sudo mkfs /dev/sdb1
    And then mount it as:
    $ sudo mount /dev/sdb1 /mnt

    At this point, I connect the 500GB test disk and this shows up in the tail of /var/log/messages:
    May 31 21:02:39 ntfs-3g[4787]: Mounted /dev/sdc1 (Read-Write, label “SignatureMini”, NTFS 3.1)

    Is this the correct command given the test information above:
    $ sudo dd if=/dev/sdc of=/mnt/image.dd bs=1M

    I presume I do this after the previous dd command finishes.
    $ sudo chmod uog=r /mnt/image.dd

    $ sudo yum –enablerepo epel install testdisk -y
    ==> Installed: testdisk.x86_64 0:6.12-2.el6
    ==> Dependency Installed: libewf.x86_64 0:20100226-1.el6
    Note: This apparently installs /usr/bin/photorec

    You probably mean “mkdir”, so is this what I run:
    $ sudo mkdir /mnt/recover
    $ cd /mnt/recover

    $ sudo photorec /mnt/image.dd

    Q: Is this the recommended procedure as written after your comments?

  • You could try without reformatting it: just check where it is mounted:
    mount |grep sdb1
    this will show where the disk got mounted.

    Check whee it got mounted mount |grep sdc1
    and umount it to be sure

    this now becomes:
    dd if=/dev/sdc1 of=Correct

    Indeed, I am a lousy typer and even more lousy at proofreading….

    Yes, doing it this way makes sure you do not destroy the content of the old disk as you are working from a copy


  • Thanks for your patience. I backed up the spare 500MB USB disk, so, I’m about to run the procedure on the “bad” 150MB disk as we type.

    Plugging in the spare 500MB disk, I run the suggested command:
    a. Open a wide window & type “sudo tail -f /var/log/messages”
    b. Plug in the spare 500MB USB disk & look for where it mounted:
    ==> Jun 1 07:42:41 rock ntfs-3g[5834]:
    ==> Mounted /dev/sdb1 (Read-Write, label “SignatureMini”, NTFS 3.1)
    ==> Cmdline options: rw,nosuid,nodev,uhelper=udisks,uidP3,gidP3,dmask77
    ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime,
    ==> Global ownership and permissions enforced, configuration type 1
    c. $ mount | grep sdb1
    ==> /dev/sdb1 on /media/SignatureMini type fuseblk (rw,nosuid,nodev,

    It won’t mount because it’s already mounted:
    $ sudo mount /dev/sdb1 /mnt
    ==> Mount is denied because the NTFS volume is already exclusively opened.
    ==> The volume may be already mounted, or another software may use it which
    ==> could be identified for example by the help of the ‘fuser’ command.

    Maybe I should umount it first?
    $ sudo umount /dev/sdb1
    $ mount | grep sdb1
    ==> now reports nothing

    OK. Now I’ll mount it as you kindly suggested:
    $ sudo mount /dev/sdb1 /mnt
    $ mount | grep sdb1
    ==> /dev/sdb1 on /mnt type fuseblk (rw,allow_other,blksize@96)

    Note: The funny thing was that the second time I tried that, it asked for the file system type:
    $ sudo mount /dev/sdb1 /mnt
    ==> mount: you must specify the filesystem type

    So, I specified the filesystem type:
    $ sudo mount -t fuseblk /dev/sdb1 /mnt
    ==> mount: special device /dev/sdb1 does not exist

    Hmmm… I’ll reboot and try again because I tried a few options for specifying the filesystem type and all failed.

    Sending this out … so it’s not lost … and then rebooting and trying again. Thanks for your help. I’ll try to be responsive and detailed so that we can come up with a procedure that not only works for me, but that works for others on CentOS.

  • Hi Louis,

    I’m ready for the big dd!

    OK. Starting over after a reboot, given these two disks:
    A. The 500MB USB disk is the “good” disk B. The 150MB USB disk is the “bad” disk

    I run these commands (documented to help others on CentOS):
    a. Open a wide window & type “sudo tail -f /var/log/messages”
    b. Plug in the good disk & note where it mounted:
    ==> Jun 1 08:26:39 rock kernel: usb 1-1.2:
    ==> new high speed USB device number 5 using ehci_hcd
    ==> Mounted /dev/sdb1 (Read-Write, label “SignatureMini”, NTFS 3.1)
    ==> Cmdline options: rw,nosuid,nodev,uhelper=udisks,uidP3,gidP3,dmask77
    ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime,fsname=/dev/sdb1,blkdev,blksize@96,default_permissions c. $ mount | grep sdb1
    ==> /dev/sdb1 on /media/SignatureMini type fuseblk (rw,nosuid,nodev,allow_other,blksize@96,default_permissions)
    $ sudo mount /dev/sdb1 /mnt
    ==> Mount is denied because the NTFS volume is already exclusively opened.
    ==> The volume may be already mounted, or another software may use it which
    ==> could be identified for example by the help of the ‘fuser’ command.
    $ sudo umount /dev/sdb1
    $ mount | grep sdb1
    ==> reports nothing
    $ sudo mount /dev/sdb1 /mnt
    ==> reports nothing (but no errors either)
    $ mount | grep sdb1
    ==> /dev/sdb1 on /mnt type fuseblk (rw,allow_other,blksize@96)
    Here is where I had to reboot a moment ago … but we can pick up from here now that I’ve repeated the commands without errors.

    OK. Now I connect the bad disk & check /var/log/messages:
    ==> Jun 1 08:34:26 rock kernel: usb 3-2: new high speed USB device number 2 using xhci_hcd
    ==> Mounted /dev/sdc1 (Read-Write, label “SignatureMini”, NTFS 3.1)
    ==> Cmdline options: rw,nosuid,nodev,uhelper=udisks,uidP3,gidP3,dmask77
    ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime,fsname=/dev/sdc1,blkdev,blksize@96,default_permissions

    Doublechecking how the bad disk is mounted:
    $ mount | grep sdc1
    ==> /dev/sdc1 on /media/SignatureMini type fuseblk
    ==> (rw,nosuid,nodev,allow_other,blksize@96,default_permissions)

    OK. I will umount the bad disk:
    $ sudo umount /dev/sdc1

    And, I check that the bad disk is unmounted:
    $ mount | grep sdc1
    ==> reports nothing

    OK. This is where we don’t want to make a mistake!
    Q: Does the block size matter?

    $ dd if=/dev/sdc1 of=/mnt/image.dd

    When that finishes, I’ll run:
    $ sudo chmod uog=r /mnt/image.dd

    And, then the recommended testdisk recovery steps.

    Wish me luck as I’m running the DD as soon as I send this
    (I was confused which block size you recommended, as you initially had 1M and then didn’t have any size).

    NOTE: The detail will be put into a tutorial for CentOS users which will have all the “idealized” steps, in sequence; so your kind efforts not only help me, but many others (we hope).

  • I kicked it off, as follows, and will wait to report:

    $ cd /mnt
    $ script recovery.log
    ==> Script started, file is recovery.log

    Backing up the MBR (as per the Wikipedia on “dd”):
    $ sudo dd if=/dev/sdc1 of=MBR.img bsQ2 count=1
    ==> 1+0 records in
    ==> 1+0 records out
    ==> 512 bytes (512 B) copied, 0.00111047 s, 461 kB/s

    Backing up the MBR+stuff (as per the Wikipedia on “dd”):
    $ sudo dd if=/dev/sdc1 of=MBR_boot.img bsD6 count=1
    ==> 1+0 records in
    ==> 1+0 records out
    ==> 446 bytes (446 B) copied, 0.00122302 s, 365 kB/s

    Now comes the biggie, backing up the entire 150MB disk:
    Q: Maybe I should have used the “conv=noerror” option as suggested in the dd wikipedia entry?

    $ sudo dd if=/dev/sdc1 of=/mnt/image.dd bs=1M

    I’ll report back the results; but hints are good because I will write up a tutorial, based on my experience, and post it for others to follow specifically for CentOS.

  • The dd finished backing up after about 3 hours.

    $ sudo dd if=/dev/sdc1 of=/mnt/image.dd bs=1M
    ==> 152625+1 records in
    ==> 152625+1 records out
    ==> 160039240704 bytes (160 GB) copied, 9750.86 s, 16.4 MB/s

    Although I can’t see to change the permissions of the result:
    $ ls -l
    ==> -rwxrwxrwx. 1 root root 160039240704 Jun 1 12:13 image.dd
    $ sudo chmod uog=r /mnt/image.dd
    $ ls -l
    ==> -rwxrwxrwx. 1 root root 160039240704 Jun 1 12:13 image.dd
    $ sudo chmod 555 ./image.dd
    $ ls -l
    ==> -rwxrwxrwx. 1 root root 160039240704 Jun 1 12:13 image.dd

    At this point, some people said to try to recover using the backup; while others said I should work off the original disk.

    I think I’ll try the testdisk recover procedure first.

  • testdik can work on a disk image, so I recommend using that. Don’t risk chaging the original disk (although testdisk is not supposed to touch it IIRC)

  • Thanks Louis for sticking with me. I do greatly appreciate your help!

    I’m so out of my league; but I’ll try to faithfully report the comings and goings – so that others – who follow in our footsteps – may benefit.

    At the moment, I have the dd image that I’ll use testdisk on; and I have the original disk that I’m using Recuva on (in Windows XP Home, so it’s really OT for this forum).

    Unfortunately, Recuva is giving an error, that one (or more) of the
    400K files has too long of a file spec (sheesh. They could at least tell me *which* filespec it is); so I have to back up the files by keyword searches (without the help of regular expressions); so, overall, I’d say Recuva is a bad way to do things:

    Details here if you’re interested:
    Need to know how to recover table of contents for an external NTFS 150GB disk