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. http://www3.picturepush.com/photo/a/12892041/img/12892041.jpg
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?
On 5/9/2013 1:41 PM, Rock wrote:
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?
the FAT contains all the file linkage. if it was overwritten, then there's no file structure left at all on the disk.
John R Pierce wrote:
On 5/9/2013 1:41 PM, Rock wrote:
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?
the FAT contains all the file linkage. if it was overwritten, then there's no file structure left at all on the disk.
Are you sure that the FAT was mangled, and not just the MBR?
mark
On Thu, 09 May 2013 16:51:48 -0400, m.roth-x6lchVBUigD1P9xLtpHBDw wrote:
Are you sure that the FAT was mangled, and not just the MBR?
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: http://www1.picturepush.com/photo/a/12893214/img/12893214.jpg
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. http://www1.picturepush.com/photo/a/12893269/img/12893269.jpeg
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?
On Thursday 09 May 2013, Rock Rocksockdoc@gmail.com wrote:
d) I backed up all the data files onto the 150GB USB drive
How did you back up?
e) I disconnected the 150GB USB drive
Did you "safely remove" the USB drive as shown here? http://etc.usf.edu/techease/win/hardware/how-do-i-safely-remove-a-usb- device-from-my-computer/
But this is really a Windows question, and I think you're out of luck.
On 2013-05-10, Rock Rocksockdoc@gmail.com wrote:
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. http://www1.picturepush.com/photo/a/12893269/img/12893269.jpeg
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!
Is it already "putting" your files somewhere? If so it's almost certainly too late to throw a linux recovery tool at it.
--keith
On Thu, 09 May 2013 18:53:30 -0700, Keith Keller wrote:
Is it already "putting" your files somewhere? If so it's almost certainly too late to throw a linux recovery tool at 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?
Rock wrote:
On Thu, 09 May 2013 18:53:30 -0700, Keith Keller wrote:
Is it already "putting" your files somewhere? If so it's almost certainly too late to throw a linux recovery tool at 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?
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
On Fri, 10 May 2013 13:04:01 -0400, m.roth-x6lchVBUigD1P9xLtpHBDw wrote:
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.
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.
Sigh.
Now all I need to do is recover the Master File Table, because this Microsoft KB was what I had followed prior: http://support.microsoft.com/kb/176646
On 5/10/2013 3:56 AM, Rock wrote:
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.
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.
Eliezer
On 05/09/13 20:56, Rock wrote:
On Thu, 09 May 2013 16:51:48 -0400, m.roth-x6lchVBUigD1P9xLtpHBDw wrote:
Are you sure that the FAT was mangled, and not just the MBR?
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
<snip> 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.
mark
On Friday 10 May 2013, mark m.roth@5-cent.us wrote:
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!"
http://www.brzitwa.de/mb/gpart/ might help..
2013/5/10 Yves Bellefeuille yan@storm.ca
On Friday 10 May 2013, mark m.roth@5-cent.us wrote:
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!"
-- Yves Bellefeuille yan@storm.ca Mekaro en Otavo, Kanado, 18-20 majo 2013: http://mekaro.ca/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, May 10, 2013 at 8:32 AM, Yves Bellefeuille yan@storm.ca wrote:
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 :>
-- Even the Magic 8 ball has an opinion on email clients: Outlook not so good.
On Fri, 10 May 2013 08:32:35 -0400, Yves Bellefeuille wrote:
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?
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.
http://www5.picturepush.com/photo/a/12897688/img/12897688.jpeg
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: C:\apps* C:\data* 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)
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 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. http://support.microsoft.com/kb/176646
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!
On Fri, 10 May 2013 17:27:34 +0000, Rock wrote:
And, I did google for the solution for a corrupt disk and I did follow Microsoft Support instructions. http://support.microsoft.com/kb/176646
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!
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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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:
On Thu, 09 May 2013 16:51:48 -0400, m.roth-x6lchVBUigD1P9xLtpHBDw wrote:
Are you sure that the FAT was mangled, and not just the MBR?
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: http://www1.picturepush.com/photo/a/12893214/img/12893214.jpg
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. http://www1.picturepush.com/photo/a/12893269/img/12893269.jpeg
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?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, May 10, 2013 at 07:03:18AM -0700, Bry8 Star wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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.
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...
http://www.recoverdatatools.com/
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.
http://www.recoverdatatools.com/windows-data-recovery.html
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.
Fred
For the record, this is the Microsoft Support KB I had followed: http://support.microsoft.com/kb/176646
Just by way of update, it's currently at 95,000 of about 100,000 files; so I would expect the Recuva file recovery to complete by tomorrow morning (day 3):
http://www5.picturepush.com/photo/a/12901188/img/129088.gif
Of course, the results will be flatter than a pancake; so, I will try the other suggested methods; but at least I'll wait for this first (Recuva) method to complete.
On 11/05/13 14:48, Rock wrote:
For the record, this is the Microsoft Support KB I had followed: http://support.microsoft.com/kb/176646
Just by way of update, it's currently at 95,000 of about 100,000 files; so I would expect the Recuva file recovery to complete by tomorrow morning (day 3):
http://www5.picturepush.com/photo/a/12901188/img/129088.gif
Of course, the results will be flatter than a pancake; so, I will try the other suggested methods; but at least I'll wait for this first (Recuva) method to complete.
Give testdisk [0] a try. However, I'd suggest you still make a copy of the disk with dd and work on the image!
[0] - http://www.cgsecurity.org/wiki/TestDisk
Cheers, ak.
On Sat, 11 May 2013 21:27:59 +1000, Anthony K wrote:
I'd suggest you still make a copy of the disk with dd and work on the image!
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?
Note: 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 >=150GB 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 bs=512 count=1; dd if=mbrbackup of=/dev/sdb bs=446 count=1
On 11/05/13 22:56, Rock wrote:
On Sat, 11 May 2013 21:27:59 +1000, Anthony K wrote:
I'd suggest you still make a copy of the disk with dd and work on the image!
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?
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] - http://www.cgsecurity.org/wiki/TestDisk_FAQ#How_to_open_the_image.dd_file_.3...
On Sat, 11 May 2013 23:31:07 +1000, Anthony K wrote:
dd if=/dev/sda of=/path/to/hdd-image-file.img bs=4M
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 ---
Pluggin in the new 2TB drive and a test 500MB drive, they both show up in /media; but that doesn't tell me what their sda path is.
Since the dd command requires the two paths to the two drives, how do I find out that information?
Googling, I find this reference: http://unix.stackexchange.com/questions/4561/how-do-i-find-out-what-hard-dis...
I tried the suggested commands, as shown below:
1. The disklabel command wasn't found: $ disklabel ==> bash: disklabel: command not found $ sudo yum install disklabel ==> No package disklabel available. ==> Error: Nothing to do
2. Neither was the lshw command: $ lshw -class disk ==> bash: lshw: command not found $ sudo yum install lshw ==> No package lshw available. ==> Error: Nothing to do
3. The by-label directory simply gave the disk name: $ ls /dev/disk/by-label ==> My\x20Passport SignatureMini
4. And the by-id gave a cryptic set of numbers: $ ls /dev/disk/by-id ==> usb-Hitachi_HTS545050KTA300_008061300001-0:0 ==> usb-Hitachi_HTS545050KTA300_008061300001-0:0-part1 ==> usb-WD_My_Passport_0748_575833314142323938373338-0:0 ==> usb-WD_My_Passport_0748_575833314142323938373338-0:0-part1
5. Likewise with by-uuid, only the numbers were even worse: $ ls /dev/disk/by-uuid ==> horrid set of numerical results
6. It doesn't seem that the by-path is at all useful: $ ls /dev/disk/by-path ==> pci-0000:0f:00.0-usb-0:1:1.0-scsi-0:0:0:0 ==> pci-0000:0f:00.0-usb-0:1:1.0-scsi-0:0:0:0-part1 ==> pci-0000:0f:00.0-usb-0:2:1.0-scsi-0:0:0:0 ==> pci-0000:0f:00.0-usb-0:2:1.0-scsi-0:0:0:0-part1
7. And, the hwinfo command wasn't found: $ hwinfo --disk ==> bash: hwinfo: command not found $ sudo yum install hwinfo ==> No package hwinfo available. ==> Error: Nothing to do
8. Maybe the scsi directory contained what I needed? $ cat /proc/scsi/scsi Host: scsi8 Channel: 00 Id: 00 Lun: 00 Vendor: WD Model: My Passport 0748 Rev: 1019 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi8 Channel: 00 Id: 00 Lun: 01 Vendor: WD Model: SES Device Rev: 1019 Type: Enclosure ANSI SCSI revision: 06
9. Finally, I think "parted" found logical device /dev/{sdb,sdc}: $ sudo parted --list Model: WD My Passport 0748 (scsi) Disk /dev/sdc: 2000GB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 1049kB 2000GB 2000GB primary ntfs
Model: Hitachi HTS545050KTA300 (scsi) Disk /dev/sdb: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 32.3kB 500GB 500GB primary ntfs
10. Yet, fdisk found /dev/sdb1 & /dev/sdc1: $ sudo fdisk -l Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xdf7bffc7
Device Boot Start End Blocks Id System /dev/sdb1 1 60801 488384001 7 HPFS/NTFS
Disk /dev/sdc: 2000.4 GB, 2000365289472 bytes 255 heads, 63 sectors/track, 243197 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0005f107
Device Boot Start End Blocks Id System /dev/sdc1 1 243198 1953480704 7 HPFS/NTFS
On 05/09/2013 04:41 PM, Rock wrote:
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. http://www3.picturepush.com/photo/a/12892041/img/12892041.jpg
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?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I had to recover a Red Hat Raid array after a motherboard failure...
This did it: http://www.recoverdatatools.com/
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.
Fred
On Sat, 11 May 2013 11:23:35 -0400, Fred Roller wrote:
There are some linux solutions I had at the time and I am trying to dig up my notes.
Thanks if you can find them.
Currently I'm at day 3, and almost done recovering the files; but the results (sadly, due to my error in the Recuva settings) are flatter than the plains of Kansas!
http://www2.picturepush.com/photo/a/12904140/img/12904140.gif
On Sat, 11 May 2013 15:35:31 +0000, Rock wrote:
Currently I'm at day 3, and almost done recovering the files; but the results (sadly, due to my error in the Recuva settings) are flatter than the plains of Kansas!
Just for the record, Recuva finished at 66 hours: http://www5.picturepush.com/photo/a/12907423/img/12907423.jpeg
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.
On Sat, 2013-05-11 at 19:18 +0000, Rock wrote:
On Sat, 11 May 2013 15:35:31 +0000, Rock wrote:
Currently I'm at day 3, and almost done recovering the files; but the results (sadly, due to my error in the Recuva settings) are flatter than the plains of Kansas!
Just for the record, Recuva finished at 66 hours: http://www5.picturepush.com/photo/a/12907423/img/12907423.jpeg
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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
On Sat, 11 May 2013 22:28:53 +0200, Louis Lagendijk wrote:
here is a quick list of what to do:
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".
- 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
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
- As root Mount the disk:
mount /devsdxy /mnt (where y is the partion number you want to mount)
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.
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
Should I now format the 2TB disk using this command? $ sudo mkfs /dev/sdb1 And then mount it as: $ sudo mount /dev/sdb1 /mnt
- I assume here that your bad disk is already connected (as sdz check
first what the real name is)
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)
dd if=/dev/sdz of=/mnt/image.dd bs=1M This will copy the contents of your bad disk to image.dd
Is this the correct command given the test information above: $ sudo dd if=/dev/sdc of=/mnt/image.dd bs=1M
- just to be sure, make the image read-only
chmod uog=r /mnt/image.dd
I presume I do this after the previous dd command finishes. $ sudo chmod uog=r /mnt/image.dd
- install testdisk from the epel repo
yum install testdisk
$ 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
- 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
You probably mean "mkdir", so is this what I run: $ sudo mkdir /mnt/recover $ cd /mnt/recover
but any dorectory would do photorec /mnt/image.dd
$ sudo photorec /mnt/image.dd
Q: Is this the recommended procedure as written after your comments?
On Sat, 2013-06-01 at 04:18 +0000, Rock wrote:
On Sat, 11 May 2013 22:28:53 +0200, Louis Lagendijk wrote:
here is a quick list of what to do:
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".
- 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
- $ sudo tail -f /var/log/messages
- 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
- As root Mount the disk:
mount /devsdxy /mnt (where y is the partion number you want to mount)
- $ 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.
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
Should I now format the 2TB disk using this command? $ sudo mkfs /dev/sdb1
You could try without reformatting it: just check where it is mounted: mount |grep sdb1 this will show where the disk got mounted.
And then mount it as: $ sudo mount /dev/sdb1 /mnt
- I assume here that your bad disk is already connected (as sdz check
first what the real name is)
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)
Check whee it got mounted mount |grep sdc1 and umount it to be sure
dd if=/dev/sdz of=/mnt/image.dd bs=1M This will copy the contents of your bad disk to image.dd
this now becomes: dd if=/dev/sdc1 of=<path to the mount point for the new disk/image.dd
Is this the correct command given the test information above: $ sudo dd if=/dev/sdc of=/mnt/image.dd bs=1M
- just to be sure, make the image read-only
chmod uog=r /mnt/image.dd
I presume I do this after the previous dd command finishes. $ sudo chmod uog=r /mnt/image.dd
Correct
- install testdisk from the epel repo
yum install testdisk
$ 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
- 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
You probably mean "mkdir", so is this what I run: $ sudo mkdir /mnt/recover $ cd /mnt/recover
Indeed, I am a lousy typer and even more lousy at proofreading....
but any dorectory would do photorec /mnt/image.dd
$ sudo photorec /mnt/image.dd
Q: Is this the recommended procedure as written after your comments?
Yes, doing it this way makes sure you do not destroy the content of the old disk as you are working from a copy
Louis
On Sat, 01 Jun 2013 12:25:01 +0200, Louis Lagendijk wrote:
Should I now format the 2TB disk using this command? $ sudo mkfs /dev/sdb1
You could try without reformatting it: just check where it is mounted: mount |grep sdb1
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,uid=503,gid=503,dmask=0077 ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime, fsname=/dev/sdb1,blkdev,blksize=4096,default_permissions ==> Global ownership and permissions enforced, configuration type 1 c. $ mount | grep sdb1 ==> /dev/sdb1 on /media/SignatureMini type fuseblk (rw,nosuid,nodev, allow_other,blksize=4096,default_permissions)
And then mount it as: $ sudo mount /dev/sdb1 /mnt
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=4096)
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.
On Sat, 01 Jun 2013 12:25:01 +0200, Louis Lagendijk wrote:
Should I now format the 2TB disk using this command? $ sudo mkfs /dev/sdb1
You could try without reformatting it: just check where it is mounted: mount |grep sdb1
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,uid=503,gid=503,dmask=0077 ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime,fsname=/dev/sdb1,blkdev,blksize=4096,default_permissions c. $ mount | grep sdb1 ==> /dev/sdb1 on /media/SignatureMini type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,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=4096) 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.
- I assume here that your bad disk is already connected (as sdz check
first what the real name is)
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,uid=503,gid=503,dmask=0077 ==> Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,atime,fsname=/dev/sdc1,blkdev,blksize=4096,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=4096,default_permissions)
mount |grep sdc1 and umount it to be sure
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
dd if=/dev/sdz of=/mnt/image.dd bs=1M This will copy the contents of your bad disk to image.dd
this now becomes: dd if=/dev/sdc1 of=<path to the mount point for the new disk/image.dd
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).
On Sat, 01 Jun 2013 16:00:06 +0000, Rock wrote:
OK. This is where we don't want to make a mistake! Q: Does the block size matter?
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 bs=512 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 bs=446 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.
On Sat, 01 Jun 2013 16:40:46 +0000, Rock wrote:
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
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.
On Sat, 2013-06-01 at 19:52 +0000, Rock wrote:
On Sat, 01 Jun 2013 16:40:46 +0000, Rock wrote:
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
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) /Louis
On Mon, 03 Jun 2013 16:41:29 +0200, Louis Lagendijk wrote:
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) /Louis
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: http://forum.piriform.com/index.php?showtopic=38776 Need to know how to recover table of contents for an external NTFS 150GB disk
-
Anthony K -
Bry8 Star -
Eero Volotinen -
Eliezer Croitoru -
Fred Roller -
Fred Smith -
John R Pierce -
Keith Keller -
Louis Lagendijk -
m.roth＠5-cent.us -
mark
-
Rock -
Yves Bellefeuille -
zGreenfelder