[Résolu] Dure fin de nuit... - RAID 5 HS sur Synology DS412+

[JeanSimon]

Bonjour à tous (ou bonsoir au choix).

 

Je suis nouveau dans le coin, et apparemment c'est le forum le plus proche des NAS Synology.

Comme vous vous en doutez j'arrive avec une bien triste nouvelle que j'ai découvert à mon retour chez moi, mon NAS m'a laché!...

 

Plus exactement et précisément:

Mon RAID 5 de 4 disques 3To monté sur un SynologyNAS était à 87% quand je me suis connecté ce matin. Ou plutôt hier matin.

Du coup je me suis dis que j'allais le vider un peu. J'ai vidé plein de choses inutiles et (environ 5 ou 700Go), et j'ai trouvé un vieux disque 2To sur lequel j'avais envisagé d'archiver environ 1,5To de données.

Au passage ce matin aussi mon disque 4 s'était mis en erreur et avait dégradé mon RAID ce qui a motivé ma "maintenance".

J'avais néanmoins pu le ré-attacher et tout était revenu dans l'ordre.

 

Une fois mon ménage fini je connecte mon HDD 2To à mon PC sur un dock USB2 et lance la copie qui m'annonce de mémoire une dizaine d'heure.

Je m'absente pour la journée afin qu'il puisse travailler transquille, sauf qu'à mon retour mon NAS bip dans tous les sens.

En m'approchant je constate 2 diodes de disques en erreur...

Une fois connecté j'ai le merveilleux message que je ne vous souhaite pas (en pj).

 

J'ai essayé de voir s'il n'y avais pas moyen de lancer une réparation, un check des 2 disques en question mais rien à faire.

Pour info, et bizarrement, les 2 disques HS sont les 2 disques Western Digital de mon NAS. Les 2 autres sont des Seagate et n'ont rien à signaler.

Pour voir j'ai retiré 1 des 2 disques en erreur (celui qui l'avait été le matin) et je l'ai remis (tout ça à chaud, ça ne le gène pas normalement).

Au début il n'a pas voulu le reconnaitre plus que ça, j'ai donc redémarrer le NAS proprement par l'interface et la il est apparu comme prêt à l'emploi, mais quand même il était impossible de l'ajouter à mon volume (qui du coup à diminuer en taille!).

 

Mes questions sont donc les suivantes, et si vous pouviez m'aider je vous en serait trèèèèès reconnaissant! :

- Qu'est-ce que je peux faire?

- Est-ce qu'il y a un moyen "normal" et pas trop risqué de récupérer les données à travers le NAS?

- Est-ce qu'il y a à défaut un moyen pas trop risqué de récupérer les données hors du NAS?

- Et vraiment si pas le choix... Vous connaissez des sociétés qui savant faire ça sans me couter un bras et demi?

 

 

Merci d'avance à tout pour votre aide et bonne fin de nuit!

 

PS: Je vous met aussi les autres captures de l'état actuel du stockage sur NAS. Pour info je l'ai éteint en attendant de savoir ce que je vais faire.

Modifié le 28 septembre 2015 par JeanSimon
problème résolu

[marcien]

Lors de la premiere alerte, tu aurais du stopper son Syno et changer le DD défaillant, afin que tout le RAID se reconstruise.

Tu as du acheter tout des DD en meme temps (quelle année ?), ils ont peut etre la meme date de fabrication , donc théoriquement une date de casse identiques...

Ta copie d'écran montre 1 seul DD "en panne". Les données doivent pouvoir etre récupéré. Entre changer le DD et backupé les data en externe, je ne sais pas ce qui va soliciter le moins les autres DD du RAID...

Malheureusement, le RAID5 c'est juste de la continuité de service, pas du backup !!! Faut les données sur un autre support...

Modifié le 6 septembre 2015 par marcien
oubli sur le RAID5

[gaetan.cambier]

Moi, si j'ai bien compris, le disk3 à été éjecté du raid, puis il a tente de reconstruire.

Pendant la reconstruction, le disk4 est tombé en panne --> pour moi, c'est pas récupérable

[marcien]

Gaetan, si tu as bien résumé, oui, ça sent la perte de data. Mais jusqu’à quel moint ?

[JeanSimon]

Salut à tous.

