vecisse Posté(e) le 9 septembre 2017 Partager Posté(e) le 9 septembre 2017 (modifié) Bonjour, Je poste ici les infos qui m'ont permis de récupérer les données de mon synology DS414 suite à un plantage de volume. Comme j'ai eu beaucoup de difficultés pour trouver des infos sur ce sujet, j'espère que ce post sera utile à d'autre. Au passage je précise que c'est grâce à cet excellent forum que j'ai pu trouver la solution à mon problème, ainsi qu'au support de synology. Mon équipement DS414 avec 4 disque WD purple 4To en RAID SHR. 1 seul volume créé (Volume 1) Les symptômes du problème Mail de mon DS414 qui m'informe que "le volume 1 est planté". Comme je ne suis pas chez moi, je décide de lancer un redémarrage à distance, et là, plus rien. A mon retour, LED bleue clignotante et synology qui refuse de démarrer. Pas d'accès à l'interface Web non plus. je vérifie que la carte mère n'est pas en cause (https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly) J'achète même un disque test (1To) et vérifie que je peux réinstaller le syno avec 1 seul disque. Le problème est donc logiciel et non matériel d'autant qu'un test SMART de mes 4 disques de 4To ne montrent aucun défaut. Je vous passe les détails des essais de récupération de mon volume RAID sous UBUNTU. La seule chose que j'arrive à en retirer est que le volume est planté car le journal est corrompu (le volume refuse de se monter). La solution D'après les conseils du support de synology, je remonte donc dans le DS414 : le disque de test de 1To avec le système réinstallé 3 des 4 disques de 4To d'origine. après redémarrage, l'interface Web du Synology m'indique que le volume 2 est dégradé (disques non lisibles). J'active alors l'accès à la console SSH depuis le panneau de configuration > Terminal et SNMP. Je me connecte ensuite sur le synology depuis la console SSH. Voici les commandes qui m'ont permis de récupérer l'accès à mes données: admin@NAS:/$ sudo mdadm --detail --scan mdadm: cannot open /dev/md/0_0: No such file or directory ARRAY /dev/md1 metadata=0.90 UUID=4a7660ae:87c0c249:cced5de7:ca715931 ARRAY /dev/md3 metadata=1.2 name=NAS:2 UUID=8b6bc470:c340f769:ba132a9e:5005a524 ARRAY /dev/md2 metadata=1.2 name=DiskStation:2 UUID=7300606a:1c669078:5fe83f06:d9960379 admin@NAS:/$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sda5[0] 971931456 blocks super 1.2 [1/1] md3 est le volume RAID5 sur lequel se trouvaient mes données avec seulement 3 des 4 disques présents j’ai ensuite arrêté les services du NAS admin@NAS:/$ syno_poweroff_task -d puis lancé vgchange (pas sûr que cette étape soit utile …) admin@NAS:/$ sudo vgchange -ay 1 logical volume(s) in volume group "vg1001" now active 1 logical volume(s) in volume group "vg1000" now active Grace à lvdisplay, j’ai identifié le nom du volume logique associé à md3 admin@NAS:/$ sudo lvdisplay --- Logical volume --- LV Path /dev/vg1001/lv LV Name lv VG Name vg1001 LV UUID vQ9HkO-GhXm-KxK4-6fF8-tJkA-3B0m-9Va4b0 LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 10.90 TiB Current LE 2858117 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 253:0 --- Logical volume --- LV Path /dev/vg1000/lv LV Name lv VG Name vg1000 LV UUID MD95Mn-4EUW-oGxW-2J13-3ojX-NZrq-IaeWYj LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 926.90 GiB Current LE 237287 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 253:1 J’ai ensuite lancé e2fsck sur le volume corrompu: admin@NAS:/$ sudo -i root@NAS:~# e2fsck -p /dev/vg1001/lv 1.42.6-3827: recovering journal 1.42.6-3827: Journal transaction 14544865 was corrupt, replay was aborted. 1.42.6-3827 contains a file system with errors, check forced. 1.42.6-3827: Deleted inode 28311577 has zero dtime. FIXED. 1.42.6-3827: Inodes that were part of a corrupted orphan linked list found. 1.42.6-3827: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) puis reboot root@NAS:~# reboot après reboot, les données sont accessibles Modifié le 9 septembre 2017 par vecisse remise en forme 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
JMduSud Posté(e) le 10 septembre 2017 Partager Posté(e) le 10 septembre 2017 Bonjour, Je note des similitudes entre ton cas et le mien. J'ai une petite question: Comment réinstalles-tu le système sur ton nouveau disque ? Peux-tu me donner un lien ? Merci par avance 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.