Iomega 150d NAS Recovery

[rolmander]

Hi!

my boss told me to recover this raid 5 nas
and yes i used google and had about 50 tabs with usefull information open

I have a little experience in nas recovery but mostly easy jobs with madadm, intact superblocks, partitions with custom filesystem offsets and logical volumes.

First i tried to find information about the nas, it uses a Sil3114CTU chip which is afaik not capable of hardware raid.
The harddrives seem to be in good condition (SMART status is good, no strange sounds)
Then i searched the linux partition, but i couldn´t find out how mdadm mounts the raid (but bin/mdadm exists but no /etc/mdadm.conf).

fstab shows "/dev/md/0 /nethdd xfs defaults,noauto 0 0"
rcX.d are empty.
I think the commands to mount the raid are in the cgi files. I searched every other file. (maybe i overlooked something)

the deamon.log shows only the day when the nas died.

The interesting parts are

Code:

Feb 15 09:26:31 Iomega-01DB47 user.warn kernel: md: cannot remove active disk sde1 from md3 ... (30x)
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: md0: sync done.
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: syncing RAID array md3
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: using 128k window, over a total of 4112512 blocks.
Feb 15 09:26:35 Iomega-01DB47 user.info kernel: md: md3: sync done.
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel: RAID5 conf printout:
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  --- rd:4 wd:4 fd:0
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 0, o:1, dev:sde2
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 1, o:1, dev:sdb2
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 2, o:1, dev:sdc2
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 3, o:1, dev:sdd2
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel: RAID1 conf printout:
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  --- wd:3 rd:4
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 0, wo:1, o:0, dev:sde1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 2, wo:0, o:1, dev:sdc1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 3, wo:0, o:1, dev:sdd1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel: RAID1 conf printout:
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  --- wd:3 rd:4
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 2, wo:0, o:1, dev:sdc1
Feb 15 09:26:35 Iomega-01DB47 user.warn kernel:  disk 3, wo:0, o:1, dev:sdd1
Feb 15 09:27:00 Iomega-01DB47 user.info kernel: md: unbind<sde1>
Feb 15 09:27:00 Iomega-01DB47 user.info kernel: md: export_rdev(sde1)
Feb 15 09:27:16 Iomega-01DB47 user.info kernel: md: bind<sde1>
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel: RAID1 conf printout:
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel:  --- wd:3 rd:4
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel:  disk 0, wo:1, o:1, dev:sde1
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel:  disk 2, wo:0, o:1, dev:sdc1
Feb 15 09:27:16 Iomega-01DB47 user.warn kernel:  disk 3, wo:0, o:1, dev:sdd1
Feb 15 09:27:16 Iomega-01DB47 user.info kernel: md: syncing RAID array md3
Feb 15 09:27:16 Iomega-01DB47 user.info kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Feb 15 09:27:16 Iomega-01DB47 user.info kernel: md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
Feb 15 09:27:16 Iomega-01DB47 user.info kernel: md: using 128k window, over a total of 4112512 blocks.
Feb 15 09:28:21 Iomega-01DB47 user.info kernel: md: md3: sync done.
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel: RAID1 conf printout:
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel:  --- wd:4 rd:4
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel:  disk 0, wo:0, o:1, dev:sde1
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel:  disk 2, wo:0, o:1, dev:sdc1
Feb 15 09:28:21 Iomega-01DB47 user.warn kernel:  disk 3, wo:0, o:1, dev:sdd1
Feb 15 09:29:05 Iomega-01DB47 daemon.err upsd[369]: Can't connect to UPS [myups] (usbhid-ups-myups): No such file or directory


sdx1 is the linux raid1
sdx2 is the data raid5

I dont unterstand how sde1 failure can corrupt the raid5 but maybe there are parts missing in the logfile.

mdadm force assemble commands doesnt work because of the missing superblocks.

Then i tried UFS explorer and added the disks in order from top to bottom of the nas and standard settings (64k left symetrical) and voila a SGI XFS partition appered in perfect condition.
I was happy until i saw that there were only the default directory structure, user data was missing.
Hexdump at random sections at the harddrive shows the disks where not zeroed my data should be still there.
I think someone tried to recover the data by manually rebuilding/resetting the raid, maybe the device itself.

I tried a scan over the intact partition but i got only corrupted files exept html files. (filename was gone but the code was intact.) Strange was that every txt file was corrupt.
JPEGs got their Photoshop header but i couldnt open them.

At the moment i try to align the raid in different order because filesystem scan in 1234 order doesnt show a second filesystem (is that a stupid idea?)
1234 shows the default structure
4123, 3412, 2341 are still scanning but showing 2 SGI XFS partitions at different negative(wtf?) offsets (-60533888 and -484271280) with different Unique IDs.

Does the negative offset tell me that the partition starts on the previous harddisk?

btw i am working on backup images of the second parditions (sdx2), thx to ufs explorer.

Any ideas or suggestions?

and sorry english is not my primary language (I struggle at my primary language too )

[bcometa]

Try Runtime's Nas Data Recovery.

[rolmander]

@bcometa
Thx i have the demo installed but it never worked.
Its worth a try

ps: I can´t PM right now, i have to participate more.

[hddguy]

Then you need to make it manually with Winhex and lots of concentration

[bcometa]

If you can't figure it out, post some more and then PM DR-Kiev - he'll be able to remote-login to your computer and manually (read: magically) reconstruct the raid for a very low fee.

[rolmander]

hey
sorry for the late answer i was busy with not work relatet thinks on weekend

@hddguy haha Never thought of that... but maybe next time when somebody give me a floppy raid.

@bcometa That would be very nice but at the moment i can´t PM:
"We are sorry, but you are not authorised to use this feature. You may have just registered here and may need to participate more to be able to use this feature. "

What would you need? I have Windows and Linux both accessable via Teamviewer. Maybe i can give you ssh access too.

[bcometa]

Humm... not sure if it's okay to post his email address here or not. I'd have thought he'd chime in by now, perhaps he's not available.

[rolmander]

@bcometa
I can receive PMs but i cannot compose or send PMs.

After some XAGF entries are filenamens of lost files. Is that a good sign?