Data Recovery and Disk Utilities Forum @R-TT

Professional data recovery is out of options?

Thanks for the advice, but I have given up on recovery of the data and will re-format the drives.
/Micke

Alt wrote:

mwitt wrote: I recovered a couple of JPEGs yesterday (most of them are so corrupt they can not be viewed), the ones that were view-able were quite interesting. They contained all data, but were "scrambled" so that different blocks of the picture were placed in the wrong "order".
/Micke

That indicates that either:
1. The virtual RAID parameters are incorrect: wrong disk/block order. That gives you hope to recover files yourself.
2. Data was re-distributed when you added the failed disk. Possibly, files still can be recovered, but by a data recovery professional.
Can you post a couple of those JPEGs?

The raid5 is based on HW raid (LSI 8708ELP). It was originally a six x 2 GB array, but after a disk failure the array was degraded. I switched out the faulty disk for a new one and added it to the array. The array was doing back-ground initiation/rebuild, but after 10 minutes kicked out the new drive as well and remained in degraded state, so I started to recover data to other disks. During the file copy another disk dropped out of the array and the logical disk dropped from the operating system (all file copy halted with error "disk not available" or some such message). I rebooted the system and during boot the raid controller showed up reporting only 3 disks (should at least have been four) and that a "foreign configuration" was detected with the option of "importing" it. I went along with the import, but rebooted the system as soon as windows was loaded.

On the second reboot, 5 disk were detected by the raid bios and a "foreign configuration" was found which I imported. After the operating system was booted, I activated the failed 5:th disk in the raid storage application and the raid 5 returned to "degraded" from "failed", as I completed this, I noticed that the array had initiated a "patrol read" on the four disks that had not "failed", something that the raid does on its own accord when disk access is low. There was no way of aborting the "patrol read", so I had to let it finish which took about 1 hour.

However, the drive was not recognized by the operating system as a partition and the disk manager reported the disk as "non-initialized" and asked if I wanted to initialize as GTP or MBR. I did not initialize the drive and started investigating and trying to find a way to recover the data.

That is how I ended up buying your software and doing all sorts of analysis on the logical drive, GTP partition, boot rocord, MFT etc. using TestDisk, PartitionGuru and R-studio.

I have contact with LSI support, but they seem clueless and have only made an RMA for the raidcard (which I suspect is in some way faulty?!). I have a new raidcard here, but according to LSI I should not switch out the raidcard as long as the raid is degraded, so I do not dare to switch cards at this time (don´t really see any reason to do it at this stage).

I have not at any time during this switched the order of disks in the array, they have connected to the same SATA-to-SAS connections the whole time, except for the RMA:d disk.

I do suspect that something happened during the second disk failure, the strange results during the reboots ,the re-activation of the "failed" disk or the "patrol read" that in some way "scrambled" the data on the physical disks in the array.

I would love to post some screenshots of the pictures I recovered, but as I pointed out earlier, your forum does not accept uploads of files....! I get this message when trying to upload the GIF:s: "Could not upload attachment to ./files/3703_1fe7a4a0a0b4ad9ad42d8b5644224cc6."

Any other way to get the files to you?

Best regards
/Micke

mwitt wrote: I recovered a couple of JPEGs yesterday (most of them are so corrupt they can not be viewed), the ones that were view-able were quite interesting. They contained all data, but were "scrambled" so that different blocks of the picture were placed in the wrong "order".
/Micke

That indicates that either:
1. The virtual RAID parameters are incorrect: wrong disk/block order. That gives you hope to recover files yourself.
2. Data was re-distributed when you added the failed disk. Possibly, files still can be recovered, but by a data recovery professional.
Can you post a couple of those JPEGs?

Alt wrote:A lot of error messages means that the file system is severely damaged, that's why your recovered files are corrupt.

