Hello,
I hope someone can help me with this, or point me in the right direction.
I had an issue with my home NAS which runs UBUNTU as its base language, set up as JBOD array, 4 drives, 10TB
Because of the issue I had, I tried to interrogate the 'first' drive with a HDD docking device and inadvertently formatted the drive in GPT? Anyhow, it now shows up as NTFS which is not recognised in the server any longer and denying the rest of the drives being read in the JBOD array, due to the logical clamp being removed / destroyed?
I have not written to any of them, so am confident all the data is retrievable, as I'm now in recovery territory, but would like to know if there is anyway I can recover the mdadm structure, for the first drive only, so all four drives can be read as one JBOD array.
Is it possible to get rid of the NTFS partition tier and restore the original Linux partition, so I can employ the use of some RAID recovery software ?
I do not have any backups, but have another similar sized unit ready to dump anything on.
I have contacted CGsecurity, for TestDisk, who were great, but before I proceed with their advice, I'm hoping there is someone who might have some experience in this, being a Linux based drive?
I thankyou in anticipation...

Welcome to LinuxQuestions.

I've never played with a QNAP or JBOD but since no one has replied yet first is that it is not a RAID. There are no raid tools that will recover the files. If you did reformat the drive as NTFS there isn't a way to restore it to its original configuration.

As far as I know if you lose a disk the only way to recover the data without a backup is using testdisk. There is no redundancy.

Once you recover the data I suggest using RAID 1 or 5 but again it is not a backup.

1 members found this post helpful.

...!

You have advice from specialists in data recovery, but before you follow that you want advice from a forum which does not specialize in data recovery?

Why do you think anyone here will know more than what the experts have already told you - and why haven't you stated what the advice you already received was?

1 members found this post helpful.

It is safe to use testdisk/photorec to recover data if you follow the directions exactly.
Then I don't see any reason to keep the formatting if all the data has been recovered.

1 members found this post helpful.

Thanks to all who have shown interest in this thread.

Sorry, got this wrong, the advice I was given came from askumbuntu, who suggested I sift through the following website: https://raid.wiki.kernel.org/index.p...up#2._Assemble
Cgsecurity, using Testdisk will be where I will end up, however I thought I'd try to explore Linux a bit more, where the mdadm structure is concerned, to try and save me a lot of time and a world of pain it seems.
Are there any shortcuts to restore the original mdadm structure or any commands I can use to further analyse the drive ?

ubuntu@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 2.3G 1 loop /rofs
loop1 7:1 0 4K 1 loop /snap/bare/5
loop2 7:2 0 61.8M 1 loop /snap/core20/1169
loop3 7:3 0 150.4M 1 loop /snap/firefox/631
loop4 7:4 0 99.3M 1 loop /snap/core/11743
loop5 7:5 0 65.2M 1 loop /snap/gtk-common-themes/1519
loop6 7:6 0 242.3M 1 loop /snap/gnome-3-38-2004/76
loop7 7:7 0 54.2M 1 loop /snap/snap-store/557
sda 8:0 0 3.6T 0 disk
sdb 8:16 0 931.5G 0 disk
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part
sdd 8:48 0 14.6T 0 disk
├─sdd1 8:49 0 16M 0 part
└─sdd2 8:50 0 14.6T 0 part
sde 8:64 0 3.6T 0 disk
sdj 8:144 1 30G 0 disk
└─sdj1 8:145 1 30G 0 part /cdrom
sr0 11:0 1 1024M 0 rom
ubuntu@ubuntu:~$

BTW - sdd is my back up drive, so can do a clone or dump.

sdc1 should not be there, this is the NTFS partition, plus this should also be known as sda as it's the first drive and sda should be sdc.
Any more ideas, tests I can carry out to try and change this please?
Many thanks

Look at the output of the command

lsblk -f

That will show the filesystem type for your drives. It should should show them as linux_raid_member if they are actually part a mdadm RAID.

Thanks MK

This is what lsblk -f shows:-

dibbler@dibbler-HP-xw4600:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 4.0 0 100% /snap/core/11743
loop1 squashfs 4.0 0 100% /snap/bare/5
loop2 squashfs 4.0 0 100% /snap/core/11993
loop3 squashfs 4.0 0 100% /snap/core20/1242
loop4 squashfs 4.0 0 100% /snap/core20/1270
loop6 squashfs 4.0 0 100% /snap/firefox/747
loop7 squashfs 4.0 0 100% /snap/gnome-3-38-2004/76
loop8 squashfs 4.0 0 100% /snap/gnome-3-38-2004/87
loop9 squashfs 4.0 0 100% /snap/gtk-common-themes/1519
loop10 squashfs 4.0 0 100% /snap/snap-store/557
loop11 squashfs 4.0 0 100% /snap/snap-store/558
loop12 squashfs 4.0 0 100% /snap/firefox/767
sda
├─sda1 ntfs 845C4A705C4A5D54
└─sda2 ext4 1.0 8a7e41ef-7380-4066-95f5-2165c842731f 66.5G 13% /
sdb
sdc
sdd
└─sdd1 ntfs 88AEB774AEB75A00
sde
├─sde1
└─sde2 ntfs BackUpLocation D4BCF53BBCF51926 14.4T 1% /media/dibbler/BackUpLocation
sdf
sr0
--------------------------------------------------------------------------------------------------------------
Also, is the changing of the drive letters normal, as now the drive I want to recover is sdd1 ??

sdd1 ntfs is now the 'layer' I want to revert back to just sdd, without loosing the data contained within.

sdb, sdc, sdd, sdf

The above are the QNAP JBOD's I want to recover, sdd is the only one I have an issue with due to being mistakenly formatted in NTFS, is there a way of recovering the mdadm; unmount it possibly.
Will it still have the superblocks in there, if so how can I search for these ?

Or is recovery software my only option ?

Thanks again...

I've not played with a QNAP so my actual experience is limited but JBOD is not a mdadm RAID array and there is no redundancy of data.

As far a I know recovery software is your only option.