0

I have a Linux file server with two 12-disk MD1000 disk arrays attached to a RAID controller. Unfortunately, a power blip has caused a loss of configuration data on the RAID controller and it is now reporting no disk configuration. I have no backup or record of the original configuration.

Looking at the server log from the last time it successfully booted, it uses mdadm to construct a RAID0 array of 4 devices (although there is no mdadm.conf file anywhere, so i guess it autodetects) and each device is a hardware RAID5 array.

To try to recover the configuration and data: I did a dd of each disks and used the ReclaiMe (Windows) tool to establish that the original configuration was RAID50 with 4 hardware RAID5 arrays (combined using mdadm) -- plus 4 spares.

ReclaiMe has also recovered images of the 4 RAID5 arrays (into files labelled 1.img, 2.img, 3.img, 4.img) and specified the following config information for the RAID0 construction:

  1. On the right side of the R-Studio window, set "RAID type" to "RAID0 (Stripe set)".
  2. Below that, set "Block size" to "256 KB".
  3. In the "Parents" table, enter "63 Sectors" as "Offset" in all rows.

I have used R-studio with these parameters to verify the data is there and I am now trying to assemble the RAID0 array using mdadm so I can mount the original filesystem. It is at this point that I am slightly stuck. I have mounted the (NTFS-formatted) physical disks containing the images (1 physical disk per image) and then mounted the images themselves as loop devices:

# losetup /dev/loop1 /media/ubuntu/disk1/1.img
# losetup /dev/loop2 /media/ubuntu/disk2/2.img
# losetup /dev/loop3 /media/ubuntu/disk3/3.img
# losetup /dev/loop4 /media/ubuntu/disk4/4.img

Running an fdisk on an loop device:

# fdisk -l /dev/loop2
Disk /dev/loop2: 2000.4 GB, 2000435544064 bytes
255 heads, 63 sectors/track, 243205 cylinders, total 3907100672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/loop2p1              63  3902798969  1951399453+  fd  Linux raid autodetect

When I try to automatically assemble,I get:

# mdadm --assemble --scan -v
mdadm: Cannot assemble mbr metadata on /dev/loop4
mdadm: Cannot assemble mbr metadata on /dev/loop3
mdadm: Cannot assemble mbr metadata on /dev/loop2
mdadm: Cannot assemble mbr metadata on /dev/loop1

When I try to do it manually:

# mdadm --create /dev/md0 -v --level=0 --assume-clean --raid-devices=4 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4
mdadm: chunk size defaults to 512K
mdadm: /dev/loop1 appears to be part of a raid array:
level=raid0 devices=0 ctime=Thu Jan  1 00:00:00 1970
mdadm: partition table exists on /dev/loop1 but will be lost or
   meaningless after creating array
mdadm: /dev/loop2 appears to be part of a raid array:
level=raid0 devices=0 ctime=Thu Jan  1 00:00:00 1970
mdadm: partition table exists on /dev/loop2 but will be lost or
   meaningless after creating array
mdadm: /dev/loop3 appears to be part of a raid array:
level=raid0 devices=0 ctime=Thu Jan  1 00:00:00 1970
mdadm: partition table exists on /dev/loop3 but will be lost or
   meaningless after creating array
mdadm: /dev/loop4 appears to be part of a raid array:
level=raid0 devices=0 ctime=Thu Jan  1 00:00:00 1970
mdadm: partition table exists on /dev/loop4 but will be lost or
   meaningless after creating array
Continue creating array? N

I wondered if the offset mentioned in the ReclaiMe output and corresponding to the Start 63 in the fdisk output required different losetup, so tried instead (because 63 * 512 = 32256):

# losetup /dev/loop1 /media/ubuntu/disk1/1.img -o 32256
# losetup /dev/loop2 /media/ubuntu/disk2/2.img -o 32256
# losetup /dev/loop3 /media/ubuntu/disk3/3.img -o 32256
# losetup /dev/loop4 /media/ubuntu/disk4/4.img -o 32256

Then:

# mdadm --assemble --scan -v 
mdadm: no recogniseable superblock on /dev/loop4
mdadm: no recogniseable superblock on /dev/loop3
mdadm: no recogniseable superblock on /dev/loop2
mdadm: no recogniseable superblock on /dev/loop1

So, I tried to manually create again:

# mdadm --create /dev/md0 -v --level=0 --assume-clean --raid-devices=4  /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4
mdadm: chunk size defaults to 512K
mdadm: /dev/loop1 appears to contain an ext2fs file system
    size=-784337920K  mtime=Wed Dec  4 12:34:29 2013
Continue creating array? N

At this point, i don't know what to do. I have already had to restore the 4 img files (totalling 8TB) from a backup a couple of times by trying options that didn't work.

[Also, is there any way to ascertain the metadata version or chunk size?]

  • If you're able to get to the data otherwise (through the recovery software), recover the data and rebuild the array from scratch. – Nathan C Sep 9 '14 at 15:34
  • Umm, don't you need an --assume-clean? – Zoredache Sep 9 '14 at 15:45
  • I can recover some data, but i think some is missing. Also the file permissions are not recovered correctly. – BW67 Sep 9 '14 at 15:53
  • Yes, sorry. I did it with --assume-clean too and the results were the same. I will edit my post to add that information. – BW67 Sep 9 '14 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.