Jump to content

lost partition and filesystem problem with Adata SH14 disk


Recommended Posts

Good day chaps,

The situation:

I an having trouble wtih a company owned ADATA SH14 (1Tb space). We gave the disk to another company to write data to it, but when they gave it back to us the drive was showing as RAW. They lost the USB3 cable and tried to use a Micro USB cable instead and claimed that the drive was functioning properly on some of their computers. As of this moment I have extracted most of the data from the drive using iCare Recovery Software but unfortunately the names of some of the files and the directory structure is gone which makes most of the data unuseable. I read of lot of forum threads but I was not able to find one that describes my problem.

I tried to use TestDisk to repair the drive and here is what happend:

1. The first analizing tool does not find a partition at all.

2. The deep search finds a partition but when i try to browse the files it says that the filesystem might be corrupted and does not show even 1 file.

3. On the next menu it says:

Boot sector:

fat32_boot_sector: Can't read boot sector

Bad

Backup boot sector
Ok

4. I tried to use the "Backup BS" but it reports that it can not overwrite the FAT23 boot sector.

5. I tried the "Rebuild BS" and after waiting for nearly a day it found a directory with some files but when prompted to write the data it failed with the exact same error.

Drive shows as:

FAT32 LBA 0 1 1 121600 254 63 1953520002

I would really appreciate any suggestions you can give me! :)

Kind Regards,

Mihail Velikov

System Administrator

Link to comment
Share on other sites


But was the drive actually originally formatted as FAT32 (it would be extremely rare that a 1 Tb drive is formatted with the FAT32 filesystem in a single partition :ph34r:)?

There is no problem in rebuilding a FAT32 bootsector :), but the issues here are (IF the drive was actually FAT32) the FAT tables.
VERY loosely speaking, any file which is:

  1. NOT fragmented
  2. NOT residing in the root directory

should be recoverable alright from a FAT32 filesystem. (IF the issues are limited to the FAT tables)

Are you working/modifying the original :w00t: or using an image (or anyway have already an image safely stowed away)?

Which OS are you running/using to attempt accessing it?

Have you considered that the issue may be - even partially - connected with the actual USB to SATA controller inside the disk case?

Do you have the possibility to open the case and connect directly the disk to a SATA bus?

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

I really do not believe that the disk was FAT formatted. Unfortunately as I am not the one that initialized the disk so I can't be 100% sure.

I am currently working the original and not using an image. I have already extracted the data and this is last ditch attempt to save the drive. The other step will be reformatting it.

Initially I was using Windows 7 with the iCare software to recover the files. Currently the disk is attached to another systems running partedmagic boot cd.

Regarding the SATA controller - no I haven't thought about that. The disk is sealed in a rubber thingie but i could still try to open it. I will try this right now.

Update: Ok, i opened the case and extracted the disk. I have now connected it to the computer and I will see how it is going to behave. Should I run testdisk again to analyze the drive?

Kind Regards,

Mihail Velikov
System Administrator

Edited by nthnl
Link to comment
Share on other sites

In this particular case I would run on it - instead of TESTDISK - the DMDE.

(Testdisk is mainly intended for "corrupted partition" recovery and has only some very limited features when it comes to filesystem recovery).

Still, if you run again TESTDISK with the LOG option and post the log, it may contain something of use to give you some further advice.

DMDE is a very nice (IMHO) tool that has a Free Edition with not-so-limited features, that I often use to inspect damaged filesystems:

http://dmde.com/

In any case the "correct" procedure would be to first thing do a "forensic sound" image of the disk "as is".

No offence whatever intended :), but while "pure file-based recovery" (such as PhotoRec or similar) offers no risks to the integrity of the filesystem, running TESTDISK or similar software and attempting to WRITE :ph34r: to the target may make things worse that they were before.

I am not familiar with the software you mentioned, actually never heard of it before :w00t:, so, even if it is an exceptional good tool :unsure:, I would anyway go for a second (or third) opinion both as "filesystem based" recovery and as "pure file-based recovery" through the use of other tools.

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

Thank you very much for your advice.

I do not believe that the software I used made any changes to the disk - although I might be wrong. About TestDisk - yes, I tried to write to the disk but it failed so I am not sure if it actually wrote anything to start with.

I will try the DMDE tool and see how it goes. If I can make a better backup of the drive it would be great.

Update: I am running DMDE and it gives a log of errors looking like that (only the Sectors are different, also note that the drive is directly connected to the sata port on the motherboard):

LUN#0 Sector 63(try 2): WinError 23. Data error (cyclic redundancy check).

Update 2: DMDE reports this is a FAT32 File System and is currently testing FAT tables - still gives a lot of error like the one above.

Kind Regards,

Mihail Velikov

System Administrator

Edited by nthnl
Link to comment
Share on other sites

