Le galérien du RAID1 linux et le mystère du superblock perdu

Version imprimable

31/05/2020, 18h34
Say hello

Le galérien du RAID1 linux et le mystère du superblock perdu

Bonjour à vous ! :)

J'avais un serveur maison, sous Linux Mint, dont j'ai upgrade le combo CM+CPU (passage d'une P43DE + E7500 à H170-D3HP avec un i5-6500).
Fatalement j'ai réinstallé l'OS, mais ça c'est pas un soucis, c'est sur un ssd qui fait sa vie et n'a rien à voir dans l'histoire

Mon serveur avait un raid1 software (de 2 disques pour le moment) fait avec amour à coup de mdadm.
Le montage initial était peut être pas fait dans les règles de l'art mais aucun problèmes avec le raid. Pour info au départ j'ai dû créer un raid "mono disque" pour conserver les données dessus et formater ensuite le disque qui devait servir à grow le raid (j'avais que 2 DD 4To dont un contenait mes données, les tours de hanoi revisitées)

Bref, là je tente de remonter mon raid et c'est le drame :

Code:

~$ sudo mdadm -A --verbose /dev/md0 /dev/sdb /dev/sdc mdadm: Cannot assemble mbr metadata on /dev/sdb mdadm: /dev/sdb has no superblock - assembly aborted

:boom:

Je me dis what the fucking fuck et tente de vérifier les disques (les 2 disques renvoient les même résultats) :

Code:

~$ sudo fdisk -l /dev/sd* Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 08653A5D-9FAD-411E-A4CA-4C0456195F97 Périphérique Début Fin Secteurs Taille Type /dev/sdb1 2048 7814037134 7814035087 3,7T RAID Linux Disque /dev/sdb1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Code:

~$ sudo gdisk -l /dev/sdb GPT fdisk (gdisk) version 1.0.3 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdb: 7814037168 sectors, 3.6 TiB Model: ST4000DM004-2CV1 Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): 08653A5D-9FAD-411E-A4CA-4C0456195F97 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 7814037134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 7814037134 3.6 TiB FD00

Bon je me dis ok je vois pas de problème à priori mais je suis un noob de toute façon.
Le "protective MBR" je sais pas si je dois être fan ceci dit.

J'essaie d'aller plus loin avec mdadm :

Code:

~$ sudo mdadm -E /dev/sdb /dev/sdb: MBR Magic : aa55 Partition[0] : 4294967295 sectors at 1 (type ee)

Je sais pas trop pourquoi mais j'aime pas, ça me semblait beaucoup plus verbeux avant...

J'ai innocemment tenté de monter direct le HDD en read-only sans trop croire que ça puisse servir à quelque chose :

Code:

~$ sudo mount -r /dev/sdb1 /mnt/test mount: /mnt/test : wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

Au moins ça reconnait un FS j'imagine, mais bon "bad superblock"..

Du coup je tente le coup de poker avec mdadm :

Code:

~$ sudo mdadm --zero-superblock /dev/sdb mdadm: Unrecognised md component device - /dev/sdb

ETONNANT CA ! :|

Et j'atteins le seuil de mes connaissances.
J'ai besoin de vous maintenant et du savoir d'experts CPC :emo:

à ce stade j'ai débranché un des 2 disques, ils sont à priori dans un état identique et je préfère éviter de bousiller les 2 en même temps en allant trop loin.
01/06/2020, 11h48
Rocca

Salut, je ne suis pas trop linuxien, mais j'ai une petite question standard.

Tu indiques que le SSD c'est pour le système. Du coup, que viens faire la MBR sur les HDD ?

Ton système était initialement installé dessus ? Si oui, je te dirais de commencer par virer les partitions cachées sur l'un de tes HDD (vu qu'ils sont identiques, RAID 1). Tu peux tenter en le branchant en USB (boitier externe). Sinon, passe par un logiciel spécialisé dans les partitions...

Une fois que tes HDD seront des disques de données "froides" sans OS dessus, le raid 1 ne devrait pas poser problème, à confirmer.
01/06/2020, 12h09
Say hello

Je savais pas trop si c'était un problème ou pas d'avoir une MBR dessus, .. mais c'est pas juste une feature de GPT pour du legacy ?

Je sais pas trop comment c'est arrivé là non plus ça n'a jamais été des disques de boot.
Du coup je suppose que c'est un gestionnaire de partition qui m'a foutu ça là mais alors j'ai pas souvenir d'avoir initialisé de table de partition et de MBR avant de monter le raid.. à part un coup de fdisk pour définir les 2 supports en type "linux raid auto".

