Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème pour monter un disque RAID SYNOLOGY

IzzieRider

Bonjour,

j'ai le même genre de problème. NAS Syno DS215J monté avec 2 disques 1.5T. A l'origine mon 1er disque était sur le slot 2, tout était OK, copie et accès des données dessus. En montant mon 2ème disque (slot 1) j'ai étendu le volume à 3T. Le problème c'est qu'il y a eu une coupure pendant un SMART test sur ce second disque et impossible pour le NAS de remonter le tout. Pas d'aide du côté de Syno et moi je suis novice en RAID. J'ai tenté leur bout de code "mdadm" pour récupérer mes données sur mon 1er disque mais rien n'y fait il ne veut pas monter et bien sur toutes mes data dessus.... HELP! Voici déjà quelques retours de commande:

root@lili-TOSH:~# fdisk -l
Disque /dev/sdb : 1,4 TiB, 1500301907968 octets, 2930277164 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5cc98a38

Périphérique Amorçage   Start        Fin   Secteurs  Size Id Type
/dev/sdb1                2048    4982527    4980480  2,4G fd RAID Linux autodétecté
/dev/sdb2             4982528    9176831    4194304    2G fd RAID Linux autodétecté
/dev/sdb3             9437184 2930072351 2920635168  1,4T fd RAID Linux autodétecté

root@lili-TOSH:~# mdadm --examine /dev/sdb3
/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 9723ae7f:778e2f46:ec639147:463589ee
           Name : MAYA:2
  Creation Time : Wed Feb 22 07:52:43 2017
     Raid Level : linear
   Raid Devices : 2

 Avail Dev Size : 2920633120 (1392.67 GiB 1495.36 GB)
  Used Dev Size : 0
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : cecb09e1:1f69c54d:ed39c519:b1cfa7d2

    Update Time : Thu Sep  7 16:12:13 2017
       Checksum : 616f31b9 - correct
         Events : 1

       Rounding : 64K

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

root@lili-TOSH:~# mdadm --detail /dev/sdb3
mdadm: /dev/sdb3 does not appear to be an md device

root@lili-TOSH:~# mdadm --assemble --force /dev/md2 /dev/sdb3
mdadm: /dev/md2 assembled from 1 drive - not enough to start the array.

root@lili-TOSH:~# sudo lsblk -o SIZE,NAME,FSTYPE,LABEL,MOUNTPOINT
  SIZE NAME   FSTYPE            LABEL  MOUNTPOINT
298,1G sda                             
294,2G ├─sda1 ext4                     /
    1K ├─sda2                          
  3,9G └─sda5 swap                     [SWAP]
  1,4T sdb                             
  2,4G ├─sdb1 linux_raid_member        
    2G ├─sdb2 linux_raid_member        
  1,4T └─sdb3 linux_raid_member MAYA:2

root@lili-TOSH:~# mdadm --detail /dev/md2
/dev/md2:
        Version : 1.2
     Raid Level : raid0
  Total Devices : 1
    Persistence : Superblock is persistent

          State : inactive

           Name : MAYA:2
           UUID : 9723ae7f:778e2f46:ec639147:463589ee
         Events : 1

    Number   Major   Minor   RaidDevice

       -       8       19        -        /dev/sdb3

root@lili-TOSH:~# mount /dev/md2 /mnt/syno/
mount: /dev/md2: can't read superblock

root@lili-TOSH:~# mdadm --detail --scan
INACTIVE-ARRAY /dev/md2 metadata=1.2 name=MAYA:2 UUID=9723ae7f:778e2f46:ec639147:463589ee

root@lili-TOSH:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md2 : inactive sdb3[0](S)
      1460316560 blocks super 1.2
       
unused devices: <none>
 1024M sr0

jamesbad000

Bonjour.

IzzieRider a écrit

root@lili-TOSH:~# mdadm --examine /dev/sdb3
(...)
     Raid Level : linear
   Raid Devices : 2

Ton raid est en mode "lineaire". Dans ce mode il est impossible d'assembler le raid sans la totalité des volumes le constituant.

IzzieRider

Merci,

