Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
April 5th, 2011, 13:27
I've been checking out the hex data for a RAID and I'm having trouble making sense of it. I was able to find that the stripe size is 64 K, but there is some definite weirdness with it. There were 8 drives present in this RAID array. Drives 0-6 have data on them but drive 7 is mostly gibberish (probably parity). The client thought that this was a RAID 5, but it seems like there is a dedicated parity drive to make it RAID 4. That would be fine, but it looks like I'm missing about 1/8 of the data. In looking at the beginning and end MFT records in each 64 K block, I was not able to find a stripe pattern, and there are some weird jumps in record numbers that I can not account for. I enclosed a table of what I found. Worth noting: this was not a bootable array I don't think. The server had a separate bootable laptop drive that contained the OS. I also could not find the initial data record in the MFT (The one containing $ M F T, record 00 00). The hex in the Excel document is the MFT record number at the start of the data block, and at the end of the data block. I did this for the first half meg of each drive. If you could, please check out the table and let me know what you think.
Thanks!
Steve
- Attachments
-
raid hex.xls
- (13.5 KiB) Downloaded 430 times
April 5th, 2011, 13:33
Do you know (or can you find out from the user) which type of RAID controller was in use for this array? That info may help the readers here...
April 5th, 2011, 14:17
It is a 3Ware controller. I don't have a specific model number, though.
Also it is worth noting that in R-studio, if I set it up as a Virtual RAID 5, with 64 K stripe and Right Asynchronous order, I can view much of the file structuresee the drive label. I am looking for black and white TIFs. Most of them will open but of those that do, many have a black and white broad stripe of garbled info somewhere in them.
April 5th, 2011, 15:03
Forget about Raid4 , 3ware don't know this rare type.
Your drive №7 probably just spare drive, try rebuild array without it.
Show us partition sector (0) to understand total size.
BTW Which size of each drive?
April 5th, 2011, 15:15
Thanks for the tip about RAID 4 not being used on 3Ware. That helped me avoid going down the wrong path. Since there does not seem to be any parity data on the remaining 7 drives, could that indicate a RAID 0 with hot swap? That would be wacky.
These are 400 GB drives.
April 5th, 2011, 15:43
Okay...here is my guess:
Drives 0-3 are in RAID 5
Forward Parity
16KB block size
Drives 4-6 are in RAID, are stand alone drives or may be in a separate RAID configuration with drive 7, depending on what drive 7 is showing. If you could add the actual drive 7 data to the table, I might be able to give a more accurate guess.
April 5th, 2011, 15:46
Scratch that. Turning off drive 7 (the hot swap) in the R-Studio virtual RAID 5 seemed to mostly solve it. I just opened several 6 MB TIFF files.
Thanks for the assist DR-Kiev.
I see all the files that the client is looking for, and all open properly now. Only remaining curiosity is that the folders that the TIFFs are in show up as only "?".
Still, way better now, if not done.
April 5th, 2011, 15:55
DOH! I hate it when I'm wrong. Are you choosing the 8 drive array, without drive 7? That, too, could be a viable option, seeing that we really don't have the sectors from the 8th drive to reference. Oh well, it sounds like you have it...great job.
April 5th, 2011, 16:07
BytesBack wrote: Only remaining curiosity is that the folders that the TIFFs are in show up as only "?".
.
Probably unknown Fonts for R-studio, long names or something else.
Which version is using?
April 5th, 2011, 17:14
BytesBack wrote:
I see all the files that the client is looking for, and all open properly now. Only remaining curiosity is that the folders that the TIFFs are in show up as only "?".
R-Studio uses system fonts, so they all known to it. Can those be names with non-Latin characters?
April 5th, 2011, 18:02
LCoughey,
Don't worry about it. I presented things in a confusing manner. The hex data I was giving in the Excel sheet was the file record from the 3rd line of the MFT for the first and last record from each 64 K chunk. I was implying that the MFT was present in all of those spots, but I didn't actually say so I don't think. I didn't include any hex from drive 7 because there was no MFT file record, hence, no hex to include. I believe you thought I was giving you the first few hex characters from those sectors. By pure coincidence, I think, the XOR formula worked on the first 4 drives. Anyway, don't feel bad.
I unchecked the last drive (7) in R-Studio and that got everything reading perfectly. Every document I open, even over 10 MB, is correct. The only remaining issue is the ? folders, Not that big a deal.
DR-Kiev,
I am using R-Studio 4.6. I don't believe there to be special character issues, but it is possible. There are 6 folders containing all the TIFFs and all open normally. What's strange is they are all listed with ? as the folder name, and those 6 ? folders do not appear in the root directory. Rather they appear on the same level as Root and metadata. Very strange (to me).
Steve
April 5th, 2011, 18:03
Alt,
Should not be non-latin characters I don't think. This machine is in an English speaking only environment.
Steve
April 6th, 2011, 2:55
BytesBack wrote:I am using R-Studio 4.6.
Steve
Update it, 5.3 version already present.
April 6th, 2011, 4:31
[quote="BytesBack"There are 6 folders containing all the TIFFs and all open normally. What's strange is they are all listed with ? as the folder name, and those 6 ? folders do not appear in the root directory. Rather they appear on the same level as Root and metadata. Very strange (to me).
Steve[/quote]
That means that R-Studio was unable to find names and parent folders for those folders and therefore couldn't find a place for them in the overall folder tree. Sometimes that happened. R-Studio 5.3 processes such folder tree much better.
Powered by phpBB © phpBB Group.