[solved] howto recover soft raid from medion nas?

[Mgiese]

dear peers,

a friend of mine had issues with his raid1 medion nas. since it is no longer supported at all (flash browser admin tool) we thought we give it a try on gentoo. i guess the raid in question was a raid1 (2 simple mirrored hdds)

when my medion nas crashed (hardware failure, 1 year ago) i could easily mount the AIX fs on my gentoo box and start copying the files. with the raid nas i am at a loss.

the disks are being recognized as /dev/sdb and /dev/sdc, with each one partition1 of type : Linux RAID

when i used lsblk they have been recognised as follows :
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─md127 9:127 0 0B 0 1
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part
└─md127 9:127 0 0B 0 1


when i tried to mount /dev/sdc1 or sdb1, mount complained that the devices are busy. so i googled and found out, i need to "mdadm --manage --stop /dev/md127" and i guess this is when the crap started i think here i deleted the metadata for the raid1 md127

next i tried to assign the both partitions to a new /dev/md0 device first with :

[Mgiese]

if required and needed i could post (PM) the console log, after my first restart:

i removed the /dev/md127 link from /dev/sdb1 then put the sdc in the pc and removed /dev/md127 link from sdc
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

[Mgiese]

after rebooting i have the notion that that my changes have not been permanent(since the devices /dev/sdc1 and /dev/sdb1 are reassinged to /dev/md127 (as setup by medion nas originally)) :

[Mgiese]

[Mgiese]

[NeddySeagoon]

Mgiese,

[Mgiese]

thanks for your effort, here is the putput of fdisk -l :

[NeddySeagoon]

Mgiese,

[Mgiese]

thank you, i tried :

[NeddySeagoon]

Mgiese,

Start testdisk, its all ncurses menu driven.

25600 is 50 * 512 (Fifty blocks)
you could try 50, 51 ... 56. That's up to including block 56 for 7 tests.

The error message won't mean a lot, as there can be anything at what you are assuming is a filesystem start.
The kernel will try all the filesystems it knows before it gives up.

Try block 57 too if you want to guard against the out by one error.

-- edit --

To gain some confidence in the process, try mounting the first filesystem on your HDD using the same method.
Look at the partition start in fdisk, multiply that by the block size ...
There is nothing like knowing the process works when all the parts come together. It will help your confidence.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Mgiese]

i started fooling around with the 2*1tb hdds. but now we found the old harddiscs 2*512gb, which should be untouched, with them i tried all that you suggested:

[Mgiese]

how can i force testdisk not to write anything to the filesystem ? is it asking for permission to write after scanning ?
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

[Mgiese]

[Mgiese]

the deep analysis of testdisk shows the following :

[NeddySeagoon]

Mgiese,

As process validation, a partitioned USB stick will do.
If /boot is mounted, you can unmount that. Then mount it again for testing.

50*512 is 25600, Then its 26112, not the 26512 that you posted.

fdisk will tell you the block size. USB sticks are rarely 512b blocks. However, for HDD at least, 512b blocks are usually faked on drives with 4k physical blocks, so 512b is still correct.

Yes, The raid metadata describes the on disk layout of the raided space to the kernel, so the kernel knows how to to treat the space as a single device.
Changing/destroying the raid metadata does not harm the data on the raid set. It is still there. Rather like the partition table, which describes where filesystem can be found.
Removing the partition table does not harm the data, its just more difficult to access.

The risk is that the original metadata was version 0.90, at the end of the partition and by using --create, you have overwritten the start of the filesystem with the new metadata format.

If testdisk doesn't show some potential filesystems, the next step is to look at the last MB of data on the drive with a hex editor.
The last 34 blocks should be a copy of the GPT. What comes in the last few blocks just before that is the interesting bit.
More on that once testdisk has done its thing.
Do NOT let testdisk write anything.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Mgiese]

i am a bit confused by the testdisk output :

[Mgiese]

i can answer that question now :

[Mgiese]

for the purpose of learning what i am doing. i use a knoppix liveUSB stick.

[Mgiese]

ok, i understood something now, fdisk -l showed :

[Mgiese]

my final scan of 500gb sdb reports this :

[NeddySeagoon]

Mgiese,

You have already tried

[Mgiese]

yeah i tried block 63 as startblock, did not work.

but testdisk gave me the possibility to look into the different FSs . i found my files in :

[NeddySeagoon]

Mgiese,

I'm pleased you found your data,

I trust you learned from my signature too. :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Goverp]

[Mgiese]