Unable to mount raid on the NAS, trying to rescue the data, how should I proceed

mdadmmountraid

A short backstory: something happened on my Synology NAS, apparently a buggy mailserver program that came with an update stopped the device from seeing the 2x3TB drives I have. After a lot of searching and a trying a lot of different solutions I eventually got the drives to show up again but they would not mount. After struggling, I figured that, because it was set up as a mirror, I could format one drive, mount it and perform the recovery on the other.

EDIT: I had it wrong and was trying to mount the wrong disk (not used to messing around with raid), however, I'm still unable to mount the correct disk, sda

$ file -s /dev/sda1
/dev/sda1: data

$ mount -t ext4 /dev/sda1 /mnt               
mount: mounting /dev/sda1 on /mnt failed: Invalid argument

Further Info

$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,barrier=0,journal_checksum,data=ordered 0 0
/proc /proc proc rw,relatime 0 0
/tmp /tmp tmpfs rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=4,mode=620 0 0
/sys /sys sysfs rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/vg1000/lv /volume1 ext4 rw,relatime,synoacl,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0
/dev/vg1000/lv /opt ext4 rw,relatime,synoacl,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0

Best Answer

This is an attempt to summarize from the chat troubleshooting session.

The setup turns out to be physical disk -> mdraid raid1 -> LVM. So there are several layers to work through. The old setup was (due to unfortunate prior recovery efforts) not available.

However, the NAS gui had been used to create another volume on a different disk, and thankfully the GUI created the new volume exactly the same way. So it was possible to discover the setup from the new disk:

mdadm -E new-disk provided the offset to the start of the data, under the mdraid layer (2048 sectors).
dmsetup table provided the start block of the logical volume (relative to the start of the physical volume) (1152 sectors)
There is a magic number (0x53ef) in the third sector of an ext4 volume. Using dd and xxd, we verified that the magic number is present at that offset on the disk we're trying to recover data from.

Armed with the start sector of the ext4 filesystem, you can use a read-only loop device to recover the data:

# losetup /dev/loop0 -o $((512*(1152+2048))) -r /dev/sda1
# mount -text4 -o ro /dev/loop0 /mnt

And then copy it off.

lsof

The only way I can think to gain access to a mount such as this would be to mount it as you did before using Nautilus or whatever file browser, and then using a tool such as lsof to see what files/devices are opened by Nautilus.

$ lsof -p $(pgrep nautilus)

But if you're having to connect to your phone via gphoto2 then you're likely not mounting the device a a mass storage device but rather a PTP - Picture Transfer Protocol. There's a Linux FUSE implementation for PTP too.

gvfs?

I would also look in your $HOME directory for a sub-directory called .gvfs. Usually when GNOME or Nautilus are doing the mounting this directory is created as a convenience.

In newer versions of GNOME (3+) this directory has moved and is now here, /run/user/$UID/gvfs.

Example

$ ls -l /run/user/$UID/gvfs/smb-share\:server\=tank\,share\=t 
total 2
drwx------. 1 saml saml    0 Oct 31 09:16 Development
drwx------. 1 saml saml    0 Nov 18 14:52 home
drwx------. 1 saml saml    0 May 14  2013 incoming
...

NOTE: That's a environment variable $UID that is often set in Bash on most modern systems. If it isn't set you can find your user's ID like so:

$ id
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

mdadm – Rebuilding IMSM RAID-0 Array from Disk Images Using mdadm

Looking at the partition table for /dev/loop0 and the disk image sizes reported for /dev/loop0 and /dev/loop1, I'm inclined to suggest that the two disks were simply bolted together and then the partition table was built for the resulting virtual disk:

Disk /dev/loop0: 298.1 GiB, 320072933376 bytes, 625142448 sectors

Device       Boot   Start        End    Sectors   Size Id Type
/dev/loop0p1 *       2048    4196351    4194304     2G  7 HPFS/NTFS/exFAT
/dev/loop0p2      4196352 1250273279 1246076928 594.2G  7 HPFS/NTFS/exFAT

and

Disk /dev/loop1: 298.1 GiB, 320072933376 bytes, 625142448 sectors

If we take the two disks at 298.1 GiB and 298.1 GiB we get 596.2 GiB total. If we then take the sizes of the two partitions 2G + 594.2G we also get 596.2 GiB. (This assumes the "G" indicates GiB.)

You have already warned that you cannot get mdadm to recognise the superblock information, so purely on the basis of the disk partition labels I would attempt to build the array like this:

mdadm --build /dev/md0 --raid-devices=2 --level=0 --chunk=128 /dev/loop0 /dev/loop1
cat /proc/mdstat

I have a chunk size of 128KiB to match the chunk size described by the metadata still present on the disks.

If that works you can then proceed to access the partition in the resulting RAID0.

ld=$(losetup --show --find --offset=$((4196352*512)) /dev/md0)
echo loop device is $ld
mkdir -p /mnt/dsk
mount -t ntfs -o ro $ld /mnt/dsk

We already have a couple of loop devices in use, so I've avoided assuming the name of the next free loop device and instead asked the losetup command to tell me the one it's used; this is put into $ld. The offset of 4196532 sectors (each of 512 bytes) corresponds to the offset into the image of the second partition. We could equally have omitted the offset from the losetup command and added it to the mount options.

Best Answer

Related Solutions

How to mount a filesystem from a given USB bus:device

lsof

gvfs?

Example

mdadm – Rebuilding IMSM RAID-0 Array from Disk Images Using mdadm

Related Question