Reconstructing RAID

[cmyk1605]

Hi,

I have one case:

F-7223:
Proraid Smart Family NAS HFR2-SU3S2 - 4 disks Running RAID1+0.
Client accidentally formatted the array using Windows Disk Management tool.

Methods we have tried are:
1) Rebuilding the RAID using UFS using auto-mode (no data retrieved)
2) Manually arranging the disk order for RAID0(MFT damaged, files corrupt; hex inspection shows repeating patterns or FF FF FF FF)
3) Attempted to manually align 2 disk RAID0, unable to find alignment point

Is this something that I must use RAID edition for? I do not have RAID edition PC3k.

[DataMedics]

Never trust that a customer has any idea how their RAID was configured. They never know accurately. I'd estimate that 90% of the RAID cases I see they thought was a different RAID type. They say it's RAID 5, but it turns out to be RAID 0, or they say it's RAID 10 but it's really RAID 6, etc.

Have you verified everything yourself? For example, if it's RAID 10 as you say then there should be two sets of drives that perfectly match each other from beginning to end. Also, you'll need to figure out if any drives have been offline for a significant amount of time. I've seen quite a few where a drive had been offline for a year or more.

[Nick_TS]

Hello,

Source of the post 2) Manually arranging the disk order for RAID0(MFT damaged, files corrupt; hex inspection shows repeating patterns or FF FF FF FF)

Did you try to arrange the order using the virtual file system on MFT records like here http://blog.acelaboratory.com/pc-3000-d ... ition.html ?

[osity]

What would change if the drive had been offline for a year or more?

[DataMedics]

Source of the post What would change if the drive had been offline for a year or more?

Common sense should make that obvious to you. If a drive has been offline for a year, then every file that has been created, modified, moved, copied, pasted, etc. will not be the correct data where it is supposed to be. It'll be completely out of sync with the other drives and you'll be getting a ton of corrupt files because it's reading old data from a year ago.

[osity]

I have no common sense

What if the customer doesn't know when the second drive failed?
And if its 'out of sync' in a data recovery scenario, is it still recoverable or will it all be a corrupted mess ?

[AJ2008]

You should have 2 x pairs of disks for 10 - check in winhex under compare mode.

Check MBR or partition for volume size - this will help determine the actual configuration

for NAS it is not going to be NTFS so will not have MFT records - maybe you referenced MFT records from inside some VM which will likely not run consistent and will not be a good basis for analysis.

If some member is stale then it can be removed - before this you need to confirm the RAID level and config.

What is starting sector for largest partition on each disk? How many disks have superblock at this position (or some sectors after it) and what FS is present?

You first need to know its configuration so check this first via partition sizes reported, number of identical disks (or relatively identical taking into account a year old stale disk)

Most NAS units will use some MDADM/LVM config that UFS can support in auto mode- maybe you version is too old to support some FS this array may be using, maybe you build with stale disk included?

[DataMedics]

Source of the post What if the customer doesn't know when the second drive failed?

I would never expect the customer would know when/if a drive had failed. It's up to you to figure out what disk(s) were offline and rebuild using only disks that were online when it finally failed completely.

[AJ2008]

Source of the post And if its 'out of sync' in a data recovery scenario, is it still recoverable or will it all be a corrupted mess ?

Because a RAID array will often have some redundancy to account for disk failures, should a disk become defective or unreliable the array will simply ignore it and compensate for it via mirrored pairs or some parity data written on other members. As the array will continue to operate and data will remain accessible, it make sense that changes will happen to the data - new files created or changed, erased, file records will change to accommodate changes etc - should you now try to access the array with the removed disk re-inserted to the system then data will be compromised as there will be many conflicting records and copies of the data and mixing the real and valid data with the 'stale' data from the disk that was exempt - this will result in corrupt data. Any data that is likely OK is data that was never modified or accessed and usually such data is not accessed because is not so important to the client anyway. Easy way to find stale disk is to build many times and compare results with disks omitted, but sometimes this alone is not enough but you also need to know the RAID parameters correctly otherwise all results will be bad.

[osity]

in most of these types of scenarios, does it make sense fully clone all (8) drives ( including the 2 that failed 1st in my case) before attempting to rebuild the array using software?

[digitalsupport]

If you have 6 perfectly working drives I would not clone them but reconstruct RAID set leaving out the 2 failed drives. (if possible)
Then add the 2 failing drives to setup and image needed data only from them, to stress weak drives minimal.

[lcoughey]

Source of the post If you have 6 perfectly working drives I would not clone them but reconstruct RAID set leaving out the 2 failed drives. (if possible)
Then add the 2 failing drives to setup and image needed data only from them, to stress weak drives minimal.

How do you know that the 6 drives are perfectly healthy without cloning them? Others may disagree, but I'm from the camp that every drive should be cloned every time. Cutting corners and taking unnecessary risks with client's data is what computer techs and low end data recovery shops do.

[AJ2008]

It is possible to have cases that seem apparently healthy with no obvious issues that will soon die despite signs and assumptions they are good. I understand in some situations cloning may not be needed, but it is always the better option

[DataMedics]

Source of the post f you have 6 perfectly working drives I would not clone them but reconstruct RAID set leaving out the 2 failed drives. (if possible)
Then add the 2 failing drives to setup and image needed data only from them, to stress weak drives minimal.

This is a bad idea. There is a reason the RAID went offline and can't be accessed normally. Maybe it's just a few bad sectors, but the fact that two drives failed already means that the others could be on the fritz too. The professional thing to do is always to clone first. If the cloning goes fine, then it's probably safe to work from the originals if you'd like. The last 8 drive RAID I worked on had 4 drives that had failed. Two were just bad sectors and the other two had corrupted media caches. Had I not cloned first, the two with just bad sectors would have hung at some point and the whole recovery could have been botched if they catastrophically failed. Don't trust redundancy, you may have out of sync drives and the loss of one more due to haste could be game over.

[AJ2008]

There is the possibility to safely extract data without cloning, the RAID edition of DE can be used with data copy option enabled - it is possibly the safest way to work on this case without cloning, however I agree with the comments above, since the client is trusting you with this job then it is ultimately your responsibility to ensure it is dealt with in the safest and most professional manner which would be to clone each disk and work off the clones.