Question Gaining access to old RAID array components

[niftyprose]

Hello guys, my first post here. I'm having problems accessing data from an old RAID drive. I think there's probably an easy fix, but identifying it will require someone with more experience of RAID management than I possess.

About 20 years ago I bought a computer made by well-liked UK server builder Fairchild. It had a SATA RAID array comprising two 120Gb Seagate Barracudas. When I decommissioned it five years ago, I removed the Seagates. They were working perfectly but are now bereft of their RAID controller, which is presumably in landfill somewhere.

I want to access the data from the disks in a read-only/RESCUE fashion. I bought a well-regarded USB--SATA/IDE converter kit and connected one of the two Seagates.

The drive powers up.

The drive is visible to Gparted (my first call) which identifies it as /dev/sdb and lists its filesystem as ataraid.

When I try to mount it using the command:

sudo mount /dev/sdb /mnt/sata

...I get:

mount: /mnt/sata: unknown filesystem type 'silicon_medley_raid_member'.
dmesg(1) may have more information after failed mount system call.

Initial observations:
* The disk apparently wasn't partitioned as sdb1 but rather installed directly into the RAID array as sdb
* Since the filesystem type "Silicon Medley" doesn't exist, I think this name must be a reference to the hardware raid controller -- the computer wrote to the controller and the controller then handled the disk management


More findings:

sudo fdisk -l gives:

Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors Disk model: XT-U33502 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes

sudo parted /dev/sdb -l gives:

Error: /dev/sdb: unrecognised disk label
Model: XinTop XT-U33502 (scsi)
Disk /dev/sdb: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

I then got a bit ahead of myself and tried sudo mdadm -A -R /dev/md0 /dev/sdb

mdadm: no recogniseable superblock on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

Before anyone asks: I tried both the hard drives, with the same results throughout.

My sketchy deduction is that the disks were configured to work with the Silicon Medley raid controller. I doubt that they could have functioned without some kind of superblock or partition table but those structures aren't accessible to me at present. Without a superblock, I can't mount the disk(s)

I only need to read ONE of the disks ONCE to transfer its contents to archive. All suggestions gratefully received. Bonus points if you remember any specifics about Silicon Medley.

TIA, NP.

 

[niftyprose]

I took this further myself, but still need help.

I figured out that the mdadm management utility may not be the best choice for this legacy setup. Accordingly I activated DMRaid, which has native support for the Silicon Medley RAID format.

sudo dmraid -ay gives me

ERROR: sil: wrong # of devices in RAID set "sil_adabceahdiaa" [1/2] on /dev/sdb
RAID set "sil_adabceahdiaa" was activated

We can discount that ERROR -- I only connected one of the paired RAID drives. So, now I have an active RAID set called "sil_adabceahdiaa". (Whoop de doo.) lsblk still doesn't show a UUID for the newly-activated set or for the component device. If I try to mount it, I get the same old error:

niftyprose@q4os-desktop:~$ sudo mount /dev/sdb /mnt/sata
mount: /mnt/sata: unknown filesystem type 'silicon_medley_raid_member'.

(the same was true for the new long name beginning "sil", too.)

I think I may be missing something. Any pointers?

Best, NP.

 

[stonecarver]

About 20 years ago I bought a computer made by well-liked UK server builder Fairchild. It had a SATA RAID array comprising two 120Gb Seagate Barracudas. When I decommissioned it five years ago, I removed the Seagates. They were working perfectly but are now bereft of their RAID controller, which is presumably in landfill somewhere.

Is that Fairchild company still around. Maybe just maybe they might have the old raid controller on some backroom dusty shelf.

 

[fzabkar]

Can you show us the Partitions tab in DMDE? DMDE has both Linux and Windows versions.

https://dmde.com/

This is probably a better group for your question:

https://ww.reddit.com/r/datarecovery/rising/

Data recovery pros hang out there, many with experience in old hardware and RAID systems.

BTW, Silicon Medley was "Silicon Image's Medley™ ATA software RAID".

https://www.datasheetarchive.com/datasheet/230580006e7d3fff?type=P&term=silicon%20medley (SiI0680 Starter Kit with Medley software RAID)
https://theretroweb.com/chip/documentation/sii0680-pb-663f4aa85934e075846574.pdf

https://bitsavers.computerhistory.org/components/siliconImage/datasheet/SiI-DS-0069-C_SiI0680A.pdf (Silicon Image SiI0680A PCI to IDE/ATA controller)

 

[niftyprose]

Thanks, guys, esp. fzabkar. I wasn't aware of that Reddit and will cross-post there. I will also update this thread with DMDE output tomorrow when I bring the workstation back online, promise.

Humint aside: when I activated DMRaid I found the developer's email address in the manpage so I wrote directly to him, about 20 years late. Well, if anyone's gonna know...

Best, NP.

 

[fzabkar]

I suspect that there may be RAID metadata at the beginning of the drive. If so, then this would mean that the partition table would be offset from sector 0 where it normally resides. Assuming this is the case, and assuming that you indeed have a mirrored RAID (RAID 1), then DMDE should find your data.