Recovering a lost HFS+ partition fr a two drive raid 0 array

[trinsic]

I did a scan on the drive for recoverable files. It looks like it found some .trash directories and one program folder.

The rest is extra files with generated names.
The interesting part is it looks like it found a lot of the meta files for the drive. Is there a way to construct the partition from the meta information?

Attachments

[trinsic]

Im doing a file recovery on this since I cant get any further help on recovering the file structure. Can anyone tell me why the file recovery scan shows 50.00TB on a 4TB drive? Im not going to be able to do a full recovery on the disk with that much space to recover from. Any suggestions on how to handle this?

[S.Haran]

Here's a python script that you may find helpful. It will create an image from two RAID-0 member drives. Then you can use Linux tools to attempt recovery from the image... http://indianalinux.blogspot.com/2008/0 ... rrays.html

To test instead of making a full 4TB image you could probably make a partial image to see if the results look promising.

I'm working on a way to take two RAID-0 drives and assemble them to create a mountable block device in Linux, which would eliminate the image creation step, but I'm not there yet.

[trinsic]

Here's a python script that you may find helpful. It will create an image from two RAID-0 member drives. Then you can use Linux tools to attempt recovery from the image... http://indianalinux.blogspot.com/2008/0 ... rrays.html

To test instead of making a full 4TB image you could probably make a partial image to see if the results look promising.

I'm working on a way to take two RAID-0 drives and assemble them to create a mountable block device in Linux, which would eliminate the image creation step, but I'm not there yet.

I have the 2 drives in an identical replacement raid 0 enclosure that works fine, so that is not the problem any longer, right now im just trying to resolve an issue where the file recovery is reporting that there is more space to recover from than the size of the drive itself.

[labtech]

Use the filter option to rid of obvious files that don't make sense size wise.

[trinsic]

Use the filter option to rid of obvious files that don't make sense size wise.

Yeah the program is is crashing on me when I mess with the filter settings on this particular drive, I do not know why maybe too many files or something. So I am now re sorting to recover one file type at a time and working though the files that way.

[labtech]

Likely crashing because files' sizes don't make sense and it is eating up all RAM trying to process them.

Still, to me, something seems wrong with the set up or some other damage took place besides that of the enclosure.

[trinsic]

Likely crashing because files' sizes don't make sense and it is eating up all RAM trying to process them.

Still, to me, something seems wrong with the set up or some other damage took place besides that of the enclosure.

Thanks for the followup.

The setup is just a 2 drive raid 0 inside an identical hardware raid enclosure replacement. The HFS+ partition has been damaged. Are you suggestion something else is wrong beyond that?

Im not quite clear on what else could be wrong.

[labtech]

If the original problem was the enclosure, then the partition should not be damaged. The fact that the results from the attempts in trying to put the RAID together and finding correct logical structure are unsuccessful, it indicates that likely the RAID array is not put together properly, even with just putting the drives in an exact same model working replacement enclosure.

Now this assumption could be false if the HFS+ volume had gotten damaged during the recovery attempts or before that.

But we do not know, because we have not been able to confirm one way or another.

To confirm, the proper way is to connect the drives themselves directly to a machine and have somebody knowledgeable put the RAID together per instructions already supplied in earlier posts using R-Studio and/or UFS. From a safety perpesctive, it should be clones of the drives that it should be used, not the original drives.

All the best. Hope it will work out for you.

[trinsic]

If the original problem was the enclosure, then the partition should not be damaged. The fact that the results from the attempts in trying to put the RAID together and finding correct logical structure are unsuccessful, it indicates that likely the RAID array is not put together properly, even with just putting the drives in an exact same model working replacement enclosure.

Now this assumption could be false if the HFS+ volume had gotten damaged during the recovery attempts or before that.

But we do not know, because we have not been able to confirm one way or another.

To confirm, the proper way is to connect the drives themselves directly to a machine and have somebody knowledgeable put the RAID together per instructions already supplied in earlier posts using R-Studio and/or UFS. From a safety perpesctive, it should be clones of the drives that it should be used, not the original drives.

All the best. Hope it will work out for you.

The partition was damaged before the recovery happened per the information the person gave me when he said that when the raid controller hung. When he power cycled the unit he was unable to see the partition. The next thing he did was to scan the drive for errors, but the system could not find the partition. He didnt do any repairs on the drive he said.

When the drives were out of the enclosure and the raid was assembled per instructions I scanned for partitions but there was only one HFS+ that started at 2048. further scanning for partitions but it was taking way to long 380+ hours using a usb two drive 3.0 controller.

So I am using an identical enclosure, when I inserted both the drives and the array was assembled without error. So you are saying that it may not have assembled the array correctly? I dont mean to be a pest, but if the array assembles without error, in my experience the array is assembled correctly.

[trinsic]

If the original problem was the enclosure, then the partition should not be damaged. The fact that the results from the attempts in trying to put the RAID together and finding correct logical structure are unsuccessful, it indicates that likely the RAID array is not put together properly, even with just putting the drives in an exact same model working replacement enclosure.

Now this assumption could be false if the HFS+ volume had gotten damaged during the recovery attempts or before that.

But we do not know, because we have not been able to confirm one way or another.

To confirm, the proper way is to connect the drives themselves directly to a machine and have somebody knowledgeable put the RAID together per instructions already supplied in earlier posts using R-Studio and/or UFS. From a safety perpesctive, it should be clones of the drives that it should be used, not the original drives.

All the best. Hope it will work out for you.

The partition was damaged before the recovery happened per the information the person gave me when he said that when the raid controller hung. When he power cycled the unit he was unable to see the partition. The next thing he did was to scan the drive for errors, but the system could not find the partition. He didnt do any repairs on the drive he said.

When the drives were out of the enclosure and the raid was assembled per instructions I scanned for partitions but there was only one HFS+ that started at 2048. further scanning for partitions but it was taking way to long 380+ hours using a usb two drive 3.0 controller.

So I am using an identical enclosure, when I inserted both the drives and the array was assembled without error. So you are saying that it may not have assembled the array correctly? I dont mean to be a pest, but if the array assembles without error, in my experience the array is assembled correctly.

[labtech]

Well, from my perspective, theoretically, a volume should not have gotten damaged if there was a problem with the controller, unless something additional happened either with the drives indepentently or once placed in the new replacement box. Or the user attempted a format of some kind prior to sending to you, which may have fully or partially destroyed the original volume structure, all dependent on how it was done if attempted.

Either way, with current replacement set up, we can't really verify anything.