Recover a single drive from an abandoned RAID 1 mirrored pair
Like most folks who’ve been in tech for a couple of decades, I’ve accumulated my fair share of obsolete equipment. I normally either find new homes for old hardware or have it responsibly recycled but, for peace of mind, I always shuck the hard drives first and promise to myself to “deal with them later”. “Later” never seems to happen and during a recent home-office tidy I discovered I’d been hoarding 11 hard drives of various flavours and vintages. Most of these drives were simply pulled from laptops or external drive caddies so mounting them, backing up any extant data and securely erasing them is a simple affair within any reasonably modern Debian install. One of the drives was pulled from an old Synology DS210j NAS however.
The drives in the DS210j had been set up as a mirrored pair for resiliency. I’ve always understood that to mean that a full, identical, copy of the data was made to both disks, but I’ve never poked under the hood to see how that worked. Can one drive be mounted as if it was always just a single disk? How much of the RAID array’s state has been lost by pulling the drive and getting rid of the NAS? Is there even anything left to recover and erase?
Here’s the steps I went through to enumerate and mount the data partition from a single drive that was once part of a RAID 1 mirrored pair.
I use this USB-SATA adapter from StarTech to connect old drives to my computer since it comes with an external power supply, so it should support even the beefiest 3.5″ spinning metal HDDs without dropping out. Connecting the drive and adaptor to the PC reveals the following logs.
$ sudo journalctl --catalog --pager-end --follow
# [...]
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: new high-speed USB device number 8 using ehci-platform
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: New USB device found, idVendor=174c, idProduct=235c, bcdDevice= 1.00
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: Product: USB 3.0 Destop HD EP0 Product string
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: Manufacturer: ASMT
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: SerialNumber: 0000000000B8
Jul 02 12:56:06 dev-box kernel: scsi host1: uas
Jul 02 12:56:06 dev-box kernel: scsi 1:0:0:0: Direct-Access ASMT USB 3.0 Destop H 0 PQ: 0 ANSI: 6
Jul 02 12:56:06 dev-box kernel: sd 1:0:0:0: [sdb] Spinning up disk...
Jul 02 12:56:18 dev-box kernel: ............ready
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes
Jul 02 12:56:18 dev-box kernel: sdb: sdb1 sdb2 sdb3
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
# [...]
We can see that Debian’s picked up the new USB device and set up our drive under /dev/sdb with three partitions /dev/sdb[1-3]. We can then use fdisk to inspect the partition table and try to see what each partition is for.
$ sudo fdisk /dev/sdb
# [...]
Command (m for help): p
# [...]
Device Boot Start End Sectors Size Id Type
/dev/sdb1 63 4980149 4980087 2.4G fd Linux raid autodetect
/dev/sdb2 4980150 6024374 1044225 509.9M fd Linux raid autodetect
/dev/sdb3 6281415 1953520064 1947238650 928.5G fd Linux raid autodetect
# [...]
Command (m for help): q
It looks like /dev/sdb3 is likely to be our data partition since it takes up >90% of the total space on the drive. We can try to mount that partition to take a look at any remaining files, but Linux won’t mount a RAID member directly.
$ sudo mount /dev/sdb1 /mnt
mount: /mnt: unknown filesystem type 'linux_raid_member'.
dmesg(1) may have more information after failed mount system call.
Referring to an old datasheet for the Synology, it looks like the only file system it supported was EXT3, so we should be able safe enough to assume that’s what’s actually on that partition.
We can go back in to fdisk to change the partition’s type from raid member to regular linux partition. That involves changing it’s ID from FD to 83.
$ sudo fdisk /dev/sdb
Command (m for help): t
Partition number (1-3, default 3): 3
Hex code or alias (type L to list all): L
#[...]
Aliases:
linux - 83
#[...]
raid - FD
#[...]
Hex code or alias (type L to list all): 83
Changed type of partition 'Linux raid autodetect' to 'Linux'.
Command (m for help): w
Unfortunately, that doesn’t seem to work. There must be some other data encoded within the partition table or filesystem referring back to the old format ID so it won’t automatically mount the partition.
$ sudo mount /dev/sdb3 /mnt
mount: /mnt: unknown filesystem type 'linux_raid_member'.
dmesg(1) may have more information after failed mount system call.
At this point I’m still pretty sure that the partition is really just ext3 under the covers, so it should be possible to mount it by specifiying the filesystem type explicitly in the mount command. We can use ext4 for this on a modern computer as there’s a good degree of forward and backward compatibility between the two filesystems.
$ sudo mount --types ext4 /dev/sdb3 /mnt
Running that mount command returned no errors, so to double check we can ask the system for a list of it’s currently mounted partitions and see how it’s getting on.
$ mount
[...]
/dev/sdb3 on /mnt type ext4 (rw,relatime)
That looks promising, we might be on to something. The next step is to see if there any files available under the mountpoint to prove we’ve really attached the partition properly.
$ ls --all -l --human-readable /mnt
[...]
-rw------- 1 root root 6.0K May 3 2014 aquota.group
-rw------- 1 root root 8.0K May 1 2014 aquota.user
drwx------ 2 root root 4.0K Jun 4 2014 @autoupdate
drwxr-xr-x 7 root root 4.0K Apr 14 2014 @download
[...]
Bingo! A whole list of files with a reasonably appropriate date have been found on the drive. Now I can back up anything that I still need a copy of, erase the disk when I’m done, and reflect on the fact that this drive has been in my to-do pile for a decade. Oops.
2024-07-10