Other Rescue data from NAS drive

Hi forum
I'm trying to rescue some data from a drive that comes to me from a (failed ?) QNAP NAS device.
I belive the drive was part of a raid-1 setup. (I also have the second drive)
smartctl test=long completes without any obvious error/s.

gpart reports as follows :
Code:
=>        34  3907029101  da4  GPT  (1.8T)
          34           6       - free -  (3.0K)
          40     1060250    1  ms-basic-data  (518M)
     1060290           6       - free -  (3.0K)
     1060296     1060284    2  ms-basic-data  (518M)
     2120580           4       - free -  (2.0K)
     2120584  3887119526    3  ms-basic-data  (1.8T)
  3889240110           2       - free -  (1.0K)
  3889240112     1060288    4  ms-basic-data  (518M)
  3890300400           8       - free -  (4.0K)
  3890300408    16707592    5  ms-basic-data  (8.0G)
  3907008000       21135       - free -  (10M)
How to mount a "ms-basic-data" partition in FreeBSD ?
I assume the filesystem is NTFS, so tried the following, alas without success.
Code:
# ntfs-3g -o ro /dev/da4p3 /mnt/ntfs
NTFS signature is missing.
Failed to mount '/dev/da4p3': Invalid argument
The device '/dev/da4p3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Some blogs suggest QNAP uses ext4.
Would gpart detect ext4 and call it "ms-basic-data" ?

Thanks for any suggestions to try and do this the-right-way.

Edit.
# file -s /dev/da4p3
/dev/da4p3: LVM2 PV (Linux Logical Volume Manager), UUID: eOXcjy-Cd0D-ZeiP-v6Fm-9mMz-Tudi-wu5pjL, size: 1990204485632
 
According to gpart(8), the "ms-basic-data" partition type has the following meaning to gpart:

A basic data partition (BDP) for Microsoft operating
systems. In the GPT this type is the equivalent to partition
types fat16, fat32 and ntfs in MBR. This type is used for GPT
exFAT partitions. The scheme-specific type
is "!ebd0a0a2-b9e5-4433-87c0-68b6b72699c7" for GPT.

I think that means you have a series of exFAT partitions, on account of gpart saying the drive uses a GPT partitioning scheme.

I don't know how the NAS device's RAID controller might have affected its layout, though.
 
# file -s /dev/da4p3
/dev/da4p3: LVM2 PV (Linux Logical Volume Manager), UUID: eOXcjy-Cd0D-ZeiP-v6Fm-9mMz-Tudi-wu5pjL, size: 1990204485632

Does this mean the drive is not raid-1, and instead is part of an LVM partitioning scheme with data spread around across multiple physical drives ?
 
# file -s /dev/da4p3
/dev/da4p3: LVM2 PV (Linux Logical Volume Manager), UUID: eOXcjy-Cd0D-ZeiP-v6Fm-9mMz-Tudi-wu5pjL, size: 1990204485632

Does this mean the drive is not raid-1, and instead is part of an LVM partitioning scheme with data spread around across multiple physical drives ?

It can still have raid on top of lvm.
 
Does this mean the drive is not raid-1, and instead is part of an LVM partitioning scheme with data spread around across multiple physical drives ?
Or it could be a leg of LVM mirror (so no md device /raid device)/at all).

file can five you lots of false information too. If this partition was part of the LVM (type 83e00) I don't see a reason why wouldn't gpart show it as such ("linux-lvm").
This partition could also be part of the Windows raid (concated or mirrored).

You should know what FS is actually on that partition. My 2c: use native tools to given FS when attempting recovery. Don't try to use FreeBSD to recover NTFS data.

If this partition was part of some redundancy setup ("raid 1 alike") you should not have problems reading data. If it was raid0 you're done and need to restore from backup.

But then you didn't mention why you need to rescue data (what is the actual underlying problem and how you are detecting that problem).
 
What OS does a QNAP NAS run? Why don't you use that operating system to try to read this disk? Why are you making it artificially difficult for yourself?
 
What OS does a QNAP NAS run? Why don't you use that operating system to try to read this disk? Why are you making it artificially difficult for yourself?
My preference is to use FreeBSD, where practical. I don't use FreeBSD for punishment.
AFAIK, QNAP uses their own customised linux.
So, I can see I'm gonna need to spin up linux on some other hardwares.
 
Possibly:

"This type is used for GPT
exFAT partitions."

I think that means you have a series of exFAT partitions, on account of gpart saying the drive uses a GPT partitioning scheme.

You should know what FS is actually on that partition. My 2c: use native tools to given FS when attempting recovery. Don't try to use FreeBSD to recover NTFS data.

ntfs-3g said 'no valid ntfs signature', so that's unlikely.

Easy enough to ...

pkg install exfat-utils
pkg install fusefs-exfat

... to see if it is exFAT, and mount if so.

https://man.freebsd.org/cgi/man.cgi....0-RELEASE+and+Ports&arch=default&format=html
 
ntfs-3g said 'no valid ntfs signature', so that's unlikely.
True, and good point to raise.

That's why I mentioned what I mentioned above. For the sake of the data it would help us to known what the problem is, how it was detected and what fashion were these disks used.

So, I can see I'm gonna need to spin up linux on some other hardwares.
Yes, that's a good starting point. Especially if those disks use Linux-native tools (such as md raid, LVM..).

If you have enough space you could dd the disk to an image and mount that anywhere, even in VM. Possibly under FreeBSD (mdconfig), though I'd stick to Linux here (losetup and kpartx).
 
1/ - do not fight to mount the partition at any cost.
2/ - what exactly were the circumstances of the failure?
3/ - have you performed any disk diagnostics? At least provide its model.
4/ - you should protect the output state by making a binary copy (disk clone),
5/ - how is the partitioning of this disk seen by DMDE?
 
Back
Top