How do I mount a multi-disk Windows NTFS RAID/logical drive on Linux?

Question

I have two 500GB hard drives from an old Windows laptop at my workplace. My boss has asked me to copy the contents to the file server if possible, with the caveat that absolutely no data may be lost.

Normally, backups would suffice for this, but this was from the earlier days of the operation when stuff like backups weren't kept more strictly, and this guy was notoriously poorly organized, so I'm not sure whether the backups have the most up-to-date (or even reasonably up-to-date) contents.

---

First thing I did was to produce images using ddrescue. The drive that has the partition table copied without errors, and the other drive lost ~150 KiB to errors. The images were mounted read-only to /dev/loop1 and /dev/loop2 using losetup. fdisk -l shows the following:

Disk /dev/loop1: 465.8 GiB, 500107862016 bytes, 976773168 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 /dev/loop2: 465.8 GiB, 500107862016 bytes, 976773168 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: 0x87afa6ad

Device       Boot      Start        End    Sectors   Size Id Type
/dev/loop2p1            2048   31459327   31457280    15G 27 Hidden NTFS WinRE
/dev/loop2p2 *      31459328   31664127     204800   100M 27 Hidden NTFS WinRE
/dev/loop2p3        31664128 1191071167 1159407040 552.9G  7 HPFS/NTFS/exFAT
/dev/loop2p4      1191071168 1953533951  762462784 363.6G  7 HPFS/NTFS/exFAT

The partition sizes seemed to suggest that this was a RAID array or Windows logical drive, and a quick check with blkid showed that the drive types were isw_raid_member. Attempting to assemble the array with mdadm -v --assemble /dev/md0 /dev/loop2 /dev/loop1 produced the following output:

mdadm: looking for devices for /dev/md0
mdadm: Cannot assemble mbr metadata on /dev/loop2
mdadm: /dev/loop2 has no superblock - assembly aborted

Other things I tried either to mount the drives or get more information were:

• mount /dev/loop2 <mount point>: Failed with unknown filesystem type 'isw_raid_member'
• mount -t with NTFS and exFAT: Unable to find file system
• mount /dev/loop2p[1234]: Special device <dev> does not exist
• mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/loop[21]: States that /dev/loop2 appears to be part of a raid 0 array with no devices and a creation date of 00:00:00 Jan 1 1970
• mdadm -E /dev/loop[12]: States that no md superblock was detected on /dev/loop1 and prints out the partitions and MBR magic number of aa55 for /dev/loop2
• file -s /dev/loop1: prints /dev/loop1: data
• file -s /dev/loop2: spits out a block of text basically saying it's a DOS/MBR boot sector and the gives raw numbers for partition offsets/sizes.

• mount -t ntfs -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1:

  NTFS signature is missing
  Failed to mount '/dev/loop3': Invalid argument
  The device '/dev/loop3' doesn't seem to have a valid NTFS
  

  No, I didn't mistype that 3. No clue where it came from.

I also looked at Recovering a failed software RAID, but that seems to be for already working Linux arrays being recovered on Linux (not to mention quite a bit goes over my head).

Is there anything I can do to get these images mounted safely?

Answer 1

_{Note: I'm writing this answer after the OP got help via comments, trials and errors. Having other users in mind, I'm making the answer broader and little more generic.}

---

If these two disks worked together, they might be

1. mirrored, RAID1-style;
2. or concatenated, JBOD-style;
3. or striped, RAID0-style.

The cases are ordered starting from the easiest to deal with. I will instruct you how to tell them apart and how to deal with them to mount the partitions eventually.

Mounting should be done with -o ro first, until you're sure you got it right. In some cases mount may succeed and give you access to mangled directory structure and/or scrambled files. Insane data and/or metadata indicate you didn't get it right. Mounting read-only ensures you won't harm the image(s).

---

1. mirrored, RAID1-style

In this case both disks should contain the same data, if healthy; they both should contain the same valid partition table. Only the image you have as /dev/loop2 reports a partition table. This may be because

