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

[gaetan.cambier]

vu que tu y a acces a tes fichier :

winscp ou disque usb pour tous recup

les iscsi sont en mode fichier --> si les fichier sont intact, ils seront exploitable par la suite

[JeanSimon]

Petite précision, je me suis connecté avec winscp pour mieux voir et effectivement c'est bien ce que je disais, j'ai accès aux dossier qui étaient partagé sur le NAS sans problème.

Concernant mon disque iSCSI je l'ai bien trouvé dans le dossier indiqué plus haut par contre il est en "brut", c'est à dire que c'est un gros fichier de 5To (la taille du disque que j'avais fait), mais bien sur comme ça, impossible de le monter et je suis quasiment certain que si j'essaye de copier le bloc ça va planter...

Petite question, est-ce que si j'efface des données des partages classiques ça pourrais éventuellement améliorer la situation? (vu que le NAS était plein à 80% avant de planter)

 

----

 

vu que tu y a acces a tes fichier :

winscp ou disque usb pour tous recup

les iscsi sont en mode fichier --> si les fichier sont intact, ils seront exploitable par la suite

Ca veut dire quoi les iSCSI sont en mode fichier?

Que je peux le copier et l'exploiter par la suite si la copie (entière) se passe bien?

Modifié le 7 septembre 2015 par JeanSimon
lisibilité

[Einsteinium]

Ba le soucis c'est que tu es trop pressé, un peu comme le dit Gaëtan.

moi je ferais cette commande puis un fsck, enfin le montage normale.

 

car dans le cas présent tu va récupérais des fichiers oui... Mais pas forcément exploitable ;-)

donc à toi de voir.

[JeanSimon]

Ba le soucis c'est que tu es trop pressé, un peu comme le dit Gaëtan.

moi je ferais cette commande puis un fsck, enfin le montage normale.

 

car dans le cas présent tu va récupérais des fichiers oui... Mais pas forcément exploitable ;-)

donc à toi de voir.

Donc pour toi il faudrait que je fasse les commandes que tu m'as donné et que je ne tienne pas compte de cet accès partiel alors?

 

Donc on parle bien des commandes suivantes :

mdadm --stop /dev/md2

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

/proc/mdstat

puis

fsck

J'ai rien loupé?
Pour la commande mdadm par contre c'est pas précisé dans celle que tu m'a pas envoyé "/dev/md2".
C'est normal?

Il faudra pas aussi que je passe par un unmount avant de faire le premier stop? ou il est implicite?

 

 

[Einsteinium]

Exact un oubli !

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

et oui fait un umount avant bien sûr, pourble reste c'est tout bon.

[JeanSimon]

C'est noté!

J'ai quand même copié 2-3 trucs important qui trainaient et j'ai lancé le tout.

 

Pour le fsck, la commande n'existe pas en tant que tel sur les syno, j'ai donc trouvé son équivalent en demandant à Gogole.

Par contre le test est toujours en cours depuis 5min, je pense que ça doit être normal non?

Par contre, il va ptet falloir que je sorte le syno de ce mode debug si je veux l'utiliser pour de vrai je pense. C'est quoi la commande?

 

Sinon voila le résultat :