Attention, lors de la première alerte du matin, il m'a direct proposé de faire une vérification du disque, chose que j'ai fait, il a vu que tout était ok et il l'a remis dans le RAID.

Après ça tout était parfaitement normal.

 

Pour ce qui est de l'origine des disques et de leur age, ils datent tous d'Octobre 2013, acheté tous en même temps et de 2 marques différentes.

2 Western Green (les 2 en panne) et 2 Seagate qui sont ok. J'avais justement mixé pour éviter ce genre de chose mais bon visiblement c'était pas assez mixé...

 

Et pour te répondre Gaetan, les 2 WD ont été déclarés en panne, et lorsque j'ai sorti puis remis celui qui était en panne le matin en espérant qu'il tente une reconstruction, il l'a carrément éjecter du RAID au final. D’où la présence de 3 disques uniquement dans ma capture.

Mais la précédente reconstruction du matin s'était bien déroulé, tout était 100% fonctionnelle après.

 

Est-ce qu'il n'y a pas un moyen de brancher tout ça en externe pour tenter de récupérer les données?

[gaetan.cambier]

En 1 matinée, un test Disk et une reconstruction raid ...

[JeanSimon]

En 1 matinée, un test Disk et une reconstruction raid ...

C'est aussi ce que je me suis dis.

Le test c'était la version rapide, et le RAID par contre il ne me l'a pas mis en reconstruction, il m'a juste dis que tout est était ok comme s'il l'avais fait revenir dans la boucle sans avoir besoin de reconstruire.

En tout cas je suis certain qu'il n'y a eu aucune reconstruction de faite.

La dernière fois que j'avais eu ce genre de soucis (il y a 1 an je crois), c'était plus grave, j'avais vraiment du sortir le disque, le formater le remettre, le réinitialiser, le re-ajouter au RAID et faire une reconstruction pour que tout sois ok.

Là c'était plus un truc du genre merci d'éteindre et de rallumer, et tout était ok. Maintenant que tu le dis je me rends compte que c'est bizarre mais sur le coup j'ai pas fais gaffe...

[Einsteinium]

Exécute en ssh la commande suivante : 

cat /proc/mdstat

Et colle le résultat ici, fait aussi un imprimé écran des valeurs smart de ton hdd3, car il est peu être encore possible de le réinjecté manuellement est mettre ton raid en lecture, tu pourras récupèrer presque toutes tes données ainsi avec de la chance.

[JeanSimon]

Du coup il faut que je sorte le disque et que je fasse ça dans un Linux ou je peux le faire en ssh directement sur le NAS?

[Einsteinium]

En ssh sur le nas bien sur ;-)

[JeanSimon]

Voici la réponse :

 

DMZ-07> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdc3[2](E) sdb3[4]
      8776632768 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UUE_]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      2490176 blocks [4/4] [UUUU]

 

[Einsteinium]

Ok parfait, alors tape les deux commandes suivantes et colle moi le résultat de la seconde :

mdadm --stop /dev/md2

mdadm --assemble --verbose /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3

[JeanSimon]

Ok parfait, alors tape les deux commandes suivantes et colle moi le résultat de la seconde :

mdadm --stop /dev/md2

mdadm --assemble --verbose /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3

Désolé, j'ai oublié une ligne dans mon premier collage de résultat.

Après le paragraphe md0 il y avait ça

 

unused devices: <none>

 

Est-ce que ça change quelque chose?

[JeanSimon]

Bon, j'ai cherché un peu sur l'internet et j'ai vu que ça changeais rien cette ligne.

 

Par contre quand j'ai voulu taper la première commande il m'a demandé une élévation de droit pour pouvoir le faire.

Et quand j'ai voulu me mettre en root je me suis heurté au problème "su: must be suid to work properly"

Internet aussi m'a bien aidé j'ai réussi à m'en débarrasser et maintenant je suis en root et j'ai tapé la commande mais j'ai le message suivant :

 

DMZ-07> mdadm --stop /dev/md2
mdadm: failed to stop array /dev/md2: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?

 

J'ai trouvé des trucs pour "forcer" un démontage mais j'ai trouvé ça un peu délicat donc je préfère agir avec approbation...

Et la commande lsof n'étant pas reconnu, je ne sais pas comment savoir/vérifier quel est le fichier qui est actuellement utilisé et bloque le démontage...

 

