Jump to content
XPEnology Community
  • 0

Problème groupe Raid et plantage lors de la verification de cohérence.


Bulok

Question

Bonjour à toutes et à tous !

Je viens vers vous aujourd'hui car je n'arrive pas à résoudre un sacré problème ...

Sur mon Xpenology, j’héberge quelques serveurs de jeu ( Ark et Minecraft principalement), je m'en sert également comme hébergement vidéos pour mon groupe ( concerts et répètes), Vidéosurveillance de la maison, etc...


De temps en temps, le NAS plante, et ne répond plus, impossible de se connecter à celui-ci via ssh/ftp/http ....(obligé d'aller l'éteindre de force avec le bouton .. ou la prise ... et de le relancer).
Je pense que c'est dû au serveur de Jeu Ark et d'une map en particulier ( aucun problème avec les autres bizarrement ... ).


Je démonte le bouzin, petit coup de nettoyage/dépoussiérage  .. je remonte le tout à l'identique ..
J'ai d’abords pensé a un problème de RAM .. Suite à un Memtest86+ pendant plus de 5h en boucle, aucune erreur trouvée...


Et là lors du redémarrage, problème sur mon groupe Raid SHR ... Un de mes disque est considéré comme inutilisé (le 3)... Il est Initialisé, avec un status SMART normal.

Je fait réparer, tout va bien jusque là... puis DSM lance une vérification  de la cohérence de parité ...

Le NAS plante .. ( comme lorsque mon serveur Ark est en route, alors que docker est complètement arrêté ) aucune réaction.

Après l'avoir relancé, il m'indique un de mes disques en panne (le même qui était en status initialisé)... J'ai quand même accès a mes données .. du coup, je sauvegarde tout .. (j'y ai mis plusieurs jours pour seulement 1,5 To car plantages à répétions) sauf mes fichiers vidéos ( pas assez de place ^^ )...

Je remplace le disque en question, refait une réparation, une vérification de cohérence, et là .. replantage ...

A chaque fois que je tente quelques chose, je suis obligé d'aller couper le NAS ...


Tout les services que je pouvais utiliser sont désactivés.

Actuellement, j'ai cloné le disque soit-disant en panne (le N°3), remplacé celui-ci, et ça plante toujours, J'en ai fait de même avec le plus ancien dedans (le n°1) , ...plantage ...


Je ne sais plus trop quoi faire ...

Est-ce qu'une suppression du groupe raid ... et une restauration de la configuration pourrait m'aider à récupérer mes vidéos ?
Comment trouver ce qui fait planter le NAS ?

 



Merci d'avance pour votre aide !!



Config :
Modèle : DS3615xs - DSM 6.1.7-15284 Update 3   


CPU : AMD A10-5800K
CM : ZOTAC A75-ITX WiFi b
Ram : Corsair Vengeance Low Profile 16 Go (2 x 8 Go) DDR3 1600 MHz CL9
HDD 1 : Western Digital Red 3 To (WD30EFRX)
HDD 2 : Seagate Ironwolf 8To (ST8000VN0022)
HDD 3 : Seagate Ironwolf 4To (ST4000VN008)
HDD 4 : Seagate Ironwolf 4To (ST4000VN008)

Edited by Bulok
Link to comment
Share on other sites

25 answers to this question

Recommended Posts

  • 1

Salut jeunes gens,

Au vu des différents soucis, il me semble également que le soucis vienne plutôt d'un problème matériel.
Aurais-tu une alimentation qui pourrait faire l'affaire quelques temps pour tester ? Cela pourrait également expliquer pourquoi une fois la machine "vidée" d'une partie des hdds pourrait fonctionner beaucoup plus longtemps sans plantage. Idem, lors de la reconstruction d'un volume/groupe, cela sollicite beaucoup les ressources processeur, disques, etc et donc du courant. Concernant ton serveur de jeu et le lien avec une map particulière, peut-être une map plus gourmande, plus grande qui aurait pu mettre en exergue un soucis futur.

En général, si tu avais un soucis processeur, rien ne démarre, et ta ram a été testée.

 

Edited by renegadeBE
Link to comment
Share on other sites

  • 0

Bonsoir,

Pas évident comme problème, mais un plantage brutal est possible aussi en cas de surchauffe du proc ou du chipset (et éventuellement de la RAM).

