4 Drive RAID 5 with Ext3 format and EFI partitioning

[BytesBack]

Greetings.

I've got a 4 1 TB drive RAID 5 from a Seagate BlackArmor 440 NAS. It appears that the drive is formatted in Ext3, with EFI partitioning, neither of which am I well experienced in.

All 4 drives have been imaged, how can I go about figuring out the order and stripe size? I'm looking for information akin to that found here: http://www.r-tt.com/Articles/Finding_RAID_parameters/

Are the file records numbered in Ext3 like they are in NTFS? Are there helpful strings to search for like $MFT, FILE0, etc. in Ext3?

Any pointers would be appreciated.

Thanks!

[networks]

You may want to try this and see if it can discover the parameters. http://www.runtime.org/nas-recovery.htm I saw one post on the Seagate forum for the same info never had any response. Possibly a call to support may yield some results not holding my breath. Keep us posted on the progress

[BytesBack]

No dice on that utility. In my experience those automatic parameter discovery tools almost never work. I prefer checking for the parameters myself in hex. My only issue here is that I don't know what I'm looking for.

[BytesBack]

No dice on that utility. In my experience those automatic parameter discovery tools almost never work. I prefer checking for the parameters myself in hex. My only issue here is that I don't know what I'm looking for.

[hddguy]

Are the file records numbered in Ext3 like they are in NTFS? Are there helpful strings to search for like $MFT, FILE0, etc. in Ext3?

EXT does use a sequential record system in the partition, this may help a little but I dont think it will be enough to help you rebuild this volume.

[pcimage]

I suggest you enlist the help of "dr-kiev" on this forum

[hddguy]

I suggest you enlist the help of "dr-kiev" on this forum

I agree. DR-kiev can certainly handle this

[BytesBack]

Yeah, I love DR-Kiev. He's magical.

*swoon*

[darkforce1]

No Doubt. DR-Kiev is Master in Raid.

DF

[BytesBack]

Got the RAID figured out. Got all the data off. Ran into an issue though. It seems that the RAID had been crapping out for the last couple weeks and the file system was pretty messed up. There were some files that showed up in R-Studio as several EXABYTES in size (Max possible volume size for this RAID was 2.7 TB). The customer went through the data and found that everything old was in good shape, but the current projects he has are all coming up with missing files or showing 0KB size or some of the file shows, others do not, etc.

This is the Ext3 file system, anyone know of any good tools to repair the file system in place? I think I've got all the data off that I can manage.

[DR-Kiev]

The customer went through the data and found that everything old was in good shape, but the current projects he has are all coming up with missing files or showing 0KB size or some of the file shows, others do not, etc.

It means that some drive wasn't working for a long time , you should to skip it while reconstructing to get better result.

[BytesBack]

Thanks for the input, DR-Kiev. Unfortunately, I already did that. Disk 4 was the only one with any read errors when imaged on DDI and that was confined to just bad 3 sectors. Still, I figured those 3 sectors could be better reconstructed from parity data so drive 4 was set as a missing disk in R-Studio. Disks 1,2,3 all imaged perfectly, 0 unread sectors after the first pass.

[BytesBack]

Any other ideas? Any ways of recovering from a journal or anything wacky like that?

[drc]

Probably one of the drives you are currently using failed out some time ago, and the drive with bad sectors was the 2nd drive to fail out

Lots of times customers don't notice anything is wrong until the 2nd failure, which brings down the volume

[DR-Kiev]

Any other ideas? Any ways of recovering from a journal or anything wacky like that?

Create few arrays , with different missing drives (for diferent zones) and correctly connect them between each other as JBOD.
For example for those zone where drive4 has bads , skip this drive, for all others zone's skipe another drives and so on.

[psalazar]

DR-Kiev, BytesBack,

I have the same problem with the same raid configuration (NAS440 with 4x1tb drives). I have block size and block order (left synchronous), but I need the drive order and offset(s). Can either of you help.

thanks!

[harddrivespecialist]

DR-Kiev, BytesBack,

I have the same problem with the same raid configuration (NAS440 with 4x1tb drives). I have block size and block order (left synchronous), but I need the drive order and offset(s). Can either of you help.

thanks!

Are you sure all of your drives in good working condition?

[Michael.Reilly]

If you know xor arithmetic then I would suggest finding a place with patterned data or text on one drive and the other two drives mostly (but not entirely) blank. From there you can figure out which one is the parity disk by inspecting the other three for "screwed up text," it'll be text but wherever the data isn't blank on the other two drives will be different.

To find the ext3 offset you can search for 0xEF53 (53 ef on disk) at offset 0x38.

Also, if you can examine the hex and tell which order the stripes are in, because you know it's left symmetric you can figure out what order they're in.

0 1 2 P
4 5 P 3
8 P 6 7
P 9 A B

[psalazar]

I was able to create an image file of all 4 drives without any errors, so I'm guessing they are good.

I'll check on M.Reilly's suggestion and get back to you.

[psalazar]

So here's the process to recovery data from a BlackArmor 440 NAS with raid 5. It took a while, but I recovered ALL MY DATA (1.2TB) and it was really quite easy (once you know how). I do not recommend using any of the commercial software or companies out there until you try this first.

I had a BlackArmor 440 with 4x1tb drives set up as Raid 5 configuration. What I did was find a PC with an open PCIe slot and inserted a sata card with 2 sata ports. I then hooked up all four drives to the PC, with 2 sata ports from my new card and 2 free sata ports from the motherboard. I then downloaded and burned a Knoppix live cd and rebooted. Once booted I started the X server and brought up a shell. Here is the magical formula that no one wants to tell you.

COMMANDS USED FOR RECOVERY
-----------------------------------------------------
1) fdisk -l (used to find your raid sata drives)
2) mdadm -examine /dev/sd[abde]4 (used to get the uuid of the raid array)
3) mdadm --assemble --force /dev/md0 --uuid=76f68200:764ae344:42443e49:162b00c5 (this is where the magic happens. mdadm will check all the superblocks and re-assembly your raid drive onto device /dev/md0. Try the command first without the '--force' option and if that doesn't work, then use it)
4) modprobe dm-mod {next 4 commands were needed to mount a LVM2 partition type, which the raid uses}
5) vgchange -ay
6) lvscan
7) mount /dev/vg0/lv0 /media/md0 (used to mount the data partition)

Once complete, you can 'cd' to '/media/md0' and copy all your files. I used rsync to copy my files to a 3tb western digital usb drive. Took a long time, but this works when your linux nas box disables the raid volumn, even though the drives spin up with no problems. I've researched why this happens, and the usual scenario is when one drive is marked 'inactive' and then another drive has a latent read/write error, forcing that drive to become inaction as well. The linux raid then takes the volumn offline even though it is very capable of recovering. (at least thats how I understood what's happening).

Hope this helps out all you Linux NAS users.

cheers,
PS