PS: même après un reboot j'ai le même message d'erreur au passage.

Modifié le 6 septembre 2015 par JeanSimon
ajout précision

[Einsteinium]

Le but final va être de remonter ton raid avec trois disque, 2 bon et le dernier déclarer en erreur afin que tu puisse accéder à tes données, je les déjà fait avec succès.

donc oui force le stop et donne moi le résultat de la seconde commande.

ps : va falloir arrêté de reboot par contre, car quand ton disque 3 sera cuit comme le 4, la cela sera bien mort...

[JeanSimon]

C'est noté.

Par contre avec quelle commande je dois le forcer? Parce-que j'ai vu plein de trucs différents et je ne sais pas vraiment laquelle est le plus adapté à mon cas...

[gaetan.cambier]

Le but final va être de remonter ton raid avec trois disque, 2 bon et le dernier déclarer en erreur afin que tu puisse accéder à tes données, je les déjà fait avec succès.

donc oui force le stop et donne moi le résultat de la seconde commande.

ps : va falloir arrêté de reboot par contre, car quand ton disque 3 sera cuit comme le 4, la cela sera bien mort...

ne force pas, passe en mode debug avec cette commande :

syno_poweroff_task -d

meme si je crois pas trop sur le fait de recupérer les data, au moin, la, tu aura + de chance

[JeanSimon]

Bon! J'ai tout fait!

Pour l'instant il réponds (sur l'interface web), le voyant status clignote en orange, le voyant pour le disque 3 est toujours orange mais s'est stabilisé en orange fixe.

J'attends...

 

Voici le résultat des commandes :

 

DMZ-07>  mdadm --stop /dev/md2
mdadm: failed to stop array /dev/md2: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?
DMZ-07>
DMZ-07>
DMZ-07> syno_poweroff_task -d
DMZ-07> man syno_poweroff_task
-ash: man: not found
DMZ-07>
DMZ-07> mdadm --stop /dev/md2
mdadm: stopped /dev/md2
DMZ-07>
DMZ-07> mdadm --assemble --verbose /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: device 2 in /dev/md2 has wrong state in superblock, but /dev/sdc3 seems ok
mdadm: added /dev/sdb3 to /dev/md2 as 1
mdadm: added /dev/sdc3 to /dev/md2 as 2
mdadm: no uptodate device for slot 3 of /dev/md2
mdadm: added /dev/sda3 to /dev/md2 as 0
mdadm: /dev/md2 has been started with 3 drives (out of 4).
DMZ-07>

 

PS: Ou est-ce que j'peux avoir un descriptif de toutes ces commandes?

Parcequ'il n'y a pas de man dans le syno et je trouve pas de gros manuel en ligne non plus...

 

 

J'ajoute que j'ai fais un autre test juste pour voir si le message avait changé

DMZ-07> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdc3[2](E) sdb3[4]
      8776632768 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UUE_]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      2490176 blocks [4/4] [UUUU]

unused devices: <none>
DMZ-07>

 

Bon. J'ai toujours aucune réaction et le syno n'est joignable par aucun autre moyen que la fenetre SSH sur laquelle je suis.

J'ai voulu voir s'il était en plein job donc j'ai fais un sfdisk et voici le résultat. (j'ai comme l'impression qu'il a planté...

 

DMZ-07> sfdisk -l
/dev/sda1                   256         4980735         4980480  fd
/dev/sda2               4980736         9175039         4194304  fd
/dev/sda3               9437184      5860528064      5851090881  fd

/dev/sdb1                   256         4980735         4980480  fd
/dev/sdb2               4980736         9175039         4194304  fd
/dev/sdb3               9437184      5860528064      5851090881  fd

/dev/sdc1                   256         4980735         4980480  fd
/dev/sdc2               4980736         9175039         4194304  fd
/dev/sdc3               9437184      5860528064      5851090881  fd

/dev/sdd1                   256         4980735         4980480  fd
/dev/sdd2               4980736         9175039         4194304  fd
/dev/sdd3               9437184      5860528064      5851090881  fd

/dev/md01                     0         4980351         4980352   0

/dev/md11                     0         4194175         4194176   0

/dev/md21                     0     17553265535     17553265536   0

Error: /dev/zram0: unrecognised disk label
get disk fail