DMZ-07>
DMZ-07> umount /volume1
DMZ-07> mdadm --stop /dev/md2
mdadm: stopped /dev/md2
DMZ-07> mdadm --assemble --verbose --force /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: clearing FAULTY flag for device 2 in /dev/md2 for /dev/sdc3
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>
DMZ-07> /proc/mdstat
-ash: /proc/mdstat: Permission denied
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> fsck
-ash: fsck: not found
DMZ-07> e2fsck
Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
                [-I inode_buffer_blocks] [-P process_inode_size]
                [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
                [-E extended-options] device

Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external_journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list
DMZ-07> e2fsck -nvf
Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
                [-I inode_buffer_blocks] [-P process_inode_size]
                [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
                [-E extended-options] device

Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external_journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list
DMZ-07> e2fsck -nvf /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes

 

Enfait je viens de me rendre compte que la commande que j'ai utilisé n'est pas la bonne mais j'arrive pas à arrêter le premier test.

J'ai donc lancé un autre test dans une autre fenêtre :

DMZ-07> fsck.
fsck.ext3     fsck.ext4     fsck.hfsplus
DMZ-07> fsck.
fsck.ext3     fsck.ext4     fsck.hfsplus
DMZ-07> fsck.ext4 /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.42.6-3776: is cleanly umounted, 422485/274272256 files, 1883956891/2194158192 blocks
DMZ-07>

 

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

 

Quelqu'un sait comment on arrête e2fsck ?

DMZ-07> e2fsck -nvf /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
^C^C^X^C^

(commande toujours en cours)

 

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

C'est bon l'annulation a bien été prise en compte.

 

Par contre je fais quoi maintenant?

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

Je biens de me rendre compte que j'avais fait le cat avant de faire le check disque donc je remet le résultat de maintenant

 

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>

 

Modifié le 7 septembre 2015 par JeanSimon
ajout 2eme commande

[Einsteinium]

Plutôt comique... Le disque 3 est encore en erreur alors que : clearing FAULTY flag for device 2 in /dev/md2 for /dev/sdc3

Essaye un reboot et de force de nouveau voir...

Sinon c'est plutôt : fsck.ext4 -n -v /dev/md2

Mais faut être patient que cela ce termine, après tu mount en volume1 pour la récupération de tes données ;-)

[JeanSimon]

Plutôt comique... Le disque 3 est encore en erreur alors que : clearing FAULTY flag for device 2 in /dev/md2 for /dev/sdc3

Essaye un reboot et de force de nouveau voir...

Sinon c'est plutôt : fsck.ext4 -n -v /dev/md2

Mais faut être patient que cela ce termine, après tu mount en volume1 pour la récupération de tes données ;-)

Pourquoi c'est comique étant donné que c'est le sdC?

J'ai l'impression que c'est le disque 3 physiquement mais qu'il l'a pris dans le RAID comme étant le disque 2 j'me trompe?

 

Mais le fsck.ext4 -n -v /dev/md2 je viens de le refaire mais il est très rapide, genre même pas 30 secondes. Il manque rien à la commande?

Je remet les résultats :

DMZ-07> fsck.ext4 /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.42.6-3776: is cleanly umounted, 422485/274272256 files, 1883956891/2194158192 blocks
DMZ-07> fsck.ext4 -n -v /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.42.6-3776: is cleanly umounted, 422485/274272256 files, 1883956891/2194158192 blocks
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>

 

[Einsteinium]

Bon monte ton volume est récupère les données que tu peux... Et détruit puis refait ton volume, le plus simple, mais montre les valeurs smart de ton disque 3, voir l'état, la après c'est sinon c'est des commandes un brin plus trash, mais il faudrait faire un backup des disques avant manipulation (etc etc..)

Pour en avoir le cœur net de sa place tu peux faire :

mdadm --detail /dev/md2

Mais non il est bien en position 3 ton sdc et c'est lui en erreur. (sdc3[2](E))

[JeanSimon]

D'accord mais comment je fais pour monter mon iSCSI? Vu que c'est dessus que son stockés toutes les données vraiment importantes.

Sachant que pour l'instant je ne le vois que sous la forme d'un gros fichier de 5To à travers ssh...

 

 

Par contre je ne remonterais surement pas mon RAID avec ces 2 WD dedans ça c'est sur!!!

Ils sont beaucoup trop volatiles, je peux pas leur faire confiance. Et puis ils ont peut-être bien un problème après tout.

Vous avez des marques ou des types de disque préféré pour les NAS ofait?

[Einsteinium]

http://forum.synology.com/enu/viewtopic.php?f=39&t=53945

Voila une solution, qui correspond bien à ton problème, fait un retour.

 

WD je dirais qu'ils sont les plus fiables d'après ce que je vois... Je te déconseille les Seagates en tout cas... J'ai eu triple mort il y a peu... Mais quand je dis mort... C'est physiquement sans aucun procès... Heureusement pour moi je backup... J'ai eu que la vidéo à reprendre et de vieux zip de backup de PC que j'utilisais plus depuis plusieurs années.

[JeanSimon]

http://forum.synology.com/enu/viewtopic.php?f=39&t=53945

Voila une solution, qui correspond bien à ton problème, fait un retour.

 