Selon les bios, la machine peut s'arrêter brutalement si la température est surveillée, ou rester figée dans le cas contraire.

La reconstruction d'un disque en raid soft consomme pas mal de CPU je suppose, donc la surchauffe pourrait être une piste à exploiter.

 

Bons tests et bon courage

Jacques

Link to comment
Share on other sites

  • 0

Merci pour ta réponse. 

 

Malheureusement ce n'est pas une surchauffe... Le NAS est en moyenne entre 15 et 18°C (dans une baie info dans le garage.. Avec les températures actuelles c'est un frigo dedans ^^). 

 

Quand a l'utilisation Cpu 1 voir 2% max pendant l'opération de reconstitution 😕

 

Je suis en train de cloner mon HDD n°2.. Celui de 8 To.. J'ai vu dans les détails disques du moniteur de ressources qu'il était à 0% d'utilisation alors que les 3 autres tournaient entre 6 et 12%.. 

 

Je vais tenter demain soir quand ça sera fini. 

Edited by Bulok
Link to comment
Share on other sites

  • 0

Bonjour à toi !

C'était, avant de le dépoussiéré, dû au serveur de jeu Ark (avec une certaine map en mémoire).. Car lorsque je changeait celle-ci, ou que j'arrêtais ce paquet là en particulier je n'avais plus aucuns problèmes.

Depuis, il plante à répétition, de jours comme de nuit ...

C'était également lui qui jouait le rôle de serveur DHCP.... du coup, c'est un peu plus problématique dans la maison ^^.


Pour le moment, vu que mon groupe raid est HS , je n'ai plus de plantage... (la reconstruction du groupe RAID SHR ne se fait pas )...


Pour ce qui est des logs, je pense malheureusement qu'ils pourront rien nous apprendre :

putty1.thumb.png.64894dd6384ae82f7701ee1618142658.pngputty2.thumb.png.7231424b95c90e8b989f60a9bba547cd.png

 

 

C'est pas tout récent 😕


Encore 4h de clonage pour mon hdd n°2 et je test ... mais je pense que je peut dire au revoir au groupe raid et le recréer... Une possibilité de récupérer les fichiers dedans quand même ?

 

 

 

EDIT : 35mn après ce message, il me fait mentir ... De nouveau planté et plus accessible 😕

Edited by Bulok
Link to comment
Share on other sites

  • 0

Bonjour,

Pour récupérer les données, l'idéal est d'utiliser un live-cd Linux et de monter (si ce n'est as fait automatiquement) les différentes couches (LVM et mdadm).

Il y a un article sur le site de Synology pour accéder aux disques à partir d'un linux (CD ou USB).

 

Regarde les messages d'erreur enregistrés dans le bios éventuellement (NMI), ça peut aider si c'est un problème hard c'est parfois enregistré.

 

Jacques

Link to comment
Share on other sites

  • 0

Voici les données que j'ai réussi à avoir ( j'ai voulu faire un test étendu mais le serveur à de nouveau crash ( il a tenu 5h51mn tout de même ^^ )...

Les infos S.M.A.R.T.  :  (le disque 2 est tout neuf, reçu hier, clone du disque initialement monté à sa place).


 

 

625351980_SMART1.thumb.png.7923e372d0ef7565e503e4e83ca86254.png

 

336079101_SMART2.thumb.png.e86c4b69ed05a31f44724d676a95d050.png

 

1126770714_SMART3.thumb.png.40d8c5d100487c625107effddd6c394c.png

 

636489463_SMART4.thumb.png.2aff8b80080eeada6d9cd125d17767d1.png

 

 

 

J'ai tenté plusieurs recherche sans trop comprendre ( même avec google trad j'ai du mal ^^ ) ..
Voici d'autres captures :

 

Groupe.thumb.png.8853f94892ba1329931b34a2f8983613.png

 

HDD.thumb.png.82938a367630712301c3cee975e2c11d.png

 

 

 

PUTTY.png.c346a90fdd0a56a8020fd467012c6bf3.png

 

 

 

 

Edited by Bulok
Link to comment
Share on other sites

  • 0

Le SMART du 1disque western est ok