Error: /dev/zram1: unrecognised disk label
get disk fail

Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)?
Warning: Not all of the space available to /dev/synoboot appears to be used, you can fix the GPT to use all of the space (an extra 25600 blocks) or continue with the current setting?
/dev/synoboot1               63           32129           32067  ef
/dev/synoboot2            32130          224909          192780  ef

DMZ-07>

 

Modifié le 7 septembre 2015 par JeanSimon
ajout test

[JeanSimon]

J'ai essayé de chercher à gauche à droite par rapport aux différents messages que j'ai eu et apparemment il faudrait que je reconstruise le "superblock" et que je vérifie le tout avec "fsck.ext4".

Est-ce que vous approuvez? Vous pouvez me dire comment utiliser ces commandes si c'est le cas?

Et du coup il faut que je redémonte le RAID? Actuellement le NAS est toujours avec la diode status orange clignotante et il ne réponds à rien d'autre qu'au SSH...

 

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

 

Au passage j'ai aussi tenté la carte "récupération en laboratoire" et j'ai contacté plusieurs boites françaises pour avoir un devis gratuit après leur avoir expliqué le problème.

C'est... cher! Très cher même!!! Pour un RAID5 on est en gros entre 1500 et 3.000€ pour un particulier. C'est un petit prix spécial. Pour les sociétés il faut ajouter 20% voir plus si des contraintes de temps sont à prendre en compte.

Il y en a juste 1 qui m'a proposé d'utiliser leur logiciel pour faire le taf chez moi dans un premier temps (si ça marche).

Je préfère essayer dans un premier temps directement sur le NAS et voir après avec leur logiciel si ça n'aboutie.

 

Ce qui est sur c'est qu'on ne m'y reprendra pas!!!

Avec mes pauvres connexion internet précédente j'avais oublié le fait de prendre en compte le cloud pour des envois enTo mais maintenant que je suis fibré c'est tout à fait envisageable et je suis prêt à dégainer ma CB pour un abo hubic dès que (si) je remet la main sur mes DATAs!

 

Tout ça avec votre aide bien sur. =)

Modifié le 7 septembre 2015 par JeanSimon
lisibilité

[gaetan.cambier]

PS: Ou est-ce que j'peux avoir un descriptif de toutes ces commandes?

pour les commande standart man + nom de la commande dans google

pour les commande speciale syno, faudra nous faire confiance principalement, c'est très peu documenté, parfois l'option -h donne quelque renseignement mais sans plus

pour revenir à ton problème :

faut surtout pas se essayer tout et n'importe quoi, et un fsck n'est pas forcement une bonne iddée, vu que on est pas sur de l'etat du raid, vaut mieux :

essayer de redemarrer le raid

monter la partition en Read only

tout souvegarder ailleur

et ensuite repartir sur des bonne base

 

bref, pour commencer : j'aimerai savoir l'etat du raid :

cat /proc/mdstat

 

Bon. J'ai toujours aucune réaction et le syno n'est joignable par aucun autre moyen que la fenetre SSH sur laquelle je suis.

c'est tout a fait normal, le syno est en mode debug, tous les service sont coupé souf ssh, les partitions (volume1, ...) sont demontées, mais tant que le ssh fonctionne, c'est parfait pour nous

Modifié le 7 septembre 2015 par gaetan.cambier

[JeanSimon]

pour les commande standart man + nom de la commande dans google

pour les commande speciale syno, faudra nous faire confiance principalement, c'est très peu documenté, parfois l'option -h donne quelque renseignement mais sans plus

Ok c'est noté.

 

 

 

pour revenir à ton problème :

faut surtout pas se essayer tout et n'importe quoi, et un fsck n'est pas forcement une bonne iddée, vu que on est pas sur de l'etat du raid, vaut mieux :

essayer de redemarrer le raid

monter la partition en Read only

tout souvegarder ailleur

et ensuite repartir sur des bonne base

 

bref, pour commencer : j'aimerai savoir l'etat du raid :

cat /proc/mdstat

 

c'est tout a fait normal, le syno est en mode debug, tous les service sont coupé souf ssh, les partitions (volume1, ...) sont demontées, mais tant que le ssh fonctionne, c'est parfait pour nous

Ok pour moi.

J''ai qu'un envie c'est de sauvegarder! ^^

 