Donc je dis adieu à mes données? ou est-il possible d'ajouter un nouveau disque, de simuler le remplacement du disque (défectueux), réécrire le format du RAID avec ce seul disque sans risque pour les données?... ou quelconque moyen pour récupérer mes données...

jamesbad000

Adieu ? Non pas si vite. Mais le raid linéaire n'est pas un mode qui permet la perte d'un disque et la reconstitution automatique du disque manquant. (le 2ème volume est juste la suite du premier)
Tu ne peux pas mettre le 2ème disque dans ton PC ? qu'on voit ce que ça donne.

IzzieRider

Malheureusement non, le disque "croque/clic/clac" dès le démarrage de l'alimentation et n'est pas détecté par fdisk, je viens de ressayer. J'ai un peu d'expérience avec dd voir même ddrescue pour le sauvetage de disque en bout de course mais la il n'y a rien à faire à mon avis, ça semble électro/méca. La seule "chance" que j'ai c'est que je venais de le connecter donc pas de donnée perso sur ce disque. Ce que je peux te dire c'est que c'est exactement le même modèle SAMSUNG HD154UI 1500GB. Je peux peut être utiliser un vieux disque si besoin mais je n'aurai pas autant de capacité pour "compléter" jusqu'à 3To. Pour l'instant seul l'accès à mes données importe. Le remontage du RAID se fera dans un second temps. Merci pour ton aide.

jamesbad000

Ah Ok. Mais ce n'était pas du explicite dans ton post que ce disque était HS.

IzzieRider a écritJe peux peut être utiliser un vieux disque si besoin

Ca n'aidera en rien à reconstituer le volume raid. Encore une fois, le raid linéaire n'est pas un raid à tolérance de pannes. Il permet seulement d'étendre un volume sur plusieurs disques.
En revanche il va peut-être nous falloir un espace de travail d'une centaine de Go...

Mais il faut d'abord que je fasse quelque test pour trouver la meilleurs approche...

jamesbad000

Ok, alors d'après le résultat de mdadm -E le système de fichier doit se trouver au secteur 2048 de la partition

    Data Offset : 2048 sectors

Voyons que donnes

sudo losetup -o $((2048*512)) /dev/loop0 /dev/sdb3
sudo fsck -fn /dev/loop0

IzzieRider

J'ai récupéré un disque de 100 Go et j'ai quelques dizaines de Go de libre sur mon OS. Je pourrai faire un peu de place au besoin.
Retour commande:

root@lili-TOSH:~# sudo losetup -o $((2048*512)) /dev/loop0 /dev/sdb3
root@lili-TOSH:~# sudo fsck -fn /dev/loop0
fsck de util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
La taille du système de fichiers (selon le superbloc) est de 730158272 blocs
La taille physique du périphérique est de 365079140 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
Arrêter ? non

La date de dernier montage du superbloc (Thu Sep  7 16:06:13 2017,
	maintenant = Sat Mar  4 17:26:40 2017) est dans le futur.
Corriger ? non

La date de dernière écriture du superbloc (Thu Sep  7 17:19:49 2017,
	maintenant = Sat Mar  4 17:26:40 2017) est dans le futur.
Corriger ? non

Passe 1 : vérification des i-noeuds, des blocs et des tailles
l'i-noeud 46 a le drapeau INDEX_FL activé sur le système de fichiers sans support des htrees.
Effacer l'index HTree ? non

l'i-noeud 290 a le drapeau INDEX_FL activé sur le système de fichiers sans support des htrees.
Effacer l'index HTree ? non

Passe 2 : vérification de la structure des répertoires
Problème avec l'i-noeud de répertoire d'HTREE 46 : bloc n°1 a un hachage maximal erroné
Problème avec l'i-noeud de répertoire d'HTREE 46 : bloc n°2 a un hachage mininal erroné
I-noeud de répertoire d'HTREE 46 invalide (/@database/pgsql/base/1). Effacer l'index HTree ? non

Problème avec l'i-noeud de répertoire d'HTREE 290 : bloc n°1 a un hachage maximal erroné
Problème avec l'i-noeud de répertoire d'HTREE 290 : bloc n°2 a un hachage mininal erroné
I-noeud de répertoire d'HTREE 290 invalide (/@database/pgsql/base/16385). Effacer l'index HTree ? non

Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
Erreur de lecture du bloc 365101056 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur ? non