Pour les Seagate, je ne pourrai me prononcer clairement, car je ne connait pas trop cette marque. Mais peut etre faudrai t'il les inspecter avec le logiciel fournisseur pour etre sur qu'il n'ont pas de soucis ?

Link to comment
Share on other sites

  • 0

Merci pour ta réponse.

D'après les tests ils sont bons aussi ...

 

News : le serveur à planté même après avoir enlevé tout les HDD et laissé le neuf de 8To fraichement formaté ...

 

 

Coup de sang, j'ai tout viré, nouvelle clé usb, nouvelle installation... j'ai eu du mal,  .. je serais bien passé sur un 918+ avec le loader 1.04 mais impossible de le trouver sur le réseau ...

J'ai récréé un raid ainsi que des volumes neufs avec mon HDD reçu il y a quelques jours ...
Actuellement en vérification du disque... J'espère ça va passer !


Je testerais de récup mes données quand j'aurais fini de télécharger l'iso d'ubuntu (avec l'adsl, c'est long ^^ )...
 

Link to comment
Share on other sites

  • 0
il y a une heure, Bulok a dit :

News : le serveur à planté même après avoir enlevé tout les HDD et laissé le neuf de 8To fraichement formaté ...

 

Cela ressemble plutot a un soucis hardware.

Tu devrai je pense, installer un windows 10 ou autre, et stresser un peu ta config afin de voir ce quil se passe ( avec occt par exemple )

Probleme de température par exemple ?

Link to comment
Share on other sites

  • 0

Je n'ai pas encore osé installer windows dessus pour tester.. mais j'ai pas eu de plantage depuis hier avec 1 seul HDD dedans...

Pour les températures, c'est sur que ce n'est pas ça.

J'attends de voir si je peux récupérer mers données et je remet les autres disque dur dedans.

Link to comment
Share on other sites

  • 0

Petite news pour cette nuit, j'ai essayer de monter mon raid avec un Live-Ubuntu sur clé usb.. 

 

Après avoir suivi scrupuleusement le tuto Synology, j'arrive sur cette erreur lors de montage

 

mdadm: Duplicate MD device names in conf file where found.

 

Du coup ça bloque là. 

 

 

Quand je vais dans le fichier /mdadm/mdadm.conf ça me donne ça :

(c'est du copié /collé du net.. Les UUID n'étaient pas les mêmes).. 

 

# definitions of existing MD arrays

 

ARRAY /dev/md/2 metadata=1.2 UUID=xxxxxxxxxxxxx name=ServeurBulok:2

ARRAY /dev/md/2 metadata=1.2 UUID=xxxxxxxxxxxxx name=ServeurBulok:2

ARRAY /dev/md/3 metadata=1.2 UUID=xxxxxxxxxxxxx name=ServeurBulok:3

 

 

Si je comprend bien, mon 1er hdd n'est plus visible (md/0) et le 2eme (md/1) est considéré comme le 3ème (md/2).

 

À ce niveau, je n'ai pas trouvé comment faire pour lui donner le bon ordre des hdd 😕

Link to comment
Share on other sites

  • 0

Bonjour,

/dev/mdX représente un groupe raid (0 pour le premier, 1 pour le 2ème, etc...).

Ces groupes sont répartis sur un certain nombre de disques ou de partitions et on peut voir la structure (et les manquants dans le fichier /proc/mdstat (commande cat /proc/mdstat pour lire le contenu).

Résultat de la commande "cat /proc/mdstat" sur mon NAS :
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [raidF1] 
md2 : active raid5 sda5[0] sdd5[3] sdc5[2] sdb5[1]
      11706562368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      
md3 : active raid1 sde3[0]
      971940544 blocks super 1.2 [1/1] [U]
      
md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4]
      2097088 blocks [12/5] [UUUUU_______]
      
md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]
      2490176 blocks [12/5] [UUUUU_______]
      
unused devices: <none>

md0 représente le système XPenology (réparti dans la partition 1 de chacun des disques durs

md1 est le swap réparti sur la partition 2 de tous les disques durs

md2 est un raid SHR réparti sur la partition 5 des 4 disques principaux (4T0)

md3 est un raid SHR (sans sécurisation) sur un disque unique

Le montage peut être vu avec la commande mount (mount | grep ^/dev pour ne voir que les partitions physiques ou presque)

# mount | grep ^/dev
/dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
/dev/md3 on /volume2 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50)
/dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50)