Résultat de la commande :

DMZ-07> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdc3[2](E) sdb3[4]
      8776632768 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UUE_]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      2490176 blocks [4/4] [UUUU]

unused devices: <none>
DMZ-07>

 

[gaetan.cambier]

ce E m'interpelle, d'habitude, j'ai soit un disque reconnu (U) soit un disque absent (_) mais le (E) ...

bref, on va commencer pas le + simple : tenter de monter tout simplement la partition en readonly

si ca fonctionne tant mieux, si ca fonctionne pas, de toute facon, ca ne change rien sur les disque

mount -o ro /dev/md2 /volume1

si tu as une erreur tu fait :

tail /var/log/messages

si tu n'a pas d'erreur, tu nous fait :

ls -l /volume/

comme toujours, tu copie colle tout ici (si tout reussis, pas besoin de nous collé ta liste de fichier par contre )

[Einsteinium]

Le superblock semble corrompus donc, alors re stop le md2 et cette fois on force :

mdadm --assemble --verbose --force /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3

colle le résultat et donne aussi le résultat d'un cat /proc/mdstat 

Si cela passe on monte le volume... Voir un fsck avant

@gaetan t'inquiète je donne pas des commandes au hasard ;-)

Modifié le 7 septembre 2015 par Einsteinium

[gaetan.cambier]

@gaetan t'inquiète je donne pas des commandes au hasard ;-)

non, je sais bien, je disait ca à jean car les question défillais et c'est souvent là que on test n'importe quoi

perso, je monterai le volume en ro sans fsck, sans savoir dans quel etat est le raid (probablement en cours de reconstruction qd tout a merdé), vaut mieux essayer de recuperer d'abord

[JeanSimon]

ce E m'interpelle, d'habitude, j'ai soit un disque reconnu (U) soit un disque absent (_) mais le (E) ...

bref, on va commencer pas le + simple : tenter de monter tout simplement la partition en readonly

si ca fonctionne tant mieux, si ca fonctionne pas, de toute facon, ca ne change rien sur les disque

mount -o ro /dev/md2 /volume1

si tu as une erreur tu fait :

tail /var/log/messages

si tu n'a pas d'erreur, tu nous fait :

ls -l /volume/

comme toujours, tu copie colle tout ici (si tout reussis, pas besoin de nous collé ta liste de fichier par contre )

Dans l'ordre.

Le "UUE_" Je trouve ça logique vu qu'actuellement il voit le dernier disque comme étant hors du RAID donc le _, et il voit le 3ème disque en erreur; d'ou le E.

Les 2 premiers étant clean, RAS.

J'me trompe?

 

Pour les commandes, c'est fait!

Aucune erreur par contre 2 choses!

D'une part j'ai bien une liste de fichier qui apparait et ce sont bien mes fichiers mais pas tout.

Mais bizarrement, avant de faire "mdadm --stop /dev/md2" je voyait déjà cette liste de fichier quand je faisais un "ls -l" sur un dossier, mais je sais plus lequel exactement...

Quand je dis que je vois une liste de fichier c'est à dire que je vois les partages classiques qui étaient fait sur le RAID.

 

On en arrive au 2ème truc, qui est que j'utilisais principalement un disque iSCSI.

 Mais mes principales données sont dessus.

Quand j'ai listé les données du dossier volume1 j'ai vu qu'il y en avait un qui s'appelle "@iSCSITrg" (ça sonne bien) donc je suis allé dedans et j'ai trouvé "iSCSI_1_Extent_LUN-HDD_000" qui corresponds au nom de la target que j'avais fait.

Par contre pour pouvoir la monter faut pas que je sorte du mode debug? Ou winscp sais monter ça?

 

Le superblock semble corrompus donc, alors re stop le md2 et cette fois on force :

mdadm --assemble --verbose --force /dev/sda3 /dev/sdb3 /dev/sdc3

colle le résultat et donne aussi le résultat d'un cat /proc/mdstat 

Si cela passe on monte le volume... Voir un fsck avant

@gaetan t'inquiète je donne pas des commandes au hasard ;-)

C'est ce qui m'a semblé aussi pour le superblock.

Par contre comme j'ai déjà fais les commandes de gaetan, le volume est pas déjà monté justement?

Les commandes que tu m'a donné sont pour corriger le superblock?