fsck.ext4: Ne peut lire un bitmap de blocs lors de la tentative de re-lecture des bitmaps pour 1.42.6-15047

1.42.6-15047 : **ATTENTION : le système de fichiers contient encore des erreurs**

e2fsck: arrêté

1.42.6-15047 : **ATTENTION : le système de fichiers contient encore des erreurs**

jamesbad000

Ca a l'air pas mal. Je pense qu'on peut tenter la réparation du système de fichier directement.
Seulement, pour tronquer le système de fichier, il n'est pas possible de faire un fsck totalement automatique. Il va falloir que tu réponde "o" à chaque demande de réparation. Après s'il apparait nettement plus de problèmes que dans la passe précédente, inutile de passer des heures à répondre aux messages d'erreur, envoi moi le contenu du terminal que je vois ce qui ne va pas...

sudo fsck -f /dev/loop0

IzzieRider

Je n'ai pas arrêté la boucle mais comme tu le sentais la liste à l'air longue, j'ai fais quelques non pour pouvoir arrêter du coup je laisse en l'état en attendant ton retour.

root@lili-TOSH:~# sudo fsck -f /dev/loop0
fsck de util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
La taille du système de fichiers (selon le superbloc) est de 730158272 blocs
La taille physique du périphérique est de 365079140 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
Arrêter<o>? non
La date de dernier montage du superbloc (Thu Sep  7 16:06:13 2017,
	maintenant = Sat Mar  4 17:49:08 2017) est dans le futur.
Corriger<o>? oui
La date de dernière écriture du superbloc (Thu Sep  7 17:19:49 2017,
	maintenant = Sat Mar  4 17:49:08 2017) est dans le futur.
Corriger<o>? oui
Passe 1 : vérification des i-noeuds, des blocs et des tailles
l'i-noeud 46 a le drapeau INDEX_FL activé sur le système de fichiers sans support des htrees.
Effacer l'index HTree<o>? oui
l'i-noeud 290 a le drapeau INDEX_FL activé sur le système de fichiers sans support des htrees.
Effacer l'index HTree<o>? oui
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
/lost+found n'a pas été trouvé. Créer<o>? oui
Erreur de lecture du bloc 365101056 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 365428736 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 365953024 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 366477312 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 367001600 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 367525888 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? oui
Forcer la ré-écriture<o>? oui
Erreur de lecture du bloc 368050176 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>? non
fsck.ext4: Ne peut lire un bitmap de blocs lors de la tentative de re-lecture des bitmaps pour 1.42.6-15047
Erreur lors de d'écriture du bloc 365101056 (Argument invalide). Ignorer l'erreur<o>? non
Erreur lors de d'écriture du bloc 365428736 (Argument invalide). Ignorer l'erreur<o>? non
Erreur lors de d'écriture du bloc 365953024 (Argument invalide). Ignorer l'erreur<o>?

jamesbad000

Le mieux est d'arrêter avec la combinaison de touche ctrl+c.
Et maintenant que le système de fichier a été tronqué, on peut relancer en auto avec

sudo fsck -fy /dev/loop0

IzzieRider

ctrl+c

Erreur lors de l'écriture de l'information de système de fichier: Argument invalide

1.42.6-15047: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
root@lili-TOSH:~#

Du coup il m'arrête à la table de partition comme on est en auto (yes)

root@lili-TOSH:~# sudo fsck -fy /dev/loop0
fsck de util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
La taille du système de fichiers (selon le superbloc) est de 730158272 blocs
La taille physique du périphérique est de 365079140 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
Arrêter ? oui

root@lili-TOSH:~#

jamesbad000

Evidemment j'aurais du penser qu'il n'enregistrerait pas les modifs avant d'avoir été jusqu'au bout.
Je viens de tester une autre approche...

sudo resize2fs /dev/loop0 365079140

IzzieRider

root@lili-TOSH:~# sudo resize2fs /dev/loop0 365079140
resize2fs 1.42.13 (17-May-2015)
SVP exécutez « e2fsck -f /dev/loop0 » d'abord.

