3

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?

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
Olver Hernández Navarro
  • 31
  • 1
  • 2
    "_Is is possible to read the data without the PERC H710 controller?_", yes, of course, I know by myself form former work experience. However, it is too complex to discuss, explain and advise here because of the risk of data loss. Therefore the recommendation should be either seeking professional services for, or setup a separate test bed with similar hardware, train the steps before and transfer the steps to the other hardware. – U880D Jun 17 '23 at 13:54
  • 1
    With a separate test bed you would also be able to repair the existing setup. You could also try to use the harddisk in an external case with read-only option and use software which is able to read block devices and recover files from (like Xways, EnCase, orther Linux disc forensics software ...) – U880D Jun 17 '23 at 13:57
  • 1
    In my experience, any LSI/Avago/Broadcom MegaRAID SAS RAID controller should have recognize this RAID and run it even by default without any hassle. I once replaced a built-in PERC, older than yours (which is rebranded LSI MegaRAID SAS too) and that worked. But we *upgraded* the chip, e.g. LSI chip on PERC was older than LSI chip on the replacement. – Nikita Kipriyanov Jun 17 '23 at 14:03
  • 2
    That said, if you use a simple HBA which *is not* a RAID controller, and run Linux, it should recognize the RAID with its praised Software MD RAID module, as LSI devices use standard SNI DDF on-disk metadata, which MD driver recognizes too. So yes, without a RAID controller, or with RAID in HBA mode — just mdadm is your friend. – Nikita Kipriyanov Jun 17 '23 at 14:07
  • @NikitaKipriyanov, "_... as LSI devices use standard SNI DDF on-disk metadata ..._", if I remember correctly, that block is stored at the end of the disk behind the data. Therefore, in case of RAID1, the disk connected to HBA might look like a normal without any RAID. So, yes, it should just become recognized. – U880D Jun 17 '23 at 14:13
  • 1
    Yes, almost perfect. If there is GPT, the second GPT at the end will not be at the place. But sure, if you have RAID1 and have access to the raw device, you can always find an offset and end and take that :) – Nikita Kipriyanov Jun 17 '23 at 14:16
  • Also, to the OP: what you've seen with a single disk under live Ubuntu was exactly this case. `fdisk` saw a protective MBR and system also found *wrong* GPT so it didn't create any real partitions. Do the same, but connect *both* drives and check /proc/mdstat for MD-recognized arrays. – Nikita Kipriyanov Jun 17 '23 at 14:20

2 Answers2

9

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.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
1

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.

fraxinus
  • 624
  • 3
  • 5