7
0
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 withunknown filesystem type 'isw_raid_member'
mount -t
with NTFS and exFAT: Unable to find file systemmount /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 1970mdadm -E /dev/loop[12]
: States that no md superblock was detected on/dev/loop1
and prints out the partitions and MBR magic number ofaa55
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?
Please let me know if this should go on a different SE site. I considered Server Fault, but this seemed like it could happen in non-business settings, so I chose here. – awksp – 2016-08-19T14:49:43.563
As far as I can tell LOOP2 is the 1st disk from the laptop and LOOP1 the 2nd disk. Looks like the laptop only had disk 1. Disk 2 was added and (guessing now) both disks were changed to dynamic disks in Windows. Then C: and D: where extended with space allocated on the 2nd disk. I don't know if there is any way to make sense of this from within Linux. If possible I would place the disks back in the original laptop (or one that is very similar) and boot into Windows. Copy the data from there. Keep the images you made to fall back to a pristine start situation in case Windows trashes the disks. – Tonny – 2016-08-19T15:00:25.470
@Tonny Your guess sounds reasonable. I was hoping to work with the images and use the disks as originals, but now that you mention it the other way works too. Only thing I would be concerned about is the bad sectors on the 2nd disk. IIRC
dd
errored out due to those sectors around 10GB in, but everything else was fine. Would that interfere with restoring the disk with the image? – awksp – 2016-08-19T18:14:49.503Putting the image back to the same disk is probably not a very good idea. Writing to that disk may even make it worse. (If you see bad sectors the disk has already used up all its spare sectors. It is beyond dead already.) Just get another disk of same size or slightly bigger. I would recommend NOT to let Windows chkdsk the system on 1st boot, but just boot and copy data. After that is done let it chkdsk and see if you can then recover more data. – Tonny – 2016-08-19T20:02:17.440
@Tonny Right, you have a point. I don't think we have any 2.5" drives or USB adapters sitting around, so if other methods fail I'll go down to the local computer store and try what you suggested. – awksp – 2016-08-19T20:48:31.240
@KamilMaciorowski The
mount
commands fail withunknown filesystem type 'isw_raid_member'
, unfortunately. – awksp – 2016-08-19T20:55:49.107@awksp How about forcing NTFS by adding
-t ntfs
option to thosemount
commands? – Kamil Maciorowski – 2016-08-19T21:19:58.260@KamilMaciorowski Pasted the full results to the bottom of the question. The summary is that
mount
seems to be trying to access/dev/loop3
and failing. – awksp – 2016-08-19T21:47:19.243@KamilMaciorowski Holy moly that's complex. It's going to be a bit until I can try this, though; the server on which the images reside isn't visible from outside the office. – awksp – 2016-08-20T01:54:52.553
@KamilMaciorowski Changed comment chain into edit to bottom of question. tl;dr:
dmsetup
succeeds, but can't figure out how to mount anything, even with anoffset
argument – awksp – 2016-08-21T19:52:29.600@awksp It looks like this is a wrong way then. I'm sorry I couldn't help. – Kamil Maciorowski – 2016-08-21T20:04:58.813
@KamilMaciorowski :( That's too bad... Thank you for your help though! – awksp – 2016-08-21T20:18:26.010
@awksp Check this. Looks like
– Kamil Maciorowski – 2016-08-22T12:48:09.467dmraid
may be useful to you. It's just a clue, a lead. I thinkisw_raid_member
indicates Intel Software RAID. Do research.Idea out of left field: Have you tried to start a windows VM and thrown copies of two images at it to see if M$ magic can just figure it out, then samba it out? – Peter Berbec – 2017-10-02T18:12:22.590
@PeterBerbec That's a intriguing idea. Unfortunately, I don't have easy access to the images at the moment, but I'll give that a shot next time I do – awksp – 2017-10-28T08:07:12.087
@KamilMaciorowski idk if you're still around, but I was trying your instructions again and I actually managed to get the thing to mount! Only difference was I used a different number of sectors (19553531904 instead of 1953546336) and a
chunk_size
of 256. Not sure what exactly I did differently this time, but I'm just glad it worked. Post an answer, and I'll accept! – awksp – 2018-07-16T20:34:19.430@KamilMaciorowski Also, consider posting an answer here; this guy seems to have a similar issue. He seems to have found a workaround, but posting a proper answer hopefully wouldn't hurt
– awksp – 2018-07-16T20:35:23.317@KamilMaciorowski And looks like your original number of sectors works too (and is actually more correct, because I can actually mount the 4th partition this way). Not sure why things didn't appear to work earlier – awksp – 2018-07-16T21:04:29.880
@KamilMaciorowski Done! Sorry it took so long – awksp – 2018-10-25T18:49:12.200