Do you mean that the file system is damaged (MFT) or that the actual files (data) are damaged? R-studio obviously recognized the directories as well as the directory structure itself, something that I guess it gets from the MFT, but the data recovered is corrupt. I recovered a couple of JPEGs yesterday (most of them are so corrupt they can not be viewed), the ones that were view-able were quite interesting. They contained all data, but were "scrambled" so that different blocks of the picture were placed in the wrong "order".

My non-qualified guess is that data has been moved around and possibly over-written by the ROC Raid card, so that the MFT is in part corrupt and the "file pointers" that remain point to files that sometimes are in the correct sector, but sometimes are no longer present. I would think that the headers of the files are sometimes readable, and in some cases the whole file, but the order of the data is moved around by some raid function? Doing analysis of the boot sector tells me that boot sector is ok (both primary and back-up), but the MFT is reported as corrupt, both primary and back-up.

Is it over...should I give up?
/Micke

A lot of error messages means that the file system is severely damaged, that's why your recovered files are corrupt.

The deep scan is now complete and it has detected an enormous amount of "partition" of all types, FAT32, FAT16, FAT12, EXT+ and NTFS. Its about 2-300 items listed. Most of them are very small.

The only one that has a label that I know I have created is listed a "Recognized1", has the Label "Data1", NTFS file system and starts at 0 bytes. It is however listed as Size "24.59 EB", a bit larger than it should be:-).

Opening this partition, the process of opening starts and lists that it will take 3-4 hours to complete, and huge amounts of error messages are written to the log! Example of errors:

Warning File 2012-04-03 11:55:39 [FileId: 4152385524409] Claimed attribute size 0x70080 was shrunk to 0x60
Error File System 2012-04-03 11:55:39 [FileId: 68403] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 68403] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 68449] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 68449] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 25874] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 26778] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 23598] MFT record child's claimed parent mismatch, aborting
Warning File System 2012-04-03 11:55:39 [FileId: 4152385524586] Fixup 2 is 0x0, but should be 0xb
Warning File System 2012-04-03 11:55:39 [FileId: 4152385524706] Fixup 2 is 0x0, but should be 0xa
Warning File System 2012-04-03 11:55:39 [FileId: 4152385524733] Fixup 2 is 0x0, but should be 0x10
Warning File System 2012-04-03 11:55:39 [FileId: 4152385524988] Fixup 2 is 0x0, but should be 0x7
Warning File System 2012-04-03 11:55:39 [FileId: 4152385525035] Fixup 2 is 0x0, but should be 0x8
Error File System 2012-04-03 11:55:39 [FileId: 68770] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 68770] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 68834] MFT record child's claimed parent mismatch, aborting
Warning File System 2012-04-03 11:55:39 [FileId: 4152385525229] Fixup 2 is 0x0, but should be 0xa
Warning File System 2012-04-03 11:55:39 [FileId: 4152385525330] Fixup 2 is 0x0, but should be 0xd
Warning File System 2012-04-03 11:55:39 [FileId: 4152385525438] Fixup 2 is 0x0, but should be 0xd
Warning File System 2012-04-03 11:55:39 [FileId: 4152385525661] Fixup 2 is 0x0, but should be 0xb
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526042] Fixup 2 is 0x0, but should be 0x17
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526198] Fixup 2 is 0x0, but should be 0x8
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526217] Fixup 2 is 0x0, but should be 0x7
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526233] Fixup 2 is 0x0, but should be 0x1b
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526300] Fixup 2 is 0x0, but should be 0xf
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526314] Fixup 2 is 0x0, but should be 0x10
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526348] Fixup 2 is 0x0, but should be 0x25
Error File System 2012-04-03 11:55:39 [FileId: 69392] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 70174] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 70194] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 70199] MFT record child's claimed parent mismatch, aborting
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526438] Fixup 2 is 0x0, but should be 0xf
Warning File System 2012-04-03 11:55:39 [FileId: 4152385526443] Fixup 2 is 0x0, but should be 0x5
Error File System 2012-04-03 11:55:39 [FileId: 69442] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 71513] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 71513] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 71513] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 71513] MFT record child's claimed parent mismatch, aborting
Error File System 2012-04-03 11:55:39 [FileId: 71513] MFT record child's claimed parent mismatch, aborting
Warning File System 2012-04-03 11:55:40 [FileId: 4152385526657] Fixup 2 is 0x0, but should be 0xa
Warning File System 2012-04-03 11:55:40 [FileId: 4152385526882] Fixup 2 is 0x0, but should be 0x5
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527215] Fixup 2 is 0x0, but should be 0x9
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527368] Fixup 2 is 0x0, but should be 0x11
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527393] Fixup 2 is 0x0, but should be 0x4
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527503] Fixup 2 is 0x0, but should be 0x1a
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527635] Fixup 2 is 0x0, but should be 0x5
Warning File 2012-04-03 11:55:40 [FileId: 4152385527711] Claimed attribute size 0x108 was shrunk to 0x68
Warning File 2012-04-03 11:55:40 [FileId: 4152385527715] Claimed attribute size 0x110 was shrunk to 0xd8
Warning File 2012-04-03 11:55:40 [FileId: 4152385527717] Claimed attribute size 0xc8 was shrunk to 0x68
Warning File 2012-04-03 11:55:40 [FileId: 4152385527718] Claimed attribute size 0xc8 was shrunk to 0x68
Warning File 2012-04-03 11:55:40 [FileId: 4152385527721] Claimed attribute size 0x1a8 was shrunk to 0x180
Warning File 2012-04-03 11:55:40 [FileId: 4152385527724] Claimed attribute size 0x108 was shrunk to 0xe0
Warning File 2012-04-03 11:55:40 [FileId: 4152385527725] Claimed attribute size 0x190 was shrunk to 0x98
Warning File 2012-04-03 11:55:40 [FileId: 4152385527726] Claimed attribute size 0x1a0 was shrunk to 0xf0
Warning File 2012-04-03 11:55:40 [FileId: 4152385527728] Claimed attribute size 0x190 was shrunk to 0x120
Warning File System 2012-04-03 11:55:40 [FileId: 4152385527761] Fixup 2 is 0x0, but should be 0xe
Warning File 2012-04-03 11:55:40 [FileId: 4152385527792] Claimed attribute size 0x1b0 was shrunk to 0x110
Warning File 2012-04-03 11:55:40 [FileId: 4152385527796] Claimed attribute size 0x100 was shrunk