Dans un raid SHR, il y a un raid Soft (mdadm) et une couche d'abstration supportée par LVM (Logical Volume Manager).

La commande lvm permet d'afficher ou de gérer le tout (résultat pour le seul volume LVM présent dans mon NAS (/dev/mapper/vg1-volume) :

lvm vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               10.90 TiB
  PE Size               4.00 MiB
  Total PE              2858047
  Alloc PE / Size       2858047 / 10.90 TiB
  Free  PE / Size       0 / 0   
  VG UUID               rdtKYh-nE8n-xLRq-CVPW-VXLE-LTDS-cBEMrK

Ça devrait te permettre de t'y retrouver un peu plus facilement dans la configuration de tes disques.

 

Jacques

Link to comment
Share on other sites

  • 0

Juste un complément sur ma réponse :

Dans le fichier /proc/mdstat, on voit la structure des différents raids et les disques concernés. Pour mémoire, un disque Up est noté U, un disque absent _

Pour md0, le système, il est prévu sur tous les disques possibles (8), donc les infos d'état des disques sont : [UUUUU_______] soit 4 Up et 4 manquants

Pour md1, le swap, c'est la même configuration : [UUUUU_______]

Pour md2, le volume1 via LVM, il y a 4 disques déclarés, donc on retrouve l'état ainsi : [UUUU]

Pour md3, un seul disque, l'état est noté : [U]

 

Jacques

Link to comment
Share on other sites

  • 0

Je m'en suis douté un peu quand j'ai fais la fameuse commande cat /proc/mdstat... 

 

J'ai obtenu l'image que je joint. 

 

Si je comprend bien, c'est dans md2 et md3 que c'est le bordel, pour lui, il me manque 2 disque sur 4 pour l'un, et 1 sur les 3 pour l'autre (par contre, j'ai toujours eu 4 hdd dedans donc c'est bizarre ^^). 

 

Est-il possible de "combler" manuellement les trous manquants et de lui dire ou chercher les infos pour réformer le raid (et les 2 volumes présent dessus du coup). 

 

 

IMG_20210223_032826.png

Link to comment
Share on other sites

  • 0

Bonjour,

Effectivement, il semble manquer sda et sdc au niveau des raids md2 et md3 (et pour md3 c'est un seul disque, ce qui semble indiquer que les informations du raid inscrites dans le superblock (en fin de disque) ne sont pas à jour.

Les commandes mdadm permettent de reconstruire un raid et d'ajouter manuellement (ou de retirer) un disque d'un grouê raid.

Je n'ai pas assez de pratique pour te guider de mémoire, les tutos ne manquent pas, entre autres celuici : https://www.linuxpedia.fr/doku.php/expert/mdadm

Les règles de base sur ce genre de problème sont :

1) Sauvegarder au maximum les données accessibles

2) Prendre son temps

3) Si on est fatigué, remettre à plus tard les opérations critiques, une simple faute de frappe peut détruire un système raid

En principe, même si le superbloc a été effacé par accident, les données ne sont pas modifiées sur le disque, mais un disque rajouté peut avoir un superbloc à jour (il fait partie du raid) mais ne pas avoir été reconstruit et donc ne pas contenir les données.

Normalement, un raid SHR supporte 1 disque perdu, pas 2 (à moins d'avoir choisi la double redondance à la création, en DSM 6 uniquement). Donc le raid md2 me parait très mal en point (sauf si le disque d'origine déclaré en faut est encore lisible).

 

Bon courage et patience surtout

Jacques

 

  • Like 1
Link to comment
Share on other sites

  • 0

Hello :)

 

Merci pour les infos que tu me donne.. Je pense que j'avance !!! 

 

Après montage avec un live CD, je pense avoir trouvé le pourquoi du comment !!... 

 

 

 

Si je ne me trompe pas, d'après mon screen. Mon hdd de 8To (qui est en fait le clone) n'a pas le même uuid pour la partition sdd5 que les autres... Donc pour lui, pas la même et donc planté !.. 

 

J'ai tenté de modifier l'uuid avec la commande "tune2fs -U <Mon UUID> /dev/sdd5" mais j'obtiens le message suivant :

Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdd5

