Is it possible to recover data from an Intel PERC H710 Adapter RAID Controller disks into another server with SAS controller

I have a Dell T420 server with a PERC H710 Adapter RAID Controller. I had a RAID 1 with two hard drives. And another disk into the same controller, with no RAID only for backup.

The Motherboard of this server now is damaged, It didn't boot because of a hardware failure in a NIC card.

I have access to another old Dell PowerEdge 2900 with a SAS Controller.

I'm trying to connect the hard disks into the old server to recover the backup or the filesystem of my server but I didn't have success yet.

I tried to connect the backup disk (A seagate barracuda 2TB disk) and it didn't appear when using a live ubuntu.

When I tried with one of the RAID 1 disks (a Dell Constellation 4T disk), it appear but I'm unable to mount the disk.

    sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 2 TiB, 2199023254528 bytes, 4294967294 sectors
Disk model: ST4000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdb1           1 4294967295 4294967295   2T ee GPT

sudo mount /dev/sdb1 /media/backup/
mount: /media/backup: special device /dev/sdb1 does not exist.

sudo mdadm --assemble --run /dev/md0 /dev/sdb1
mdadm: cannot open device /dev/sdb1: No such file or directory
mdadm: /dev/sdb1 has no superblock - assembly aborted

ls /dev/mapper/*
/dev/mapper/control

Is is possible to read the data without the PERC H710 controller?

LSI/Avago/Broadcom MegaRAID SAS devices happily recognize RAIDs from each other. PERC H710 is such a rebranded controller with LSI chip. Once in my experience we transferred a pair of devices from older gen8 Dell PERC (don't remember which controller exactly) to some certainly newer LSI card, and that card happily recognized a RAID and OS booted from it, as if nothing happened. The only difference from your case was that new card had newer LSI chip than old PERC. Try it.

Also, MegaRAID uses SNIA DDF on-disk metadata, which is publicly defined and also it is recognized by the Linux software RAID MD driver. You can even create such RAID with mdadm.

What you see with fdisk is so called protective MBR. It means only one thing: there is a GPT partition table on the device. As mentioned in comments, DDF metadata is at the end of the device, so the second GPT which is normally at the end was misplaced, so GPT appears broken and no partitions are regognized. It also didn't start it as an array due to the standard behaviour "don't start a degraded array unless it was already marked as degraded during shutdown".

So if you connect both drives using HBA (no RAID functionality, allowing raw access to drives) to a Linux machine, even live, it must recognize and create "ordinary" software RAID out of it. Repeat with both of them, then check /proc/mdstat.

Another way, it we know exact size of your virtual disk, we can set up a loop device on top of the hard drive with size limit, so the second GPT on the loop will appear in place and it will find its partitions. It is possible to guess: coercion size of LSI is either 128MiB or 1GiB, but for that I need to see the exact size of your 4T disk.

Most modern Linux distributions recognize these "hardware" RAID volumes out of the box.

In the ideal case, one could connect all of the salvaged disks to a machine with SATA/SAS controller, boot Linux from an USB flash or CD and navigate their way to:

• reconstruct the RAID array in a read-only fashion

The read-only part is important because of the possible reconstruction mistakes that may ruin the only surviving copy of your data.

If feasible, the content of the whole disks could be backed up elsewhere before any of the RAID reconstruction attempts.

• mount the filesystems over the reconstructed RAID (also read-only). Linux has drivers for the most filesystems one can see in use today. Some of them are incomplete, but all of them are OK for reading files.

• copy the important data over the network or another storage device attached to the same machine.

• swear not to use "hardware RAID" anymore if at all avoidable.

Because there is no such thing as a "hardware RAID". The RAID layer always runs in software - be it in a specialized controller or (as in H710 case) right on your host CPU as a not-very-well-written device driver.