Those kind of errors are not "good news" :(.

They appear to be "low-level" errors :ph34r: (i.e. either the disk controller or the SATA cable or - more probably - the disk itself have hardware issues).

(BTW they could be also originated by the Windows 7 OS, but it would be "queer")

Now, much more than before, it is imperative that you:

  1. stop fiddling with that disk drive. like NOW (sometimes a defective disk only needs to cool down a bit)
  2. procure yourself another disk slightly bigger with a partition/volume formatted as either NTFS or Ext2/3/4 to make on it an image of the disk
  3. get *any* Linux distro with Gnu ddrescue and use it to make the image

https://help.ubuntu.com/community/DataRecovery#Imaging_a_damaged_device.2C_filesystem_or_drive

BTW, there is a similar software for Windows:

http://www.datarescue.com/photorescue/v3/drdd.htm

but the GNU ddrescue offers some added functionalities (it will skip defective sectors, logging what was skipped and you can re-run it and will automatically try to re-read the skipped ones), you can do more or less the same with datarescuedd, but you need to image in chunks (manually) and re-assemble chunks, see:

http://reboot.pro/topic/15040-data-recovery-off-clicking-disk/

http://reboot.pro/topic/15040-data-recovery-off-clicking-disk/?p=133567

The first error being on sector #63 makes a lot of sense as - IF the disk was originally partitioned using the old CHS convention - sector LBA 63 is actually the bootsector of the partition (i.e. the thing that TESTDISK had issues writing to).

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

Ok, I will order another drive, because I don't have one that big on my disposal right now.

The check of the FAT tables just completed and here are the results:

FAT table size in bytes: 122065408

radio box 1: FAT1: 4096-122065408: 100% OK; 30%OK, 0 % bad, 69% empty, 0% unknown

radio box2: FAT2: 4096-122064896: 99% OK; 29% OK, 0% bad, 70% empty, 0% unknown

radio box3: do not use FAT tables

check box: check (do not use bad sectors)

Any idea which one should I choose or should I just end task the application then make the image of the drive?

Kind Regards,

Mihail Velikov

System Administrator

Link to comment
Share on other sites

These results are not that bad:

The check of the FAT tables just completed and here are the results:

FAT table size in bytes: 122065408

radio box 1: FAT1: 4096-122065408: 100% OK; 30%OK, 0 % bad, 69% empty, 0% unknown

radio box2: FAT2: 4096-122064896: 99% OK; 29% OK, 0% bad, 70% empty, 0% unknown

radio box3: do not use FAT tables

BUT they are not "normal".

I mean it seems like the two copies of the FAT are overlapping.

Any idea which one should I choose or should I just end task the application then make the image of the drive?

If you choose the "do not use FAT tables" the filesystem will be read as "RAW" and as such only files that are contiguous and in any subdirectory may be recovered (BUT, IF the FAT tables - even if "OK" - do contain invalid or incomplete data, this option may allow to recover MORE files than when using the supposedly "100% OK FAT table", on the other hand, it is well possible that the second FAT table, though not "100% OK" may contain "different" - possibly "more valid" data.

The "standard" procedure when you know WHAT you are actually looking for is to try checking the files/directory tree once for each option and then choose the one that shows the needed file(s).

If you don't know what you are looking for, the procedure is to run the whole recovery process three times, and then compare results.

The real issue here is that - depending on the reason that caused the sector level errors - it is possible that each read operation/movement of the head on that disk makes things worse, and - besides - working on an even partially defective disk will slow down operations to a level that is almost unbearable.

That's another reason for making the image, it may take a lot of time to create (hopefully) a valid image, but the imaging tool can be run "unattended" at night, and once you have the image on a "good" disk, the interactive part of the recovery (analyzing/searching/copying/etc.) will be faster.

I would no doubt have the image made next thing. (better be safe than sorry ;))

Can you post the EXACT model of the actual disk drive?

I want to check it's actual sector size and number of sectors as something - instinctively, but I have do make some calculations - doesn't "sound" right to me about the FAT size found.

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

Indeed you are correct - > better safe than sorry. Reading the disk is extremely slow so I will do an image when the new drive arrives and see if I can extract any useful data from it.

Regarding the actual drive it is:

Samsung

Model: HN-M101MBB (1Tb/5400rpm/8M)

LBA 1,953525,168 1TB

REV. A

S/N: S2R8J9BB901504

P/N: C7612-G14A-A47PT

As soon as I have any news I will update the thread.

Kind Regards,

Mihail Velikov

System Administrator

Link to comment
Share on other sites

Good. :)

The disk is seemingly one of those with the "newish" 4096 bytes per sector "advanced" format:

http://www.storagereview.com/samsung_spinpoint_m8_review

but as a mattter of fact it seems like it "exposes itself" as a conventional 512 byte/sector device.

As such the offset of 4096 bytes for the start of the FAT1 seems like "possible or probable".