/dev/sdd5 contient un système de fichiers linux_raid_member étiqueté << ServeurBulok:2 >>

 

Avec gparted je n eoeux pas modifier ce fameux Uuid, l'option est grisé. 

J'ai essayé aussi de démonté le point de montage /dev/md127 qui fait référence à sdd5.. J'ai comme résultat

Cannot get exclusive access to /dev/md127: Perhaps a running process, mounted fikesystem or active volume group.

 

Pour le moment j'en suis là.. Je reste persuadé qu'en modifiant cet UUID qui ne correspond pas aux autres j'ai moyen d'avoir accès au raid ! 

IMG_20210226_185745.jpg

Link to comment
Share on other sites

  • 0

Bonsoir,

Je n'ai jamais eu à jour avec les UUID pour un raid, mais c'est vrai que ça peut se tenter sans grand risque.

/dev/md127 est un périphérique raid créé lorsqu'on ne peut pas identifier le numéro du raid dans les données du disques (dans ton cas, tu dois avoir les autres qui ont été détectés correctement, et le disque sdd qui ne peut être rattaché au raid probablement suite à son UUID.

Le process qui occupe le disque est très probablement la gestion du raid par mdadm.

Il faut donc démonter les partitions /dev/mdX, désassembler le raid avec la commande qui va bien pour "sortir" les disques de la gestion mdadm.

Ensuite, retente la modification avec la commande mdadm.

Voir la réponse 6 de ce lien https://ubuntuplace.info/questions/311088/how-to-change-filesystem-uuid-2-same-uuid qui devrait correspondre à ton problème.

 

Jacques

Link to comment
Share on other sites

  • 0

Ne réussissant pas a démonter md127 j'ai tout simplement reboot ^^ ..

Du coup,  j'avais déjà survolé le lien que tu m'as donné.

Chaque fois que j'essaie quelque chose qui prend en compte sdd5 il me repond ça :
 

root@ubuntu:~# mdadm --assemble /dev/md2 --update=uuid --uuid=7db29d47-2855-5582-f5b4-af6ddfd0692f /dev/sd[abcd]5

mdadm: superblock on /dev/sdd5 doesn't match others - assembly aborted

 

 

J'ai aussi tenté un assemblage sans celui-ci .. du coup, je rencontre le 2ème problème qui fait que mon raid ne fonctionne pas :
 

root@ubuntu:~# mdadm -A -v -U resync -f /dev/md2 /dev/sd[abc]5

mdadm: looking for devices for /dev/md2
mdadm: /dev/sda5 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdb5 is identified as a member of /dev/md2, slot 3.
mdadm: /dev/sdc5 is identified as a member of /dev/md2, slot 0.
mdadm: Marking array /dev/md2 as 'clean'
mdadm: no uptodate device for slot 1 of /dev/md2
mdadm: added /dev/sda5 to /dev/md2 as 2
mdadm: added /dev/sdb5 to /dev/md2 as 3 (possibly out of date)
mdadm: added /dev/sdc5 to /dev/md2 as 0
mdadm: /dev/md2 assembled from 2 drives - not enough to start the array.


le slot 3 (sdb5) est (possibly out of date) ... De nouveau à patauger avec ce soucis où j'ai tenté pas mal de chose trouvé ça et là sur le net sans que ça fonctionne...


Resultats de la commande mdadm -E /dev/sd[abcd]5

 

