Mount von Raid-1 Array und auslesen von Daten

[nex86]

Habe hier ein defektes Bufallo NAS welches keinen mucks mehr von sich gibt.
Ich soll die Daten davon sichern falls möglich.
Die Platten scheinen noch zu funktionieren und zeigen mehrere "Linux Raid Member" Partitionen.
Ich habe MDADM unter Linux Mint installiert und dieses findet 3 arrays.

und ein 1GB Swap array
ein 5.1GB auf dem sich anscheinend die Firmware des NAS befindet
Ein 2TB großes auf dem wohl die Daten sind,


wenn ich versuchen will im Disk Manager das 2TB zu mounten kommt die Meldung

"Error Mounting filesystem"
Error mounting /dev/md2 at/media/root/20a322c5-395b-4856-8923-5c4c5e1311e5: can't read superblock on /dev/md2 (udisks-error-quark, 0)

selbes wenn ich versuche über das terminal zu mounten

tom@tom-B150-HD3P:/media$ sudo mount -v /dev/md2 /mnt/md2
mount: /mnt/md2: can't read superblock on /dev/md2.

bin jetzt nicht so der allwissende Linux Guru. Von daher, hat vllt von euch einer eine Idee?

Die Datenpartition scheint jedenfalls nicht verschlüsselt zu sein da ich im Hexeditor darin klartext von irgendwelchen Dateien erkennen kann.

 

[snaxilian]

Poste bitte mal die vollständige Ausgabe von mdadm --examine --brief --scan --config=partitions

 

[kartoffelpü]

Ich hab zwar wenig praktische Erfahrung mit mdadm, aber ich würde mich an sowas langhangeln: https://serverfault.com/questions/834886/how-to-recover-raid-mount-cant-read-superblock
Am Besten vorher ein Image von den betroffenen Platte machen...

 

[nex86]

Poste bitte mal die vollständige Ausgabe von mdadm --examine --brief --scan --config=partitions

ARRAY /dev/md0 UUID=1a174265:f9b9689e:89d3360d:c8e92716
ARRAY /dev/md/1  metadata=1.2 UUID=03b32093:34cf0490:9e8bfabe:310e5740 name=UNINSPECT-EMB4A:1
ARRAY /dev/md/10  metadata=1.2 UUID=ecd36ef4:8c188c76:d19e8ac8:3facc5a1 name=UNINSPECT-EMB4A:10
ARRAY /dev/md/2  metadata=1.2 UUID=0393b069:99562b42:38126032:41bf731c name=LS-WXLB4A:2

 

[Groug]

Bufallo nutzt so weit ich weiss xfs. xfsprogs nachinstallieren.

 

[nex86]

Ich hab zwar wenig praktische Erfahrung mit mdadm, aber ich würde mich an sowas langhangeln: https://serverfault.com/questions/834886/how-to-recover-raid-mount-cant-read-superblock
Am Besten vorher ein Image von den betroffenen Platte machen...

bei dem vorschlag von dort komm bei mir nur:

mdadm: looking for devices for /dev/md5
mdadm: /dev/sdd6 is busy - skipping
mdadm: no recogniseable superblock on /dev/sdc6
mdadm: /dev/sdc6 has no superblock - assembly aborted

Ergänzung (22. Februar 2021)

Bufallo nutzt so weit ich weiss xfs. xfsprogs nachinstallieren.

soll laut apt schon installiert sein.

 

[snaxilian]

Immerhin schon metadata=1.2.

Hast du den Vorschlag von serverfault.com 1:1 abgetippt oder an deine Situation angepasst?
Was mich ein bisschen irritiert sind die vier gefundenen Arrays aber ignorieren wir das mal vorher...
Könntest du bitte noch die Ausgabe von cat /proc/mdstat posten sowie fdisk -l /dev/md*, beide jeweils als root oder mit vorangestelltem sudo. Ersteres zeigt den Status aller aktiven Raids, der zweite Befehl zeigt die Partitionierung bzw. Partitionsinformationen zu den Devices.
Die gefundenen /dev/md* sind ja erst einmal nur Block-Devices (quasi virtuelle Festplatten) in denen dann erst die Partitionen mit Dateisystemen liegen.

 

[nex86]

alles klar hier:

