Score:0

Recovering a file by mounting a Synology RAID1 disk in Ubuntu (mount, mdadm, and losetup issues)

mx flag

I'm working with a Synology RAID1 system and deleted a file that wasn't yet backed up. To recover the file, and since an undelete approach seems to be impossible, my idea is to mount a single RAID1 disk in Ubuntu 20.04 LTS and search for it, but I'm having some trouble with it. An internet search brought me to two related Q&A's here; they are of older date though and didn't work in my case.

From lsblk:
sdb      8:16   0   5.5T  0 disk 
├─sdb1   8:17   0   2.4G  0 part 
├─sdb2   8:18   0     2G  0 part 
├─sdb5   8:21   0   2.7T  0 part 
└─sdb6   8:22   0   2.7T  0 part 
Attempt 1, usual mount attempt:

Usual mount doesn't recognize the file system.

# mount /dev/sdb1 /mnt/test/
mount: /mnt/test: unknown filesystem type 'linux_raid_member'.
Attempt 2 using mdadm (Ref)

When trying to apply the first solution, the superblock seems to be missing.

# mdadm --assemble --run /dev/md0 /dev/sdb1
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted
Attempt 3 using losetup (Ref)

However the issue persists even with the second solution.

# losetup /dev/loop18 /dev/sdb1 -o 1048576
# mount /dev/loop18 /mnt/test/
mount: /mnt/test: wrong fs type, bad option, bad superblock on 
 /dev/loop18, missing codepage or helper program, or other error.

Altogether this shows me I probably could need some help. Can anyone provide me with a working solution? Please note that the main goal is to recover the file, not necessarily in a specific way.

Edit

More outputs:

# file -s /dev/sdb?
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=ceb6a1e0-2bde-441f-97dc-db231fc51d41, volume name "1.41.12-1963" (extents) (large files) (huge files)
/dev/sdb2: Linux/i386 swap file (new style), version 1 (4K pages), size 524271 pages, no label, UUID=abbd2e2f-a7a4-4e5d-bd79-55908f8ff79d
/dev/sdb5: Linux Software RAID version 1.2 (1) UUID=a7c85951:8b8b7689:d4ad5498:e14c55d1 name=DiskStation:2 level=1 disks=2
/dev/sdb6: Linux Software RAID version 1.2 (1) UUID=69b042ac:84e2b185:501c0c3e:  c12533 name=WOTAN:3 level=1 disks=2
Michael Hampton avatar
cz flag
Now you can see which partitions are actually RAID array members. sdb1 appears to just be a plain ext4 flesystem.
jay.sf avatar
mx flag
@MichaelHampton Thanks, when I use the loop approach on sdb5 or sdb6 I get an `unknown filesystem type 'LVM2_member'`.
Michael Hampton avatar
cz flag
That's probably what's on it, then. Though I don't know why you did that instead of trying to assemble the array with a missing device. You'll probably have to in order to get to the LVM logical volumes.
jay.sf avatar
mx flag
@MichaelHampton You're right. The `mdadm` worked with the hint in [comment](https://serverfault.com/questions/383362/mount-unknown-filesystem-type-linux-raid-member?newreg=197ddc17e90e45f6a75b749b283fd543#). However `mdadm --assemble --run /dev/md0 /dev/sdb5` still gives `mount: /mnt/test: unknown filesystem type 'LVM2_member'.` Can we set a switch to assemble with missing disk somehow?
Michael Hampton avatar
cz flag
At that point the LVM logical volumes should be visible to the OS, so just do something like `vgchange -ay` to bring them in.
jay.sf avatar
mx flag
@MichaelHampton Seems `vgchange -ay --activationmode partial` brought me a step further. However `mnt/test` is empty, disk doesn't seem to be mounted and doesn't show up in `mount` output.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.