/dev/sda5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 7db29d47:28555582:f5b4af6d:dfd0692f
           Name : ServeurBulok:2
  Creation Time : Fri Jul 14 00:28:46 2017
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5850870912 (2789.91 GiB 2995.65 GB)
     Array Size : 8776305792 (8369.74 GiB 8986.94 GB)
  Used Dev Size : 5850870528 (2789.91 GiB 2995.65 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=384 sectors
          State : active
    Device UUID : 8ff66057:6bfd3d3f:839d32d1:544a8e43

    Update Time : Wed Feb 17 10:45:25 2021
       Checksum : 683bca71 - correct
         Events : 212432

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 2
   Array State : .AA. ('A' == active, '.' == missing, 'R' == replacing)

---------------------------------------------------------------------------------

/dev/sdb5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x2
     Array UUID : 7db29d47:28555582:f5b4af6d:dfd0692f
           Name : ServeurBulok:2
  Creation Time : Fri Jul 14 00:28:46 2017
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5850870912 (2789.91 GiB 2995.65 GB)
     Array Size : 8776305792 (8369.74 GiB 8986.94 GB)
  Used Dev Size : 5850870528 (2789.91 GiB 2995.65 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
Recovery Offset : 325168136 sectors
   Unused Space : before=1968 sectors, after=384 sectors
          State : active
    Device UUID : 8fd03008:06cefdad:e63d4d85:e2d48743

    Update Time : Mon Feb 15 19:39:00 2021
       Checksum : 4f432592 - correct
         Events : 212296

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

---------------------------------------------------------------------------------

/dev/sdc5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 7db29d47:28555582:f5b4af6d:dfd0692f
           Name : ServeurBulok:2
  Creation Time : Fri Jul 14 00:28:46 2017
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5850870912 (2789.91 GiB 2995.65 GB)
     Array Size : 8776305792 (8369.74 GiB 8986.94 GB)
  Used Dev Size : 5850870528 (2789.91 GiB 2995.65 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=384 sectors
          State : clean
    Device UUID : 5a6fe851:b07eadc3:7f4d7a25:13177e3c

    Update Time : Sun Feb 14 20:08:03 2021
       Checksum : 346ad099 - correct
         Events : 212432

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

---------------------------------------------------------------------------------

/dev/sdd5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : fe7238e7:074459d5:13781f3e:2d99f6c4
           Name : ServeurBulok:2
  Creation Time : Wed Feb 17 11:13:05 2021
     Raid Level : raid1
   Raid Devices : 1

 Avail Dev Size : 15618390912 (7447.43 GiB 7996.62 GB)
     Array Size : 7809195456 (7447.43 GiB 7996.62 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : 4a1bfb12:7bda5602:44af046f:02bb0588

    Update Time : Wed Feb 17 14:45:44 2021
       Checksum : 9f789670 - correct
         Events : 10


   Device Role : Active device 0
   Array State : A ('A' == active, '.' == missing, 'R' == replacing)

 

Link to comment
Share on other sites

  • 0

Bonsoir,

Effectivement, avec 2 disques manquants (le fait de ne pas être à jour est similaire), pas moyen de reconstruire un raid.

Dans le lien donné, la commande est donné pour md127, c'est à dire un raid "sans disque" pour le moment.

En mettant md2, on force à insérer le disque dans une grappe existante, ce qui échoue à priori et l'ID n'est pas mis à jour.

J'essaierai avec md127, pour permettre la mise à jour de l'ID, puis ensuite de le réinsérer dans la grappe (stop du md127 et assemble sur md2 de tête).

 

Jacques

Link to comment
Share on other sites

  • 0

Je n'étais pas au courant de cette particularité ^^ ..

 

Grâce à ça, j'ai pu enfin changer l'UUID de sdd5 pour le faire correspondre aux autres.. malgré tout, il me le comptait séparément sans pouvoir y faire quoi que ce soit..

J'avais toujours ce message : mdadm: superblock on /dev/sdd5 doesn't match others - assembly aborted

 

 

Avec tout ça, il met toujours impossible de monter sdd5 dans un /dev/mdX . Quand aux 3 autres, même si je tente avec du resync  ça ne fonctionne pas ...

J'ai donc tenté l'inverse  ... Ajouter /dev/sd[abc]5 à /dev/md127 qui contenait /dev/sdd5   .. Je m'attendais déjà à ce que ça ne fonctionne pas. Mais pas pour les raison qu'il m'a donné :  Impossible de les ajouter car ils ne font pas la taille minimum (sdd5 faisant en 7To, et les autres 2.7 .. ).

 

 


Dans tout les cas, pour le moment, impossible de retrouver mes données ... du coup je tente ceci :
mdadm --create /dev/md2 -v -l 5 -n 4 /dev/sd[abcd]5

 

Réponse du bazar :
 

mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: /dev/sda5 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Jul 14 00:28:46 2017
mdadm: /dev/sdb5 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Jul 14 00:28:46 2017
mdadm: /dev/sdc5 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Jul 14 00:28:46 2017
mdadm: /dev/sdd5 appears to be part of a raid array:
       level=raid1 devices=1 ctime=Wed Feb 17 11:13:05 2021
mdadm: size set to 2925304320K
mdadm: automatically enabling write-intent bitmap on large array
mdadm: largest drive (/dev/sdd5) exceeds size (2925304320K) by more than 1%


Ce qui est logique on va dire ... j'ai hésité pendant 20 mn avant de mettre Y :/ ( le temps d'aller faire la vaiselle 😅 )..

Un petit cat /proc/mdstat

 

Personalities : [raid6] [raid5] [raid4]
md2 : active raid5 sdd5[4] sdc5[2] sdb5[1] sda5[0]
      8775912960 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      [>....................]  recovery =  1.7% (49997740/2925304320) finish=325.4min speed=147240K/sec
      bitmap: 0/22 pages [0KB], 65536KB chunk

 

et ensuite lsblk -f

 

NAME    FSTYPE            LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                          
├─sda1  linux_raid_member                fecd3204-82f8-65da-3017-a5a8c86610be                
├─sda2  linux_raid_member                e3045bdc-4fcf-0ef3-7da4-9ce7f43eed39                [SWAP]
├─sda5  linux_raid_member ubuntu:2       c6f9494f-ec08-65e4-0659-b5790913c2f1                
│ └─md2                                                                                      
└─sda6  linux_raid_member ServeurBulok:3 90318d27-94e7-eb14-07e5-21bbbdc21f46                
sdb                                                                                          
├─sdb1  linux_raid_member                fecd3204-82f8-65da-3017-a5a8c86610be                
├─sdb2  linux_raid_member                e3045bdc-4fcf-0ef3-7da4-9ce7f43eed39                [SWAP]
└─sdb5  linux_raid_member ubuntu:2       c6f9494f-ec08-65e4-0659-b5790913c2f1                
  └─md2                                                                                      
sdc                                                                                          
├─sdc1  linux_raid_member                fecd3204-82f8-65da-3017-a5a8c86610be                
├─sdc2  linux_raid_member                e3045bdc-4fcf-0ef3-7da4-9ce7f43eed39                [SWAP]
├─sdc5  linux_raid_member ubuntu:2       c6f9494f-ec08-65e4-0659-b5790913c2f1                
│ └─md2                                                                                      
└─sdc6  linux_raid_member ServeurBulok:3 90318d27-94e7-eb14-07e5-21bbbdc21f46                
sdd                                                                                          
├─sdd1  linux_raid_member                fecd3204-82f8-65da-3017-a5a8c86610be                
├─sdd2  linux_raid_member                e3045bdc-4fcf-0ef3-7da4-9ce7f43eed39                [SWAP]
└─sdd5  linux_raid_member ubuntu:2       c6f9494f-ec08-65e4-0659-b5790913c2f1                
  └─md2                                                                                      

 

 

Comme je m'en doutais, le raid a été recréé complet ... je pense pour cette fois, avoir définitivement écarté la possibilité de récupérer mes données ...

 

Si jamais tu as des solutions pour après  ( si ça existe) .. je suis preneur ^^

En tout cas, un enorme merci pour m'avoir déjà aiguillé jusque là :)

Link to comment
Share on other sites

  • 0

Bonsoir,

Si les données pouvaient être perdues... dans ce cas ce n'est pas trop risqué.

A voir une fois la reconstruction terminée, mais je serai surpris qu'on puisse y accéder.

Une fois le raid reconstruit, il 'y a plus rien à faire en principe, à part planifier des sauvegardes automatiquement pour les fichiers sensibles...

 

J'ai des erreurs d'écriture qui apparaissent sur un de mes 4 disques de 4To... je ne vais pas tarder à tester la reconstruction je crois.

On en revient toujours au même point, les sauvegardes sont essentielles.

 

Personnellement, mon NAS le sert à stocker des sauvegardes, donc pas trop critique, des livres et BD au format électronique, des photos et des films.

Les 3 dernières catégories sont des doublons  (ou pratiquement) des données présentes sur mon PC (j'ai pas mal de stockage au final).

Pas à l'abri d'un incendie, mais d'une casse de disque en grande partie en principe.

Les données vraiments critiques sont aussi dans le cloud.

 

Bonne fin de journée

Jacques

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...