Mount QNAP Drives to Linux

[S.Haran]

Well file says there is a PV on md100 but lvdisplay and pvscan show nothing. Where before the reboot they did. So something changed. The only thing I see wrong is that you tried to use the LV Path device name as the mount point.

Code: Select all

root@odroid:~# sudo mount /mnt/old_hdd /dev/vg1/lv1

What you wanted was...

Code: Select all

sudo mount /dev/vg1/lv1 /mnt/old_hdd

At this point I would still do a scan for the data partition. If you scroll back in this thread for Niemand_01's posting you can see he used r-explorer as an alternative to testdisk to find the data partition offset to mount with. That may be faster.

BTW what is the model name of this QNAP?

[Undesirable]

Well file says there is a PV on md100 but lvdisplay and pvscan show nothing. Where before the reboot they did. So something changed. The only thing I see wrong is that you tried to use the LV Path device name as the mount point.

Code: Select all

root@odroid:~# sudo mount /mnt/old_hdd /dev/vg1/lv1

What you wanted was...

Code: Select all

sudo mount /dev/vg1/lv1 /mnt/old_hdd

At this point I would still do a scan for the data partition. If you scroll back in this thread for Niemand_01's posting you can see he used r-explorer as an alternative to testdisk to find the data partition offset to mount with. That may be faster.

BTW what is the model name of this QNAP?

I actually tested it the other way around before the reboot and it said (I copied the entire SSH session to a text file):

Code: Select all

root@odroid:~# mount /dev/vg1/lv1 /mnt/old_hdd
mount: /mnt/old_hdd: special device /dev/vg1/lv1 does not exist.

After I had tried that a few times, as well as the other way around as the guide on page 2 suggested, I stopped the md device with:

Code: Select all

root@odroid:~# sudo mdadm -S /dev/md100
mdadm: stopped /dev/md100

Before rebooting. I did not perform any other commands and as far as I can tell I never modified any data on the drive. The model name of the NAS was TS-253A.

[S.Haran]

Before the mount attempt did you activate the LV with...

Code: Select all

 vgchange -ay

[Undesirable]

Before the mount attempt did you activate the LV with...

Code: Select all

 vgchange -ay

I did not, because it wasn't in the instructions.

I just tried to use testdisk, and it showed up as an LVM volume there, but all I can appear to do is make an image of it. I can't browse the files like I can with EXT3 partitions. If I make an image, it'll probably come out as unreadable LVM data, won't it?

[S.Haran]

An image won't help. Do a deep search with testdisk.

[Undesirable]

An image won't help. Do a deep search with testdisk.

Okay, thanks a lot for your help. I'll have to continue tomorrow.

[fredrogers]

Raid5 for home users in my opinion is just the shortest path to data disaster.

Great insight! I wish these NAS vendors would warn people that data recovery is probably going to be impossible, before they configure their units using advanced RAID setups. I will continue to use RAID-1 only, thank you.

[dolbyman]

the vendors give you free choice....you go ahead with your raid1 in multibay systems ...smh

[Undesirable]

Before the mount attempt did you activate the LV with...

Code: Select all

 vgchange -ay

I had another attempt at this, and it seems that I cannot use the lv tools unless it is from a fresh installation; i.e. if lvm2 is currently installed on boot then I have to uninstall and reinstall it in the same session to be able to see my partition / data in the tools. When I did this and then used S.Haran's suggested command: "sudo vgchange -ay" then I was finally successful in being able to mount a readable EXT4 partition in the operating system. So I am very grateful to you S.Haran and philippelt for assisting me in recovering my data.

It seems there are a few more hoops to jump through to get this working with the latest versions of everything, including stopping some unreadable RAID devices when mdadm is installed (and probably every time you want to come back to read more data from the drive), otherwise each and every partition is 'busy' when you try to do anything with it. However, I got there in the end. Thanks again.

[SimmoF]

I also had the problem that my NAS died with a hardware failure.

What worked for me was using the program r-explorer: https://www.r-explorer.com/#ourproducts

This program manages to read through the full QNAP software stack mdadm -> drbd -> lvm -> ext4 in my case

Since I did not want to pay the licence fee, I used the following workaround. The Program displays the sector offset of the device and the sector size use this to do a mount command:

Code: Select all

sudo mount -o offset=109710872576 /dev/sda /mnt/

Where you need to change the offset to the value you computed and the device to the device of your hdd.

A different option to get the correct offset is the program 'testdisk'. But this would take quite long so I could not test this, yet.

This worked for me. Don't forget to multiply the offset by the sector size to get the correct value.
109710872576 also happened to be the correct offset for me.

[autolux]

Any ideas how I might go about recovery from a 4x8TB RAID10 setup?

[dolbyman]

without infos (nas model/volume type /etc) no help possible

[autolux]

TS-453B, current QTS version. RAID10 Thin provisioned (im pretty sure)...

NAS motherboard failure i believe, doesnt even post. So all I have is the 4x8TTB drives that should work fine in another QNAP, which i don't have. I'd prefer to wait for the x53D series.

Any suggestions how to proceed, or if this would be possible by putting the drives in a linux server please let me know... (instructions in this thread as far as i can tell, seem to require the drive is 'safely removed' from the raid under QTS)..

[S.Haran]

A Linux based recovery is definitely worth a try... viewtopic.php?f=25&t=143408&start=15#p702846

Post back if you get stuck or need more help. Safe removal is good if it is possible to do so. But not a strict requirement for data recovery.

[tgsbn]

Raid5 for home users in my opinion is just the shortest path to data disaster.

Great insight! I wish these NAS vendors would warn people that data recovery is probably going to be impossible, before they configure their units using advanced RAID setups.

I don't agree.
You should never count on data recovery from the salvaged disks of a defect NAS, no matter which RAID level.
The only reliable way of recovering from a NAS defect is to restore your last backup.
Data recovery from a failed RAID or from failed disks in general is always only a risky attempt to reduce the size of desaster should your backups turn out to be unusable or (shame on you) non-existent.

So the warning NAS vendors should really give is:

• Do regular backups!

• RAID is not a backup.

• RAID only protects against disk failures.

• RAID does not protect against other hardware failures.

• RAID does not protect against operating errors.

• RAID does not protect against malicious acts.

• Do regular backups!

That's not to say we shouldn't try to help fellow QNAP users who for whatever reason face the need to attempt a data recovery.
But when it comes to general warnings and recommendations, a good backup strategy that avoids the need for data recovery in the first place is much more important than adapting your RAID configuration to make data recovery easier.