I stop the process after aprox 1 minute and it lists a lot of directories, some created on the volume by me, some old directories that has been present on the disks before they were quick formated and added to the raid array. Opening one of the directories created on the partition, it list files that i recognize and it look ok.

Recovering files works without any errors, but the recovered files are corrupt and can not be used. I have tried recovering 8-10 different video files (thats what I need to recover) of type .mkv and .avi but they are all corrupt and non-playable. This is files that I have verified many times before as working (before the problems started).

How should I proceed?

Best regards
/Micke

mwitt wrote:
Is it possible to move the data to a mounted network drive directly from within R-studio?
R-studio have detected the file structure, so I guess you can make the move on a folder level and get all files included?

1. Yes.
2. You may read our on-line help on how to recover files and folders: Basic File Recovery.

Alt wrote:1. No. You have to copy all recovered files to some other place.
2. Looks like the best course of action for you will be to repair the RAID and then copy the files back to it.
Yes, all that requires a lot of time and extra storage space, but this is the safest way to recover data, and data safety is our utmost priority.

Thanks for your fast reply. I will try to copy the data to other drives as soon as the deep scan is done (about 26 hours left ).
Is it possible to move the data to a mounted network drive directly from within R-studio?
R-studio have detected the file structure, so I guess you can make the move on a folder level and get all files included?

Best regards
/Micke

1. No. You have to copy all recovered files to some other place.
2. Looks like the best course of action for you will be to repair the RAID and then copy the files back to it.
Yes, all that requires a lot of time and extra storage space, but this is the safest way to recover data, and data safety is our utmost priority.