ZombieRAID: virtualized raid recovery

quequotion · 2015-01-22 03:34:02

I'm trying to recover a RAID array without building a computer from scratch for the purpose.

I'm close, but missing a few magical incantations that could bring this virtualized RAID array to life.

I combined the advice of kernel.org's RAID Recovery, ArchWiki's Disk Cloning and this response on ServerFault.

The 4-disk RAID:5 array was created in Windows 7 on a computer that experienced either motherboard or PSU failure. I believe the disks were unaffected and their data is recoverable if their configuration can be reassembled.

The ServerFault question is the same as what I'm attempting to do:

1. Make raw images with dd
2. Mount the images as block devices
3. Reassemble the array

Step 1 worked. I made images of the disks containing all of their partitions.

Here's on one of the disk images:

fdisk -l hdj-1.img

Disk hdj-1.img: 298.1 GiB, 320075726848 bytes, 625147904 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
Disklabel type: dos
Disk identifier: 0x1b39f35b

Device     Boot     Start        End    Sectors   Size Id Type
hdj-1.img1 *         2048 1573351423 1573349376 750.2G  7 HPFS/NTFS/exFAT
hdj-1.img2      838862848 1875410943 1036548096 494.3G  7 HPFS/NTFS/exFAT

Step 2 seems possible, but I need a little more voodoo. I can mount the images to loop devices, but their partitions do not get devices.

I'm mounting the devices with "sudo losetup -r /dev/loopN hdj-N.img"
I tried mounted them with -P ("Force the kernel to scan the partition table on a newly created loop device.") but this only creates a single, empty partition for each image file (not any of the partitions in the images).

fdisk is aware of the partitions in the loop devices:

sudo fdisk -l /dev/loop{1,2,3,4}

Disk /dev/loop1: 298.1 GiB, 320075726848 bytes, 625147904 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
Disklabel type: dos
Disk identifier: 0x1b39f35b

Device       Boot     Start        End    Sectors   Size Id Type
/dev/loop1p1 *         2048 1573351423 1573349376 750.2G  7 HPFS/NTFS/exFAT
/dev/loop1p2      838862848 1875410943 1036548096 494.3G  7 HPFS/NTFS/exFAT

Disk /dev/loop2: 298.1 GiB, 320075726848 bytes, 625147904 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
Disklabel type: dos
Disk identifier: 0x58e4af2f

Device       Boot Start     End Sectors  Size Id Type
/dev/loop2p1 *     2048 1048575 1046528  511M  7 HPFS/NTFS/exFAT

Disk /dev/loop3: 298.1 GiB, 320075726848 bytes, 625147904 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
Disklabel type: dos
Disk identifier: 0x88a96432

Device       Boot Start        End    Sectors   Size Id Type
/dev/loop3p1 *     2048 1875417087 1875415040 894.3G  7 HPFS/NTFS/exFAT

Disk /dev/loop4: 298.1 GiB, 320075726848 bytes, 625147904 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
Disklabel type: dos
Disk identifier: 0xcb743846

Device       Boot     Start        End    Sectors   Size Id Type
/dev/loop4p1 *         2048  838862847  838860800   400G  7 HPFS/NTFS/exFAT
/dev/loop4p2      838862848 1875410943 1036548096 494.3G  7 HPFS/NTFS/exFAT

However, none of the partition devices, /dev/loopNpX, are created.

I've tried "mdadm --assemble" on the block devices to no avail (and no surprise), but mdadm is somewhat aware of their RAID configuration:

sudo mdadm --examine /dev/loop{1,2,3,4}
/dev/loop1:
   MBR Magic : aa55
Partition[0] :   1573349376 sectors at         2048 (type 07)
Partition[1] :   1036548096 sectors at    838862848 (type 07)
/dev/loop2:
   MBR Magic : aa55
Partition[0] :      1046528 sectors at         2048 (type 07)
/dev/loop3:
   MBR Magic : aa55
Partition[0] :   1875415040 sectors at         2048 (type 07)
/dev/loop4:
   MBR Magic : aa55
Partition[0] :    838860800 sectors at         2048 (type 07)
Partition[1] :   1036548096 sectors at    838862848 (type 07)

Last edited by quequotion (2015-01-22 07:20:08)

quequotion · 2015-01-22 04:08:01

Progress and Failure:

I am aware of a method of mounting the individual partitions from the images by calculating their offsets (most of which are outside the physical disk), but I do not believe that is compatible with reassembling a raid array. If it were even possible to mount raid partitions in that way, I think mdadm would fail because it expects block devices with MBR, etc.

partprobe should force the kernel to update the partition table; unfortunately it's not compatible with RAID partitions.

sudo partprobe /dev/loop{1,2,3,4}
Error: Can't have a partition outside the disk!
Error: Can't have a partition outside the disk!
Error: Can't have a partition outside the disk!

One of the disks did get a partition device: /dev/loop2p1

kpartx also fails:

sudo kpartx -av /dev/loop1
device-mapper: resume ioctl on loop1p1 failed: Invalid argument
create/reload failed on loop1p1
add map loop1p1 (0:0): 0 1573349376 linear /dev/loop1 2048
device-mapper: resume ioctl on loop1p2 failed: Invalid argument
create/reload failed on loop1p2
add map loop1p2 (0:0): 0 1036548096 linear /dev/loop1 838862848

sudo kpartx -av /dev/loop2
add map loop2p1 (253:0): 0 1046528 linear /dev/loop2 2048

sudo kpartx -av /dev/loop3
device-mapper: resume ioctl on loop3p1 failed: Invalid argument
create/reload failed on loop3p1
add map loop3p1 (0:0): 0 1875415040 linear /dev/loop3 2048

sudo kpartx -av /dev/loop4
device-mapper: resume ioctl on loop4p1 failed: Invalid argument
create/reload failed on loop4p1
add map loop4p1 (0:0): 0 838860800 linear /dev/loop4 2048
device-mapper: resume ioctl on loop4p2 failed: Invalid argument
create/reload failed on loop4p2
add map loop4p2 (0:0): 0 1036548096 linear /dev/loop4 838862848

There's something device-mapper doesn't like about this situation.

dmsetup is only aware of the one partition on loop2:

sudo dmsetup info
Name:              loop2p1
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: part1-loop2

/dev/mapper contains only "control" and "loop2p1"

I suspect the problem with kpartx is also that it doesn't understand RAID well. It can't take multiple images or block devices as input to create a device map, so it doesn't see multiple devices or images as a single RAID array..

Is there a solution by using dmsetup directly?

What I would do with dmsetup if it were possible:
1. create a new, empty device in /dev/mapper
2. add each partition from /dev/loop{1,2,3,4} to the device map, manually specifying their ranges and positions within the RAID

Nothing in dmsetup's manual nor any guides I've found on google lead me to believe this can be done.....

Last edited by quequotion (2015-01-22 07:23:13)

Arch Linux

#1 2015-01-22 03:34:02

ZombieRAID: virtualized raid recovery

#2 2015-01-22 04:08:01

Re: ZombieRAID: virtualized raid recovery

Board footer