Je vais regarder un peu cette histoire de passer par un gestionnaire de partition au moins pour voir ce qui peut être fait.
Sachant que je vais être très très frileux côté manip vu que je suis très loin d'être un expert des disques, partitions et FS, et que ces disques sont des conteneurs critiques. :emo:
01/06/2020, 13h17
Wobak

Heuuuuu

Pour moi ton mdadm il était fait sur les PARTITIONS (/dev/sdb1) et pas sur le DISQUE (/dev/sdb)....

Essaye de refaire ton assemble avec /dev/sdb1 et pas /dev/sdb.
01/06/2020, 22h03
Say hello

J'ai tenté un truc dans ce sens là avec l'autre disques pour voir (vu qu'un assemble risquait rien) après avoir rebranché le disque et reboot :

Code:

~$ sudo mdadm --assemble --verbose /dev/md0 /dev/sdc1 mdadm: looking for devices for /dev/md0 mdadm: /dev/sdc1 is busy - skipping

Du coup je check si y'a pas un truc qui tourne :

Code:

~$ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md127 : active (auto-read-only) raid1 sdc1[0] 3906885440 blocks super 1.2 [1/1] [U] bitmap: 0/30 pages [0KB], 65536KB chunk

OK donc ça m'a sorti tout seul un md127, why not

Je tente le mount eeeeet...

Code:

sudo mount /dev/md127 /mnt/test/ mount: /mnt/test: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error.

:(

Et un petit "examine" avec mdadm au cas où..

Code:

~$ sudo mdadm -E /dev/md127 mdadm: No md superblock detected on /dev/md127.

Je sais pas ce que j'espérais.. :vibre:
01/06/2020, 22h39
Wobak

Si tu fais un lsblk ou blkid, il te sort quelque chose avec /dev/md127 ?
01/06/2020, 23h08
Say hello

J'obtiens ceci

Code:

~$ lsblk /dev/md127 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT md127 9:127 0 3,7T 0 raid1

et sur sdc

Code:

~$ lsblk /dev/sdc NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdc 8:32 0 3,7T 0 disk └─sdc1 8:33 0 3,7T 0 part └─md127 9:127 0 3,7T 0 raid1

Donc ça n'a pas l'air totalement con encore :tired:

blkid ne renvoie rien pour md127
01/06/2020, 23h14
Wobak

Hmmmm donc là il détecte bien que sdc1 fait partie d'un RAID1 et md127 c'est le device qu'il a créé en auto quand il a détecté un superblock dessus.

Par contre ce qui est plus inquiétant c'est qu'il ne voit aucun filesystem dessus. Tu avais partitionné ton raid1 ou mis des réglages particuliers au niveau mdadm ?
02/06/2020, 08h21
Say hello

Pas d'exotisme autant que je sache, un simple raid1 de 2 disques avec un une unique partition ext4.

EDIT:
Par contre faut que je vérifie un truc, quand un des lecteurs était débranché, j'ai tenté une manip à base de "create" sur le sdb sachant qu'il est pas sensé être destructif pour faire un array d'un disque (genre voir si ça refait un superblock en gardant ma structure). Bon j'ai quand même du faire un "force" pour passer outre le check du nombre de disques pour un raid...
Ce qui aurait marché du coup, j'ai un raid montable, mais pas ce que je veux, et ça nous induirait en erreur...
Et depuis que j'ai rebranché le 2e disques je me demande si linux n'a pas changé l'assignement des noms sdb et sdc. Donc le md127 vient peut être de cette manip, ça me parait plus logique d'ailleurs qu'il monte auto un raid après que j'ai bidouillé un create et qu'on ait un résultat louche "t'as un raid mais pas de FS dedans".

Faut peut être que je me concentre sur celui qui est maintenant le sdb ?

Mais du coup sur sdb j'en suis là :

Code:

~$ lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 3,7T 0 disk └─sdb1 8:17 0 3,7T 0 part ~$ sudo mdadm --examine /dev/sdb /dev/sdb: MBR Magic : aa55 Partition[0] : 4294967295 sectors at 1 (type ee)

Code:

~$ sudo fdisk -l /dev/sdb Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : 3978C15B-C336-4245-94E4-A6F2A5DDE961 Périphérique Début Fin Secteurs Taille Type /dev/sdb1 2048 7814037134 7814035087 3,7T RAID Linux ~$ sudo fdisk -l /dev/sdb1 Disque /dev/sdb1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets

et pour comparaison sdc :

Code:

~$ sudo fdisk -l /dev/sdc Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 08653A5D-9FAD-411E-A4CA-4C0456195F97 Périphérique Début Fin Secteurs Taille Type /dev/sdc1 2048 7814037134 7814035087 3,7T RAID Linux ~$ sudo fdisk -l /dev/sdc1 Disque /dev/sdc1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

à part la taille des secteurs physique je vois pas grande différence là dessus et les 2 sont bien captés comme RAID linux en plus.

Je retente le assemble sur sdb1 pour voir et ...

Code:

~$ sudo mdadm --assemble --verbose /dev/md1 /dev/sdb1 mdadm: looking for devices for /dev/md1 mdadm: no recogniseable superblock on /dev/sdb1 mdadm: /dev/sdb1 has no superblock - assembly aborted

Lui je pense que c'est bien celui qui était débranché et qui est toujours dans son état non assemblable du début du topic.
02/06/2020, 08h47
Wobak

Tu peux tenter les mdadm --examine sur les partitions au lieu des disques ?

Ensuite pour savoir lequel est lequel : hdparm -I /dev/sdX|grep Serial
02/06/2020, 12h00
Say hello

Ok donc j'ai fais le hdparm, et pour info j'ai un Toshiba et un Seagate.
Hier le sdb branché seul, c'était le Seagate, aujourd'hui, avec les 2 disques branché, il est le sdc.
Donc hier j'ai fais un "create crado" sur le Seagate, donc le sdc actuel qui s'est monté en md127.

Du coup le disque qu'on va dire "untouched" par ma manip, c'est le Toshiba qui est actuellement le sdb et qui est toujours dans l'état à l'origine du post.

L'examine sur les partitions :

Le toshiba "sdb" donc

Code:

~$ sudo mdadm --examine /dev/sdb1 mdadm: No md superblock detected on /dev/sdb1.

le seagate "sdc"
qui s'est pris un "zeroing" de superblock en plus d'un create douteux

Code:

~$ sudo mdadm --examine /dev/sdc1 /dev/sdc1: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : dd36ab75:ed687279:80a4f024:85c655d0 Name : MIDGARD:0 (local to host MIDGARD) Creation Time : Sun May 31 23:26:02 2020 Raid Level : raid1 Raid Devices : 1 Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB) Array Size : 3906885440 (3725.90 GiB 4000.65 GB) Used Dev Size : 7813770880 (3725.90 GiB 4000.65 GB) Data Offset : 264192 sectors Super Offset : 8 sectors Unused Space : before=264112 sectors, after=15 sectors State : active Device UUID : 0ae1e089:6f00e537:150ec874:1f5a8bef Internal Bitmap : 8 sectors from superblock Update Time : Sun May 31 23:26:02 2020 Bad Block Log : 512 entries available at offset 24 sectors Checksum : 965de6cf - correct Events : 0 Device Role : Active device 0 Array State : A ('A' == active, '.' == missing, 'R' == replacing)

Est ce que je devrais envisager une manip de clonage type "dd if=/dev/sdb of=/dev/sdc" pour réparer ma folie d'hier avant d'aller trop loin ? ou rien de tel pour l'instant ?
02/06/2020, 12h40
Wobak

Ok donc vire celui qui a eu un create douteux + erase superblock et ne mets que l'autre dans le système.

Regarde alors si mdadm arrive à assembler quelque chose, et sinon, regarde un lsblk / blkid, voir si quelque chose apparaît sur ton disque.

Question : tu as migré l'OS, tu as mis à jour ou tu es resté sur la même version ? Parce que si t'as mis à jour, t'as peut être une vieille version de mdadm dont la metadata était stockée différemment.

Si tu fais un mdadm --detail --scan, ou mdadm --examine --scan, tu as des outputs ?

(je t'ai rajouté sur Steam, si tu veux qu'on tshoot en live)
02/06/2020, 15h04
Say hello

ok donc seul le toshiba est branché maintenant, mais rien de nouveau, le assemble répond :

Code:

~$ sudo mdadm --assemble --verbose /dev/md1 /dev/sdb1 mdadm: looking for devices for /dev/md1 mdadm: no recogniseable superblock on /dev/sdb1 mdadm: /dev/sdb1 has no superblock - assembly aborted

J'ai check le /proc/mdstat dans le doute mais y'a rien qui tourne ou est actif.

"mdadm --detail --scan" et "mdadm --examine --scan" n'affichent rien.

et le lsblk ne donne rien de nouveau

Code:

~$ sudo lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 3,7T 0 disk └─sdb1 8:17 0 3,7T 0 part

Pour l'install de l'OS j'étais reparti from scratch vu que je changeais de Mobo.
Mais comme le précédent montage était assez récent, la version majeure de la distrib est certainement la même dans les 2 install : Linux Mint 19
Après est ce que c'était bien la 19.3 ou la 19.2 je ne sais pas mais je pense pas que ça change grand chose à ce niveau là.

Cool merci pour steam, en ce moment je suis pas assez constamment dispo pour passer en live manip mais si à un moment je peux j'hésiterai pas :)
02/06/2020, 15h10
Wobak

Hmmmm on dirait vraiment que y'a pas de data sur ta partoche qui concerne un md device...

Si tu fais un :

Code:

file -Ls /dev/sdb1

Ça devrait t'afficher ce qu'il y a sur le disque.
02/06/2020, 15h59
Say hello

Il me répond "/dev/sdb1: data" donc je suppose qu'il voit que c'est pas totalement vide mais après sans FS identifié, je sais pas si ça affecte la table de partition ou l'intégrité...

J'ai fais un "parted -l" par curiosité voir si ça donnait une info en plus ou quoi

Code:

Modèle : ATA TOSHIBA HDWQ140 (scsi) Disque /dev/sdb : 4001GB Taille des secteurs (logiques/physiques) : 512B/512B Table de partitions : gpt Drapeaux de disque : Numéro Début Fin Taille Système de fichiers Nom Drapeaux 1 1049kB 4001GB 4001GB raid

:|

Je sens que bientôt je vais devoir passer par un testdisk
02/06/2020, 17h43
Wobak

Ouh... Le data en général c'est que y'a pas de flag ou superblock spécifique, donc ça pue un peu...

J'ai un peu peur que ton disque il ait perdu (je sais pas pourquoi / comment hein) son superblock...
02/06/2020, 18h58
Say hello

Et c'est pas comme une partoch ext3 ou ext4 avec des backup du superblock planqués quelque part ?

J'ai tenté un coup d'oeil dans testdisk mais j'ai pas trop d'idée de ce que je peux faire avec exactement.
Après une analyse il trouve 2 traces de partitions
https://tof.cx/images/2020/06/02/b08...0a2c7fe60b.png

https://tof.cx/images/2020/06/02/b6c...fe01d8b63e.png

L'une des 2 contient des refs de la précédente vie du disque (dans un NAS Qnap).

https://tof.cx/images/2020/06/02/421...3311ec0740.png

Et l'autre qui est soit ce qui m'intéresse, soit une ancienne partition "data" de la période qnap...:

https://tof.cx/images/2020/06/02/942...c48a5328aa.png

https://tof.cx/images/2020/06/02/942...c48a5328aa.png

partitions qui sont flagguées "deleted" apparemment, pas primary.
Mais en info de la 2e on voit des flags "ext4" et "Backup_SB", et une action de "load backup" mais je sais pas à quoi m'attendre.

Je vais peut être rebrancher l'autre disque aussi pour voir si j'ai accès à quelque chose via un testdisk malgré mes manips.

Je me demande si c'est pas une histoire de changement de CM en passant de techno legacy à de l'uefi sur un chipset qui supporte du raid qui pourrait avoir fumé les débuts de disques.. :huh:
02/06/2020, 23h38
Say hello

Alors résultat intéressant, en lançant un scan approfondi du seagate avec testdisk par contre je tombe sur une trace de partition où je retrouve mon listing de fichiers :

https://tof.cx/images/2020/06/02/b4b...c764cab2a6.png

Et l'arbo est pas mal navigable, j'ai l'impression que tout la liste de fichiers et répertoire est bien là.
J'ai plus qu'à trouver quoi faire avec ça...
03/06/2020, 00h14
Wobak

Une trace de partition ? C'est à dire ?
03/06/2020, 11h23
Say hello

Testdisk permettant de scanner le disques pour trouver des partitions endommager, retrouver des fragments de partitions et en récupérer des données, eux même parle de "traces de partition" dans une doc, je restais sur leur terme.

Y'a moyen de sélectionner un reliquat de partition inactive et de copier des fichiers de l'arbo lu dans la partition vers un autre support.
Comme le disque a pas eu d'autres I/O depuis le massacre de son superblock, y'a peut être moyen que je parvienne à récup mes données comme ça. :) ou au moins inventorier son contenu avant perte, pour voir si j'ai définitivement perdu quelque chose de critique.
Par contre le scan par block sur un disque de 4To c'est.. lent... sans surprise, mais c'est impressionnant ce soft, je me sens comme une merde à être devops java/gcp :XD:
04/06/2020, 09h26
Say hello

En tout cas avec ça j'arrive à récupérer mes fichiers en les copiant sur un support externe !
Je suis en train de backuper, ensuite je testerais si testdisk arrive à restaurer la partition mais seulement par curiosité parce qu'une fois les données backup je purge les disques et remonte proprement un raid1 tout neuf. :)

Grand merci Wobak pour ton temps et tes idées :)