• they were not mirrored in the first place,
• or these errors you mentioned on the other disks occurred where the partition table is (in case of DOS partition table it's MBR, i.e. at the very beginning, sector number 0).

There is however one big clue that makes RAID1 hardly probable in your case: fdisk says there are exactly 976773168 sectors on a single disk, but the last sector of the fourth partition is 1953533951. This is almost twice as much, it suggests the partition layout spawns on two non-mirrored disks.

But let's say your disks were twice as big and the above clue didn't apply. If you believe you may deal with mirrored disks then work with the image obtained without errors, leave the other image alone. Try to mount the partitions like this:

mount -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1
mount -o ro,offset=$((512*31459328)) /dev/loop2 /mnt/partition2
mount -o ro,offset=$((512*31664128)) /dev/loop2 /mnt/partition3

etc. You may even not use losetup to get /dev/loop2 but provide the file path directly, mount should create a loop device on its own and handle this just fine:

mount -o ro,offset=$((512*2048)) /path/to/the/image2.raw /mnt/partition1

---

2. concatenated, JBOD-style

If disks building JBOD use MBR to store the partition table, fdisk will find it only on the very first disk. Other disk(s) may report nothing or some insane partition table(s); the probability of getting a partition table that looks sane from not-the-first disk is very low, but even then this partition table means nothing.

If disks building JBOD use GPT to store the partition table, tools like gdisk will find the primary table on the very first disk, the secondary (backup) table on the very last one.

You have two images, one of them reports a DOS partition table (i.e. a partition table in MBR), the other reports no partition table. Should they create JBOD, you know the one corresponding to /dev/loop2 goes first.

In your case the partitions 1 and 2 are small enough to entirely fit into the first disk of JBOD. You can try to mount them with appropriate offset from the sole /dev/loop2. If this gives you access to sane filesystems then you will know JBOD is probably the right setup. To access all the partitions you need to concatenate images.

This answer of mine provides a way to concatenate images without writing the result to disk. In your case the procedure may be:

1. dmsetup create mydisk
2. type 0 976773168 linear /path/to/the/image2.raw 0 Enter
3. type 976773168 976773168 linear /path/to/the/image1.raw 0 Enter
4. hit Ctrl+D

The resulting device should be /dev/mapper/mydisk. Try to mount any partition from it with appropriate offset=….

To destroy the device invoke dmsetup remove mydisk.

---

3. striped, RAID0-style

Similarly to JBOD, if disks building RAID0 use MBR to store the partition table, fdisk will find it only on the very first disk. Other disk(s) may report nothing or some insane partition table(s); the probability of getting a partition table that looks sane from not-the-first disk is very low, but even then this partition table means nothing.

If disks building RAID0 use GPT to store the partition table, the situation gets complicated. Depending on how big the stripe size is, you may or may not get the primary partition table from the very first disk, you may or may not get the secondary (backup) partition table from the very last disk. You should get a legacy MBR from the very first disk (unless a read error occurs).

You have two images, one of them reports a DOS partition table (i.e. a partition table in MBR), the other reports no partition table. Should they create RAID0, you know the one corresponding to /dev/loop2 goes first. What you don't know is the stripe size. In general there is no firm way to know it, you should try common values and analyze the results.

The procedure to interleave your images and to create a virtual device is as follows:

1. dmsetup create mydisk
2. type 0 1953546336 striped 2 256 /dev/loop2 0 /dev/loop1 0 Enter
3. hit Ctrl+D

The resulting device should be /dev/mapper/mydisk. The number 256 means the stripe size of 128 KiB and it must be guessed right. In general, regardless of possible troubles with GPT before dmsetup, now gdisk -l /dev/mapper/mydisk should return a valid partition table if you guess the stripe size right. If you guess it wrong, the partition table may or may not be valid. If it looks valid, try to mount all the partitions from it with appropriate offset=… values.

In your case the partition table will certainly be the one you got from /dev/loop2.

Beware that even with a wrong guess you may be able to mount but the files will be scrambled. In this case umount, invoke dmsetup remove mydisk and repeat dmsetup create… with another value instead of 256. Numbers to try: 8, 16, 32, 64, 128, 256, maybe other powers of 2. If possible, read files with verifiable content (media like MP3, do they play without jitter?) or formal structure (like PDFs, do they open without errors?) to tell if your guess is right. Files smaller than the right stripe size may not show that your guess is wrong, so you should rather use an avi of 700 MB, not just a text file of few KB.

To destroy the device invoke dmsetup remove mydisk.