WD je dirais qu'ils sont les plus fiables d'après ce que je vois... Je te déconseille les Seagates en tout cas... J'ai eu triple mort il y a peu... Mais quand je dis mort... C'est physiquement sans aucun procès... Heureusement pour moi je backup... J'ai eu que la vidéo à reprendre et de vieux zip de backup de PC que j'utilisais plus depuis plusieurs années.

Je manquerais pas de faire un retour ça c'est sur! Même un tuto s'il faut!

 

Pour le coup moi c'est le cas inverse. Ce sont mes WD qui m'ont laché et mes seagate qui sont toujours la sans broncher.

Est-ce que les gammes peuvent avoir quelque chose à voir dans tout ça? (j'avais pris des WD green)

[Einsteinium]

Bof tu sais... Voila l'effet de production de masse... La qualité n'est plus la... J'ai encore un 10Go qui marche au quart de tour...

les Seagates n'ont pas bronché pendant presque deux ans, puis 1 mois avant la fin de garantie... Des secteurs en attente de realloc, puis certains déclarer OUT est finalement après 2 semaines sans prévenir... Timeout... Bref j'ai eu la chance de pouvoir faire les SAV à temps... Par contre faute d'accès, car j'avais quelques trucs hors cryptage (quelques photos, dossier web...), j'ai passer les disques dur à l'electro aimant... La j'étais sur du résultat, les disques n'était même plus visible au bios x)

par contre avec un triple sav à un mois de la garantie, j'ai été sélectionné pour un test laboratoire, prolongation de deux semaine... Mais test avec succès. Mais bon 1 mois de sav au final... Et Seagates tu prends à ta charge les frais de port.

[JeanSimon]

Ouais en gros vu comme ça, je prends n'importe quel marque et ça revient au même au final, ce sera au petit bonheur la chance...

 

Une question tiens. Je suis en train d'essayer de comprendre la procédure que tu m'a linké pour l'adapter à mon cas.

Par contre je me posais la question. Ce tuto va m'aider à monter mon iSCSI "manuellement" si j'ai bien compris, mais je vais donc bien devoir remettre mon NAS dans un état normal? Ou je peux faire ça en mode debug?

Si je dois le remettre en mode normal, comment je fais pour le sortir du mode debug?

[Einsteinium]

Oui tu as tout compris ! fait le en debug.

[JeanSimon]

Mais comment je monte un iSCSI en debug vu que le Syno n'est joignable qu'en SSH?

[Einsteinium]

Mais aussi par sftp par la même occasion ;-)

[JeanSimon]

Bon! Je reviens!

J'ai pris le temps de copier ce que je pouvais qui était en partage avant de tenter la dernière manip sur l'iSCSI et je voulais aussi avoir le weekend devant moi au cas ou ça se prolonge.

J'ai redémarré mon NAS, il s'est remis à bipper j'ai arrêté l'alarme, jusqu'ici rien de spécial. Après ça je me suis connecté à l'interface et j'ai essayé de faire une nouvelle target en RO par là-bas. J'ai réussi à la faire, et j'ai même réussi à m'y connecter!

Mais lorsque je m'y connecte il ne se passe rien, il ne me monte aucun disque. Du coup j'ai réessayé de remonter ma target habituelle pour voir si c'était pas la nouvelle qui était mal configuré mais impossible de la monter il me mettait un erreur comme quoi il y avait un périphérique pas prêt je crois.

Enfait j'ai du désactiver l'authenticition qui était activé sur ma target pour pouvoir l'utiliser. Mais il se passait la même chose, ça ne me connecte à rien du tout. La target est monté mais je n'ai aucun disque de détecté dans windows. Je suis parti voir de plus près dans le NAS et j'ai bien vu effectivement que le RAID est en erreur, mais je viens de faire attention qu'il me dis aussi que mon volume iSCSI est en panne (voir PJ).

 

Du coup je suis reparti tenter ma chance mais cette fois ci en ssh.

Mais rien à faire du tout! Pour toutes les commandes ietadm que j'essaye de faire j'ai le joyeux message "Connection refused.".

Je me suis dis que le service n'est peut-être pas lancé et j'ai essayé de trouver dans l'interface un endroit ou faire ça mais pas moyen.

Par contre j'ai trouvé dans la liste des processus qu'il y en avait plein qui commencent par iscsi. Mais surtout qu'ils étaient tous en veille! (voir PJ)