Quite surely the good guys at ADATA have created the FAT32 filesystem with a "cusstom" app (the "standard" Windows format won't deal with such a large disk or will create a "huge" cluster size, but in any case it would create a higher number of "reserved sectors").

I didn't think it was a 2.5" drive, and yes, I have seen how those are often formatted as FAT32 even if very large, in factory, so that the "common" user can use them on Windows, OSX and Linux "as is".

As well, the size of the found FAT seems like "right", 122065408/4=30516352 (roughly) indexable clusters, and if you divide 1953520002 (total sectors - these are 512 bytes ones) by 30516352 you get roughly 64 which makes sense for a 32 Kb cluster FAT filesystem.

It is possible (but I doubt it) that the "custom" format had only one FAT table, but in any case the FAT1 that the tool found - according to the data posted - sounds like "the right one". :thumbup:

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

I run the ddrescue on my disk and here is the output.

root@partedmagic:/dev# ddrescue -r 3 -n -v --force /dev/sdb /dev/sda recovery.log


GNU ddrescue 1.17
About to copy 1000 GBytes from /dev/sdb to /dev/sda
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued: 1000 GB, errsize: 1372 kB, current rate: 0 B/s
ipos: 180815 MB, errors: 21, average rate: 31125 kB/s
opos: 180815 MB, time since last successful read: 20 m
Finished

I will now try to see if the data is structured better than before from the healthy drive.

Kind Regards,

Mihail Velikov

System Administrator

Link to comment
Share on other sites

I will now try to see if the data is structured better than before from the healthy drive.

Yep.

If the DMDE found FAT table has not errors, as it seemed, now that you have the data on a surely working device, you can try also re-running TESTDISK, if it now can write to the bootsector, most probably it can fix the filesystem enough to acess the data "normally".

But can you post the actual recovery log?

BY checking the location of the chunks that errored out it is possible to see if they beloong to filesystem data or to the actual data, as this makes a big difference (between being unable to access some 16,000 entries or being unable to access - or get corrupted - 1 or two files)

In any case usually the idea is to re-run the tool a couple more times with the "-C" option to see if it can recover the "errored" areas, possibly by using a smaller block size:

`-c sectors'

`--cluster-size=sectors'

Number of sectors to copy at a time. Defaults to 64 KiB / sector_size. Try smaller values for slow drives. The number of sectors per track (18 or 9) is a good value for floppies.

and/or using the "reverse" approach:

`-R'

`--reverse'

Reverse direction of copying, retrying, and the sequential part of splitting, running them backwards from the end of the input file.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Hello Jacklaz,

I run the DMDE tool on the new drive aaaaand gues what -> again I see the errors that the previous disk gave me. I do not belive this is a disk issue as it is brand new. I am currently doing a full scan on the hard drive with DMDE for file and director fragmest and it is currently on 85% (started it around 8 hours ago).

Regarding the recovery.log - unfortunately I didn't save it. I was runing the parted magic boot cd which operates in the RAM and I didn't attach a working disk to copy it to (my bad ..).

I will see how the DMDE will do - before doing the full check it was actually giving me nearly the same folder structure as the software I initially used to recover files. If it still fails I will go ahead and run testdisk and try to repair the drive.

All in all I am quite happy to learn a lot of new things about HDD recovery - god know when I will need it again :)

Kind Regars,

Mihail Velikov

Link to comment
Share on other sites

Anyway, should you not be able to recover the data this way, we can still try assuming that your previous DMDE scan for FAT was accurate and recreate a new bootsector with the relevant BPB data on it.

You can also use DMDE (or any disk editor) to look manually in the disk to check for the FAT start.

Typically it is a few sectors after the bootsector (8 according to your previous DMDE scan) and basically it is the first sector that starts with the F8 FF FF 0F FF FF sequence.

The previous scan of DMDE says that the FAT size is 122065408, the "sectors before" from your initial posts are 63 and the partition size is (still from there) 1953520002 sectors.

The only thing that is not clear or "queer" is the number of FAT's, from the DMDE scan you reported it may be that there is only one table (and DMDE assumes that a part of the FAT1 is actually the FAT2) but this is "uncommon" as normally there are two copies of the FAT table.

If you want, you can dd the first 100 sectors of the disk, compress them in a .zip file and either attach them to your post or upload to any file hosting service and post the link.

From Linux, that would be:

dd if=/dev/sdb of=100sects.bin bs=512 count=100

(of course the command must be run from RW mounted filesystem or anyway the of= file must be on such a filesystem, i.e. include a path to it)

It would be easy if the data is confirmed to prepare a couple bootsectors, one with just one FAT and the other with two FATs.

jaclaz

Link to comment
Share on other sites

Hello Jacklaz,

I left the drive last night to complete the full indexing of the directories but unfortunately the computer applied updates and rebooted. FML right? I am not really in the mood to wait for it for a whole another day so I used the FAT1 and FAT2 tables that it got but unforutnately it found only around 950 Mb of useful data. I guess the full indexing will be required anyway.

Anyway I will run the full indexing process again and I hope it will complete properly this time. After it finishes I will extract the bootsectors and upload it here.

Kind Regards,

Mihail Velikov

System Administrator

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...