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

[trinsic]

I am attempting to recover data from a raid 0 two drive array. These two drives were part of an caldigit VR 4000GB enclosure. The controller has since failed so I am attempting to do the recover on another USB enclosure.

The drive specifics are below:

*-disk:0
description: SCSI Disk
physical id: 0.0.0
bus info: scsi@8:0.0.0
logical name: /dev/sdg
size: 1863GiB (2TB)
capabilities: partitioned partitioned:dos
configuration: sectorsize=512
*-disk:1
description: SCSI Disk
physical id: 0.0.1
bus info: scsi@8:0.0.1
logical name: /dev/sdh
size: 1863GiB (2TB)
configuration: sectorsize=512
root@bench:/home/trinsic#
root@bench:/home/trinsic# mdadm --misc --examine /dev/sdh
mdadm: No md superblock detected on /dev/sdh.
root@bench:/home/trinsic# mdadm --misc --examine /dev/sdg
/dev/sdg:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)

I talked to the person using this drive, he said the drive booted but hanged during a on device system check of the array VIA LCD display. He power cycled it the enclosure and it went though its check successfully this time, but the OS failed to read the partition when it was connected to his mackbook pro. The drive was partition as HFS+

I booted the two drives up in my linux box and checked for a partition using SFdisk, but it was missing as far as I could tell.

During a scan for lost partitions using testdisk I got a raid failure on the LCD display and testdisk stopped responding. I attempted to power cycle the enclosure but one of the drives wouldn't finish its check and the test failed to complete successfully. I attempted to reseat the drives but the enclosure would not reaching a passing state in the test of the drives. So i pull the drives out of the enclosure and put it into my two drive enclosure.

I did a smart scan on both the drives and the both are healthy.

Since i dont know how to build a virtual raid in linux I used UFS Explorer to create the virtual raid making sure drive 0 was the first drive in the list and ran a partition recovery on it. It found 6 partitions with different characteristics and wondered what would be the best way to find out which one was the right one. attached is a picture of HFS Explorer's recovered partition information.
I want to make sure I recover the right partition and wondered if anyone has experience with this particular kind of recovery that could help, thank you.

Attachments

UFS explorer list of partitions recovered from the virual raid 0

[jermy]

first things first, clone the drives and don't mess around with the original

[trinsic]

first things first, clone the drives and don't mess around with the original

Ok I purchased a 4tb drive, but I dont have enough free space to hold both images. Do you have any recommendations? I cant afford a bigger drive right now.

The two drives together equal 3.910.92tb and the available free space on the 4tb drive is 3.7tb

[data-medics]

first things first, clone the drives and don't mess around with the original

Ok I purchased a 4tb drive, but I dont have enough free space to hold both images. Do you have any recommendations? I cant afford a bigger drive right now.

The two drives together equal 3.910.92tb and the available free space on the 4tb drive is 3.7tb

If you can't even afford a drive to put the target data onto, then perhaps you shouldn't be offering data recovery services. Seems that you're ill-equipped both materially and knowledge wise. Get the clones of the drives first using ddrescue, then ask about the logical side of the recovery or you won't get much help here. None of us want to be responsible for helping you to permanently lose someone's data (which you're on the course toward that).

No point in scanning with testdisk or any other software against a single member of a RAID. Do you even know how a RAID functions? You'll have to build a virtual array and determine the correct settings before you can attempt any of that. Also since it's HFS you may end up having to manually define the starting sector of the partition (seems to happen alot).

[trinsic]

first things first, clone the drives and don't mess around with the original

Ok I purchased a 4tb drive, but I dont have enough free space to hold both images. Do you have any recommendations? I cant afford a bigger drive right now.

The two drives together equal 3.910.92tb and the available free space on the 4tb drive is 3.7tb

If you can't even afford a drive to put the target data onto, then perhaps you shouldn't be offering data recovery services. Seems that you're ill-equipped both materially and knowledge wise. Get the clones of the drives first using ddrescue, then ask about the logical side of the recovery or you won't get much help here. None of us want to be responsible for helping you to permanently lose someone's data (which you're on the course toward that).

No point in scanning with testdisk or any other software against a single member of a RAID. Do you even know how a RAID functions? You'll have to build a virtual array and determine the correct settings before you can attempt any of that. Also since it's HFS you may end up having to manually define the starting sector of the partition (seems to happen alot).

I have a basic idea how raid functions. I dont know if you understood my orginal statement, but I scanned the drives while they were in the enclosure, (before the enclosure died) so the operating system read both drives as one drive in a raid 0 configuration. Please correct me if I am wrong.

I have found another external 2tb drive that I'm currently cleaning it of data and I'm going to split the two images. one on the 2tb and one on the 4tb.

Ill post back when its done, sometime tomorrow.

Thank you for the response.

[data-medics]

You can't write a 2Tb image file to a 2Tb HDD, just FYI. Otherwise they would both fit on the 4Tb one. The file system takes up some space, so you'll always need a bigger drive. However you can directly image the whole drive to it with ddrescue instead.

[trinsic]

You can't write a 2Tb image file to a 2Tb HDD, just FYI. Otherwise they would both fit on the 4Tb one. The file system takes up some space, so you'll always need a bigger drive. However you can directly image the whole drive to it with ddrescue instead.

Yeah I just realized that. Im going to do a sector by sector copy of that one drive and image the other one to the 4tb.

[trinsic]

Ok, Backups are made of both drives as outlined and stored in a safe place away from the recovery environment.

[DR-Kiev]

Configuration of Caldigit's RAID0 is a bit tricky. Set 1 sector stripe size.

Attachments

[trinsic]

Configuration of Caldigit's RAID0 is a bit tricky. Set 1 sector stripe size.

Done.
FYI, I made sure the drive configuration is in the correct order by refreshing the storage devices one for each drive detection.

Attachments

[DR-Kiev]

Now , start seaching for the Hfs+ partition , it usualy starts from 409640 offset

[trinsic]

Now , start seaching for the Hfs+ partition , it usualy starts from 409640 offset

I started it, but it looks like its going to take 380 hours? is that right?

Attachments

[Dmitri]

it looks like its going to take 380 hours?

The most obvious thing to check is how the drives you're working with are connected to the system.
The "USB" you're using, isn't it something like USB 2.0? Maybe even with both drives on the same port through a hub?

Remember about small stripe size. You will also need time to copy recovered data at a similar speed.

[trinsic]

it looks like its going to take 380 hours?

The most obvious thing to check is how the drives you're working with are connected to the system.
The "USB" you're using, isn't it something like USB 2.0? Maybe even with both drives on the same port through a hub?

Remember about small stripe size. You will also need time to copy recovered data at a similar speed.

I now have in my possession a new replacement caldigit enclosure of the same type of the original enclosure these two drives are in when it died. Here is the new screen shot with the enclosure connected via sata. The scan time has decreased to 6 hours. Ill let you know when its done.

Attachments

[trinsic]

The scan is complete.

Attachments

[data-medics]

I don't think I've ever seen an HFS+ partition start at offset 2048 before. Seems fishy to me.... Perhaps the start of the partition was wiped somehow. If you're not able to open any files by using that layout, try manually defining a HFS+ partition at sector 409640 instead.

[trinsic]

OK, I adding the partition at that range, but it comes up as unknown, or raw.

Attachments

[trinsic]

It doesnt look like there is any data until position 0x1127C000

Attachments

[trinsic]

Also the HFS+ file system only has one directory HFS+ PRivate Data but the folder is empty.

Attachments

[Dmitri]

I don't think I've ever seen an HFS+ partition start at offset 2048 before.

OP has connected the storage as DAS instead of a set of drives.