Est-ce que ce ne serai spas la source de mes connexions refusées? Si oui comment est-ce que je peux les lancer?

[Einsteinium]

Le soucis c'est que ton raid n'a plus que 2 disques sur 4...

Tu a fait un montage du scsi, mais la tu fais avant pour le volume ? (En lecture seul aussi ou en force)

apres hypothèse... Si tu backup l'intégralité du scsi du synology... Et que tu refais une fresh install.. Tu dois pouvoir le remettre non ? Quelqu'un peut confirmé ? Perso je n'utilise pas le scsi sur synology.

Modifié le 12 septembre 2015 par Einsteinium

[JeanSimon]

C'est ce que je me suis dis pour le 2 disques sur 4. Mais après je me suis aussi dis que si c'était ça, ben en réalité je n'aurais pas accès au dossier partagés non plus. Pourquoi ceux la je peux y accéder et pas l'iSCSI?

Et la copie de l'intégralité du fichier j'y ai pensé mais il se pose une contrainte de "taille". Il fait 5To d'une part, et d'autre part comme c'est un bloc, je crois qu'il faut que tout se passe nickel pendant la copie sinon l'ensemble sera inutilisable. Mais peut-être que je me trompe?

Mais par contre je ne sais pas comment le volume a été monté vu qu'il a été monté par le syno automatiquement au redémarrage. Comment est-ce que je peux vérifier la manière dont il est monté? Est-ce qu'il y a des chances que ça change quelque chose s'il était monté en lecture écriture, que je le démonte et le remonte en RO?

[JeanSimon]

Bon! Je sais pas s'il y a toujours quelqu'un mais je suis toujours le nez en plein dans mon problème.

 

J'ai avancé un chouilla mais pas plus.

J'ai pu récupéré ce qu'il y avait dans mes dossiers partagés, mais le plus important, mon disque iSCSI reste innaccessible.

J'ai ouvert un ticket chez syno, on m'avait dis sur le chat qu'il répondaient en général en 24h mais la ça fait presque 10 jours et toujours rien...

 

Bref j'ai avancé sur le fait que j'ai récupéré mon ancien NAS DS211j, que j'ai remis à jour.

J'ai acheté 2 disque 3To de remplacement que j'ai mis dedans, fais un JBOD pour avoir un espace de 5To, fait la vérif secteur par secteur des nouveaux disque pour m'assurer que tout est ok et j'ai tenté une sauvegarde du volume iSCSI craché du DS412+ vers le 211J mais ça a planté avec le joyeux message suivant "Network LUN Backup failed to backup task [My LUN Backup Set 1] to [192.168.100.114]. ([220] Unknown error:'220')".

J'ai réessayé plusieurs fois mais rien à faire.

 

Et en dernier recours j'ai essayé de copier à la main le volume iSCSI mais je me suis rendu compte d'un truc super bizarre.

Le volume iSCSI que j'avais repéré dans le dossier /volume1/@iSCSITrg/ ne fait pas 5To comme il devrait mais 5Go!

Et dans le dossier /volume1/@EP/ par contre il me dis des choses contradictoires. Lorsque je fais un du -sh /volume1/@EP/ du dossier il me dit qu'il fait 4,2To (ce qui correspondrait à la taille de mon volume). Mais lorsque je vais dans le dossier il que j'affiche la taille de chacun des fichiers j'en ai pour plus de 20To! Ce qui n'est pas possible vu que mon RAID ne faisait que 8,11To.

 

Du coup ma question est : Est-ce que vous savez à quoi correspondent ces fichiers? Et lequel est réellement mon iSCSI? Car si j'arrive à le reprendre à la barbare comme ça et le remonter sur mon autre NAS, ça me vas tout autant! Je vous met la capture des fichiers du dossier EP et iSCSI.

[JeanSimon]

Salut tout le monde.

 

Je voulais juste vous dire que j'ai eu une réponse du support de synology qui a pris la main sur mon NAS à distance et a réussi à me faire remonter mon RAID avec 3 disques.

Du coup il était seulement en dégradé et j'ai pu remonter mon LUN en lecture seule et faire mes copies. Bon il a replanté pendant la copie mais j'avais sorti les fichiers essentiels donc c'est plus vraiment un problème. J'ai demandé au mec du support comment il avait fait, il m'a filé tout le cheminement qu'il a emprunter. Je sais pas si ça intéresse quelqu'un mais du coup je pourrais éventuellement en faire un tuto...