root@lili-TOSH:~#

jamesbad000

merde on tourne en rond. Pourtant mon test a fonctionné. Mais probablement parce que je l'ai fait avec un système de fichier propre...
Bon j'ai bien encore d'autres idées, mais ça devient compliqué, et ça risque de me prendre du temps, si on veut être sur que ça ne va pas encore foirer... Donc je préconise de revenir au plan initial et d'insister avec

sudo fsck -f /dev/loop0

charrier63

Bonsoir,
Sinon cette formule :
https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC
En branchant le disque dur synology sur un ordi

Sujet traité ici :
https://forum.ubuntu-fr.org/viewtopic.php?id=2005717

Mais au final, avec des outils :
- Ubuntu,
- Windows (pour une partie ne sachant pas la faire sous Linux),
- Synology

Edit : En gros, pour la partie recuperation de données, utiliser ubuntu pour simuler la reconstruction NAS RAID avec un logiciel Linux, si le SYNO ne sait plus le faire

IzzieRider

Pas de soucis. J'ai lancé la commande et corrigé quand je le pouvais et ignoré pour les blocs hors limite d'après ce que je comprends. Mon terminal n'a pas gardé toutes les lignes de code (pour chaque bloc qui posait problème). Je te copie les dernières lignes sinon le prompt serait monstrueux:

Erreur lors de l'écriture du bloc 724041728 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 724566016 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 725090304 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 725614592 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 726138880 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729284608 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729808896 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 726663168 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729808906 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 727187456 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 727711744 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 728236032 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 728760320 (Argument invalide). Ignorer l'erreur<o>? oui

1.42.6-15047: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
1.42.6-15047 : 5511/182542336 fichiers (1.2% non contigus), 330604168/730158272 blocs
root@lili-TOSH:~#

jamesbad000

Tu t'en sort bien finalement. Il y a peu de temps quelqu'un a passé 3 heures à répondre aux messages d'erreurs de fsck...

Refaisons une passe pour vérifier

sudo fsck -fy /dev/loop0

puis

sudo mount /dev/loop0 /mnt

IzzieRider

Ne parlons pas trop vite... le stress est toujours la...

tout se passe bien jusqu'à la passe 5 (contrairement à avant) mais après il me demande encore d'ignorer des blocs, je suis allé au bout

Erreur lors de l'écriture du bloc 724041728 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 724566016 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 725090304 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 725614592 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de l'écriture du bloc 726138880 (Argument invalide) lors de l'écriture des bitmaps de blocs et d'i-noeuds. Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729284608 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729808896 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 729808906 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 726663168 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 727187456 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 727711744 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 728236032 (Argument invalide). Ignorer l'erreur<o>? oui
Erreur lors de d'écriture du bloc 728760320 (Argument invalide). Ignorer l'erreur<o>? oui

1.42.6-15047: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
1.42.6-15047 : 5511/182542336 fichiers (1.2% non contigus), 330604168/730158272 blocs

Puis j'ai relancé une passe. il détecte toujours des arguments invalide

root@lili-TOSH:~# sudo fsck -f /dev/loop0
fsck de util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
La taille du système de fichiers (selon le superbloc) est de 730158272 blocs
La taille physique du périphérique est de 365079140 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
Arrêter<o>? non
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
Erreur de lecture du bloc 365101056 (Argument invalide) lors de la lecture des bitmaps d'i-noeuds et de blocs. Ignorer l'erreur<o>?

Faut-il que je continue à faire plusieurs passes? ce n'est peut être pas les mêmes blocs à chaque fois qu'il m'affiche.

charrier63: Bonsoir, méthode syno déjà testé sans succès suite à un disque HS pendant une coupure lors d'un SMART TEST du Syno.

jamesbad000

Le problème c'est que fsck n'a pas corrigé la taille du système de fichier contrairement à ce qui c'était passé dans mon test. Mais maintenant que le fsck est passé, s'il a bien marqué le fs "clean" le redimentionnement va peut-être passer

sudo resize2fs /dev/loop0 365079140

Page suivante »