0

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
jay.sf
  • 101
  • 2
  • 1
    Now you can see which partitions are actually RAID array members. sdb1 appears to just be a plain ext4 flesystem. – Michael Hampton Sep 03 '21 at 18:07
  • @MichaelHampton Thanks, when I use the loop approach on sdb5 or sdb6 I get an `unknown filesystem type 'LVM2_member'`. – jay.sf Sep 03 '21 at 18:10
  • 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. – Michael Hampton Sep 03 '21 at 18:15
  • @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? – jay.sf Sep 03 '21 at 18:28
  • 1
    At that point the LVM logical volumes should be visible to the OS, so just do something like `vgchange -ay` to bring them in. – Michael Hampton Sep 03 '21 at 18:32
  • @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. – jay.sf Sep 03 '21 at 18:55

0 Answers0