Volume dégradé

[Bolitar]

Bonjour, 

Je possède un DS214Play sur le quel sont montés 2 disques WD Green Desktop 2 To SATA 6Gb/s de juin 2014, sans le moindre souci jusqu'ici.

Cet après-midi après un reboot il se met à "bipper" et la led "status" à clignoter.

Je parviens malgré tout à me connecter et avoir accès à l'interface. Je vois que le volume est dégradé, je tente une réparation comme proposé. Rien y fait. J'ai parcouru la doc de Synology ainsi que ce forum, notamment le fil suivant: 

Malheureusement je n'ai pas de PC pour effectuer un test SMART comme conseillé. Le gestionnaire de stockage de DSM semble le proposer. Un test rapide donne un résultat concluant sans relever d'anomalie. Un test poussé peut-il en valoir la peine? Risque de détériorer un peu plus le disque, son voisin ou le NAS?

Forcément cela arrive un samedi et avant lundi je n'aurai aucun moyen de me procurer un nouveau disque, mais toujours le besoin d'avoir accès aux données (qui sont toujours accessibles mais plus protégées par le protocole RAID je suppose). Y a-t-il à ce stade autre chose à faire que de remplacer le disque n°2 par un nouveau? Que signifie le statut "initialisé"?

Dans l'attente de vos réponses le NAS est éteint et je retire le disque n°2 comme cela est conseillé. Je joins un screenshot pour étayer la situation.

Merci pour l'attention portée.

 

[gaetan.cambier]

Fait deja un test smart rapide via le nas, post le detail smart et on verra ensuite

[Bolitar]

Bonjour Gaetan, 

Merci pour le coup de main. 

Test SMART effectué, mais je ne sais pas où trouver le rapport. Ce que j'obtiens:

Autres infos trouvées:

 

J'espère que c'est de cela dont il est question.

 

[gaetan.cambier]

bon, il semble clean

on peux le rajouter en ligne de commande ...

ouvre une session en ssh et tape les commande suivantes (et colle nous ce que ca renvoit):

fdisk -l /dev/sda
fdisk -l /dev/sdb
pvdisplay
vgdisplay
lvdisplay
cat /proc/mdstat

on en saura + avec tout cela ;) 

[Bolitar]

Je ne parviens pas à me logger en "root", ce qui semble pourtant indispensable pour les commandes soumises. 

En "admin" ça passe, et en utilisant le même password pour root il me renvoie un "Permission denied".

Je suis peu initié à ces manipulations, un coup de main serait le bienvenu :)

Modifié le 16 avril 2016 par Bolitar

[gaetan.cambier]

Dsm 5.2 ou 6.0 ?

[Bolitar]

DSM 6.0-7321

[Bolitar]

J'ai finalement trouvé: la sécurité pour accéder en root en Ssh semble avoir été augmentée avec le passage au DSM 6.0. Une page de Synology l'explique très bien ici (en imaginant que cela puisse servir à d'autres):

https://www.synology.com/en-us/knowledgebase/DSM/tutorial/General/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet

 

Pour en revenir à mon problème, voici ce que donne l'entrée des commandes proposées:

root@****:~# fdisk -l /dev/sda

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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

Disklabel type: dos

Disk identifier: 0x00017c97

 

Device     Boot   Start        End    Sectors  Size Id Type

/dev/sda1           256    4980735    4980480  2.4G fd Linux raid autodetect

/dev/sda2       4980736    9175039    4194304    2G fd Linux raid autodetect

/dev/sda3       9437184 3907024064 3897586881  1.8T fd Linux raid autodetect

root@****:~# fdisk -l /dev/sdb

Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 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

Disklabel type: dos

Disk identifier: 0x0000543d

 

Device     Boot   Start        End    Sectors  Size Id Type

/dev/sdb1           256    4980735    4980480  2.4G fd Linux raid autodetect

/dev/sdb2       4980736    9175039    4194304    2G fd Linux raid autodetect

/dev/sdb3       9437184 3907024064 3897586881  1.8T fd Linux raid autodetect

root@****:~# pvdisplay

root@****:~# vgdisplay

root@****:~# lvdisplay

root@****:~# cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 

md2 : active raid1 sda3[1]

      1948792256 blocks super 1.2 [2/1] [_U]

      

md1 : active raid1 sda2[0] sdb2[1]

      2097088 blocks [2/2] [UU]

      

md0 : active raid1 sda1[1] sdb1[0]

      2490176 blocks [2/2] [UU]

      

unused devices: <none>

 

Encore merci pour l'attention apportée.

 

Du coup quelqu'un saurait-il interpréter ces résultats? Gaëtan? :)

Modifié le 17 avril 2016 par Bolitar

[gaetan.cambier]

comme convenu, je passe ;)

voici la commande "magique" pour remonter le raid :

mdadm --manage /dev/md2 --add /dev/sdb3

ensuite, tu verra dans l'interface graphique (en théorie) qu'il repare le raid dans le gestionnaire de volume

si pas, tu peux toujours suivre l'évolution en tapant cette commande autant de fois que tu veux :

cat /proc/mdstat

il y aura un temps restant estimé, ca te donnera une iddée ;)

[Bolitar]

Un très grand merci, la manip semble fonctionner à merveille!

Synchronisation en cours afin de vérifier la cohérence de la parité entre les 2 disques est en cours. Les voyants sont donc au vert. 

Je reviendrai confirmer le bon déroulement une fois terminée.

Merci encore!

[Bolitar]

Comme convenu voilà un retour final: tout est rentré dans l'ordre! Encore un grand merci à gaetan.cambier pour son expertise et ses conseils avisés. 

Sujet à clore.