| Author |
Message |
   
Danny O'Grady
Username: azurlake
Registered: N/A
| | Posted on Monday, Mar 23, 2009 - 11:00: | |
Hello, this is my first post here. I'm having some trouble with a NAS system, it's an old Comet Labs Network Disk, and the RAID is made under Linux using the raidtool.conf. I succesfully assembled the RAID with the correct stripe size and parity rotation. Since it's a software RAID, what I did is to select the drives in the RAID and set the offset to 542304, which the sector in which the partition starts (this information I think it's in the MBR, but there's no recognizable partition info in that sector in any disk... in fact, it's all set to 00 until sector 542304 + 16384, and at that point, everything you can see is "ÿ" or similar rubbish. Real information begins thousands of sectors further, but there's no trace of the file system. Using the Data Recovery option from the "Tools > Disk Tools > File header signature search" and the "Refine Volume Snapshot > Particularly thorough file system data structure search & File header signature search" I've been able to recover hundreds of files in less than a minute, but in the specific case of JPG's they all seem to be corrupt. I can open them with the Windows Image Viewer, but ALL OF THEM have got like some missing pixel blocks in the upper-right corner, sometimes it's just a little line in the corner, sometimes a whole line from the right corner to the left one. The larger the image, the narrower the line. In a 700 kB image, I could say that 99,5% of the image is OK, some people could not notice the line if I don't tell them about it... the images are also recovered with their original names. What's wrong with my files? |
   
Danny O'Grady
Username: azurlake
Registered: N/A
| | Posted on Monday, Mar 23, 2009 - 11:05: | |
which is* |
   
Alfons Kramer
Username: admin3
Registered: 4-2004
| | Posted on Monday, Mar 23, 2009 - 11:40: | |
If the file system involved is EXT2 or EXT3 you cannot expect that file carving will be successful for files bigger than 12 blocks in size. One has to omit the 13th block in order to get correct results. You could remove every 13th block from every corrupt file. But a better idea is to recognize an EXT-filesystem and let WinHex do the "block logic" during carving. To get this done, you need to locate a superblock for that EXT-filesystem. Either use the disk tool "search for lost partitions" or find the superblock by searching for "53 EF" at offset 56. Probably the partitioning system is LVM, which is not supported by WinHex right now. |
   
Danny O'Grady
Username: azurlake
Registered: N/A
| | Posted on Monday, Mar 23, 2009 - 12:50: | |
Thank you for replying. I've just been reading about that. The "search for lost partitions" doesn't find anything. It could be an LVM partition... I was trying to make WinHex to recover data omitting the 13th block (question: block = sector?) by selecting the "Ext2/Ext3 block logic" option, but I can't see that option anywhere... it's supposed to be in the "file header signature search" data recovery window, or within the "Refine Volume Snapshot" window (as it is written in the manual), but I just can't see it... |
   
Danny O'Grady
Username: azurlake
Registered: N/A
| | Posted on Monday, Mar 23, 2009 - 13:14: | |
One more thing, I've found a sector at offset 262048 beggining with "00 40 E8 02 A0 69 D0 05 00 00...." with "53 EF 00 00 01 00 00 00 A9 A7 FA 46 00 ..." beggining at offset 56 in that sector. Could that be an Ext partition? From offset 120 to EOS it's all set to 00, and the 4 or 5 following sectors are set to 00 too. Thank you. |
   
Danny O'Grady
Username: azurlake
Registered: N/A
| | Posted on Wednesday, Mar 25, 2009 - 10:43: | |
Yep, it's a superblock. The partition starts two sectors before it. WinHex recognizes an Ext2 partition when I tell it to interpret that sector as a partition start, and I can open the directory browser... but all I get is "directory in iNode xxxxxxxxxxx" and "file in inode yyyyyyyyyyy". The files have no extension... I tried to recover files using the refine volume snapshot and the data recovery tool with the "use ext2/3 block logic" option, but the files I recovered were corrupt as before. When I create the virtual partition, the error message display shows "a problem ocurred while trying to read sector 391.xxx.xxx from disk X. Incorrect Function." (I don't need to scan or anything for this to happen), and "Traces of a 372 GB partition found. Size not plausible. Will not be added to partition list. " and "The virtual system area file will be incomplete". What's going wrong? When I click on any file from a "files in iNode xxxxxxxx", WinHex moves to the beggining of the file... but it doesn't seem to be a file beggining; moving sectors backwards I can see data from the same file. Thanks |
   
Alfons Kramer
Username: admin3
Registered: 4-2004
| | Posted on Friday, Mar 27, 2009 - 9:30: | |
The RAID5 reconstruction went wrong, leaving you with a damaged file system. Please reconstruct your RAID5 again. |
|