SI besoin faites moi signe.

[gaetan.cambier]

Oui, toujours utile de connaître comment ils font ;)

[JeanSimon]

Retour un peu tardif.

 

Dans un premier temps, le technicien m'a communiqué leur procédure qui est la suivante :

How to rescue deleted iSCSI LUN

---

 

File-level LUN without Advanced LUN feature

The File-level LUN without Advanced LUN feature are created as file / sparse file, when user deletes the LUN, it means to delete the file(s) from volume.

Thus to rescue such LUN, you will need to run some undelete utilities, eg. extundelete, photorec …etc to find back the files.

extundelete => http://extundelete.sourceforge.net/options.html
photorec => http://www.cgsecurity.org/wiki/PhotoRec

 

File-level LUN with Advanced LUN feature

If the LUN is with Advanced LUN feature enabled, it is created as maps and pool of blocks. The LUN is a set of blocks which are registered in map file. When the LUN is deleted, those blocks will be reclaimed/un-registered and could not be recovered.

But if the scenario is that user removes the "whole volume" and thus the LUN is removed, there is still hope. Please follow the steps to rescue the LUN:

1. Recover the volume/configuration in offline/syno_poweroff_task mode
2. Move the deleted LUN map from @EP_trash to @iSCSItrg folder in the same volume (to avoid the reclamation, very important).
3. Rename the map files, then reboot the system.

 

Block-level LUN

If it is block-level LUN, removing the LUN is just like to remove the RAID volume or LVM volume, you could simply recover them as recovering deleted volume. One more step you might need to do is to adjust the synoblock configuration if the LUN is not correctly remounted to system.

• If it is block-level LUN based on RAID, please ensure the synoblock is set as “iscsi_LUN-1” (1 could be replaced by any number).
  • You could modify the space path by "synospace --synoblock -s /dev/sdX -v iscsi_LUN-1"  (for example)

• IF it is block-level LUN based on LVM, please ensure the synoblock is correctly configured,
• synospace --lv_meta –a -p VG_PATH –k LUN_BLOCK_DEVICE_NAME -v LUN_NAME
  • VG_PATH: such as /dev/vg1
  • LUN_BLOCK_DEVICE_NAME: use lvs to check the lv name, such as iscsi_0
  • LUN_NAME: usually restore it to default name, such as LUN-1

 

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

Après quoi je lui indiqué que je ne rentrais dans aucun des cas vu que la taille de mes fichiers étaient incohérente etc...

Il a alors pris la main sur mon NAS avec ses collègue en thailande ou à Taywan (j'ai un doute) et ils ont fait tout plein de choses et redémarré.

Après reboot j'avais un disque de plus qui était UP donc mon ISCSI UP aussi.

Voici les commandes qu'il a exécuté dans mon cas précis à moi :

 

a) vérifier l'historique de votre volume dans /etc/space/

b) vérifier l'état du raid avec cette commande cat /proc/mdstat

c) Vérifier les disques avec cette commande sfdisk -l

d) démonter le Raid avec cette commande mdadm -Sf /dev/md2

e) essayer de monter le volume au moins avec 3 disques "utilisant plusieurs combinaisons (c'était obligatoire, vu votre gros volume LUN)" avec cette commande (RAID classique si ma mémoire est bonne....si pour un volume SHR utiliser sd[abc]3 ou SD[abd]3) mdadm -AfR /dev/md2 /dev/sd[abc]5 et mdadm -AfR /dev/md2 /dev/sd[abd]5

f) essayer la réparation du système de fichier ext4 avec cette commande nohup fsck.ext4 -yvf /dev/mdX

g) si le système des fichiers est réparé...redémarrer le NAS avec la commande reboot

h) vérifier si le volume est bien monté avec au moins 3 disques...c'était vitale car votre volume le manque 3To, car vous avez un volume avec une protection de données sur un seul disque!!

 

 

 

Voila vous savez tout maintenant!

Au passage si quelqu'un à un lien pour réparer des secteurs delayed ou mort sur un HDD je suis preneur vu que j'ai 2 disque de 3To dans ce cas... :(