Mount QNAP Drives to Linux

[PlanetMan]

So my TS-463XU has opted to have a catastrophic failure (seems it's the mainboard). Such is life, I'm organising a replacement etc.

In the meantime, I have migrated my disks over to a Debain 9 Linux install. My hope is to run them off there for the time it takes to replace this NAS. While I do have backups and could recreate the entire system, it will be much faster if I can simply access the drives and then place them back into the replacement NAS when it arrives (backups are in the cloud and downloading ~10TB is sort of a last resort).

Problem is I don't really know how to go about that, I've never really dealt with RAID in linux before (RAID5 to be specific).

So details of the disks:

Config: RAID5
Disks: 4 x 4GB WD Reds
Volumes: 3, 2 of which are encrypted (including the QNAP system volume). I have all the keys etc.

So far I've placed the disks, verified they are showing up and run

Code: Select all

mdadm --assemble --scan

Which seems to have set things up as follow:

Code: Select all

ARRAY /dev/md/9  metadata=1.0 UUID=4f1392fe:205d1388:2ee37ff0:6c9f711f name=9
ARRAY /dev/md/256  metadata=1.0 UUID=4bd64e50:23649b90:da72490f:4f182922 name=256
   spares=2
ARRAY /dev/md/1  metadata=1.0 UUID=73e6744e:c55665db:f80aae53:8936f821 name=1
ARRAY /dev/md/13  metadata=1.0 UUID=263694db:13117506:f3deb6a9:2f3c6ca2 name=13
ARRAY /dev/md/322  metadata=1.0 UUID=0b1a2093:81d786bb:6fefa7d8:0eca4008 name=322
   spares=2

I'm not sure that's right, as there should be 4 disks in RAID5 which would have a single spare. Instead there's 5 devices and two spares which doesn't seem right to me.

Running fdisk -l I can see the following volume:

Code: Select all

Disk /dev/md1: 10.9 TiB, 11971778838528 bytes, 23382380544 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1572864 bytes

Which seems accurate enough, however I cannot mount it and get the following error:

Code: Select all

root@raid01:~# mount /dev/md1 /mnt/test
mount: unknown filesystem type 'drbd'

I've looked into drbd and it seems rather complex.. I was under the impression that QNAP devices were basically just running the standard linux RAID setup and migrating would be fairly simple. Have I missed something?

Any guidance appreciated.

[MrVideo]

QNAP runs LVM with their RAID. If you manage to get a Linux box to mount a RAID5, I believe you'll be the first.

[PlanetMan]

Thanks for the info, how would I go about accessing the files then?

I mean from what I can tell, the RAID array is mounted. This all seems to be correct.

Code: Select all

root@raid01:~# mdadm -D /dev/md1
/dev/md1:
        Version : 1.0
  Creation Time : Fri Aug 17 15:35:15 2018
     Raid Level : raid5
     Array Size : 11691190272 (11149.59 GiB 11971.78 GB)
  Used Dev Size : 3897063424 (3716.53 GiB 3990.59 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sat Sep 15 00:39:56 2018
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : 1
           UUID : 73e6744e:c55665db:f80aae53:8936f821
         Events : 8352

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       1       8       51        1      active sync   /dev/sdd3
       2       8       35        2      active sync   /dev/sdc3
       3       8       19        3      active sync   /dev/sdb3

So well.. there's the array. I'm just not sure how to go about actually accessing it.

[MrVideo]

Like I said, LVM (Logical Volume Management) is involved.

[Mousetick]

Run these commands (they're safe to use) and post the output:

Code: Select all

# modprobe drdb
# cat /proc/drdb
# ls -l /dev/drdb*
# which pvscan

They won't mount anything. This is just for testing the waters, before possible next steps.

[PlanetMan]

Code: Select all

root@raid01:~# modprobe drbd

root@raid01:~# cat /proc/drbd
version: 8.4.7 (api:1/proto:86-101)
srcversion: 0904DF2CCF7283ACE07D07A

root@raid01:~# ls -l /dev/drbd*
ls: cannot access '/dev/drbd*': No such file or directory

root@raid01:~# which pvscan
/sbin/pvscan

OS is debian 9 if I didn't mention it.

[Mousetick]

Sorry for the typos (drdb vs. drbd).

It's more complicated than I thought.

Install drbd-utils:

Code: Select all

# apt-get install drbd8-utils

There should be a directory at /etc/drbd.d.
Create a text file named r1.res in /etc/drbd.d, with the following contents. Replace 'localhost' with the actual hostname of the Debian machine.

Code: Select all

resource r1
{
    syncer
    {
        rate 4G;
    }
    on localhost
    {
        device /dev/drbd1;
        disk /dev/md1;
        meta-disk internal;
        address 127.0.0.1:7789;
    }
    on FakeHost
    {
        device /dev/drbd1;
        disk /dev/md1;
        meta-disk internal;
        address 1.1.1.1:7789;
    }
}

Then run these and post the output

Code: Select all

# modprobe drbd
# drbdadm up r1
# drbd-overview
# cat /proc/drbd
# ls -l /dev/drbd*

[storageman]

I agree with MrVideo but sure, try if you like.
We'd be interested to know if possible.

[PlanetMan]

Thanks for the reply . Also, I have no idea why, but the array is now "md127" instead of "md1". Haven't so much as rebooted the machine so no clue what the go is there.

Code: Select all

resource r1
{
    syncer
    {
        rate 4G;
    }
    on raid01
    {
        device /dev/drbd1;
        disk /dev/md127;
        meta-disk internal;
        address 127.0.0.1:7789;
    }
    on FakeHost
    {
        device /dev/drbd1;
        disk /dev/md127;
        meta-disk internal;
        address 1.1.1.1:7789;
    }
}

Code: Select all

root@raid01:/etc/drbd.d# modprobe drbd

root@raid01:/etc/drbd.d# drbdadm up r1
strange bm_offset -6208 (expected: -5640)
No valid meta data found
Command 'drbdmeta 1 v08 /dev/md127 internal apply-al' terminated with exit code 255

root@raid01:/etc/drbd.d# drbd-overview
 1:r1/0  . . .

root@raid01:/etc/drbd.d# cat /proc/drbd
version: 8.4.7 (api:1/proto:86-101)
srcversion: 0904DF2CCF7283ACE07D07A

 1: cs:Unconfigured

root@raid01:/etc/drbd.d# ls -l /dev/drbd*
brw-rw---- 1 root disk 147, 1 Sep 18 09:51 /dev/drbd1

/dev/drbd:
total 0
drwxr-xr-x 2 root root 60 Sep 18 09:51 by-disk
drwxr-xr-x 2 root root 60 Sep 18 09:51 by-res

I'm starting to get a sneaking suspicion that QNAP have vendor locked their arrays in some manner...

[Mousetick]

I'm starting to get a sneaking suspicion that QNAP have vendor locked their arrays in some manner...

Yep that's quite possible given that QNAP maintains their own fork of the Linux kernel (https://sourceforge.net/projects/qosgpl/).

Looks like someone else ran into the exact same issue: http://lists.linbit.com/pipermail/drbd- ... 24106.html. And got no answer.

I'm out of ideas, sorry. Without a valid drbd device no further progress is possible. The next step would have been to map the LVM volumes off the drbd device.

[PlanetMan]

Yeah, I'm done with them entirely, moving to Synology (with whom restoration is simple and easy, with a KB on their website). I just got my ticket back saying "too bad get a new QNAP". Instead it's getting refunded, I'm buying a Synology and never using them again. I'll rebuild from backups.

Really appreciate your help though, much appreciated!

[storageman]

Yeah, I'm done with them entirely, moving to Synology (with whom restoration is simple and easy, with a KB on their website). I just got my ticket back saying "too bad get a new QNAP". Instead it's getting refunded, I'm buying a Synology and never using them again. I'll rebuild from backups.

Really appreciate your help though, much appreciated!

It's a strange reason to move, no one should be worried about needing to read disks like this if they keep backups.

I could list you all the things Qnap do better than Synology, like snapshots, encryption, tiering, block LUNs (Syno are thin) etc, etc but haven't time.

[dolbyman]

drive recovery should not be part of any backup plan

[storageman]

drive recovery should not be part of any backup plan

Agreed, a bit of an uncalled for rant.

[dolbyman]

nope...if you had external backups, you'd noticed that those are readable with ease ..plain ntfs for instance ..works fine in any system