tom@tom-B150-HD3P:~$ sudo cat /proc/mdstat
[sudo] password for tom:       
Personalities : [raid1]
md0 : active raid1 sdd1[0]
      1000384 blocks [2/1] [U_]
    
md2 : active (read-only) raid1 dm-2[0]
      1938311340 blocks super 1.2 [2/1] [U_]
    
md10 : active (read-only) raid1 dm-1[0]
      1000436 blocks super 1.2 [2/1] [U_]
    
md1 : active (read-only) raid1 dm-0[0]
      4999156 blocks super 1.2 [2/1] [U_]
    
unused devices: <none>
tom@tom-B150-HD3P:~$ sudo fdisk -l /dev/md*
fdisk: cannot open /dev/md: Is a directory


Disk /dev/md0: 976,96 MiB, 1024393216 bytes, 2000768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md1: 4,79 GiB, 5119135744 bytes, 9998312 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md10: 976,101 MiB, 1024446464 bytes, 2000872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md2: 1,82 TiB, 1984830812160 bytes, 3876622680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

und habs abgetippt aber die Pfade an die jeweiligen Partitionen bei mir angepasst.
sdd6 bzw sdc6 wäre bei mir die Datenpartition die ich retten will.

 

[nex86]

Bei allem dass ich versuche läuft es immer auf "can't read superblock" hinaus...
glaube dass die partitionen wirklich platt sind..
Habe schon versucht nur von einer platte auf die daten zuzugreifen, das geht auch nicht.
Bin schon den ganzen nachmittag bis Abends daran dran ohne Erfolg

sudo mdadm --assemble --run /dev/md0 /dev/sdc6
mdadm: /dev/md0 has been started with 1 drive (out of 2).
mkdir ~/oldhdd
sudo mount -t xfs /dev/md0 ~/oldhdd
mount: /home/tom/oldhdd: can't read superblock on /dev/md0

 

[snaxilian]

Die Ausgabe zeigt aber, dass die jeweiligen Raid1 immer nur aus einer Disk bestehen. Dein Eingangspost liest sich eher so, dass du noch beide hast und mit beiden ehemaligen NAS-HDDs die Datenrettung versuchst...
Was mich wundert ist dass der fdisk Befehl keinerlei Infos zur Partitionstabelle und/oder Dateisystem zeigt, da wird wirklich was im argen liegen... Zeigt sich wieder einmal: Backups sind nicht grundlos wichtig aber viele lernen leider erst durch Schmerz.

 

[nex86]

Ich habe am ende die zweite platte weg genommen weil diese klack Geräusche machte, aber ich kann die Smart Werte nicht auslesen weil das USB Gehäuse diese anscheinend nicht überträgt.
Habe gelesen dass man das raid auch nur mit einer platte einhängen kann, aber das kommt genau aufs gleiche raus.

 

[Uridium]

Versuche mal testdisk oder mounte ohne explizitem -t (für auto-detect). Wenn das nichts bringt, würde ich den Superblock extrahieren/untersuchen oder mal grob mit einem Hexeditor über die Platte schauen.

 

[Groug]

Du könntest mal ein Image machen und es mit diesem Image mit xfs_repair versuchen

 

[nex86]

den Superblock extrahieren/untersuchen oder mal grob mit einem Hexeditor über die Platte schauen.

wonach soll da ausschau halten?

 

[Uridium]

Ich sehe gerade, dass Du das schon gemacht hast. Einmal drüber gucken, ob grundsätzlich Daten da sind. Wäre die Platte oder der Lowlevelzugriff defekt, käme meist nur 0xFF raus.

Ein Blick auf den Superblock ist interessanter. Dort auch zuerst schauen, ob er überhaupt da ist (die Position logisch ableiten oder nach der Magic Number "XFSB" suchen) oder evtl. komplett zerstört wurde, dann extrahieren und mit 010Editor untersuchen (der sollte das farblich aufbrechen können, wie auf dem Bild in dem Link).
https://righteousit.wordpress.com/2018/05/21/xfs-part-1-superblock/

Die Idee von @Groug ist auch gut. Man kann den Vorgang auch simulieren (-n), so dass man u.U. nicht gleich ein Image erstellen muss.
https://wiki.archlinux.org/index.php/XFS#Repair

 

[nex86]

werde ich wenn ich zeit habe nochmal durchgehen.. eventuell am freitag..
Die platten sind gerade im Büro auf der Arbeit