Forum Linux.debian/ubuntu Aide pour récupérer les données d'un RAID SHR (4 discs ) sous linux

Posté par  . Licence CC By‑SA.
Étiquettes :
0
9
mai
2020

Bonjour
Mon NAS SYNOLOGY 412 + a planté est je souhaite récupérer mes données qui se trouvent sur les 4 disques SATA (2 disques en 3T, 1 Disque 2T et Disque 1T) en les connectant sur mon ordinateur qui a une configuration Ubuntu 19.4
A ce stade j'obtiens ça :

J'ai mes 4 Hard Disk vus, 3 ont été vus également en mode Raid, et j'ai bien mes deux volumes logiques 1 et 2 du Raid SHR qui se base sur un volume global 1 (/dev/vg1)

Mais je n'arrive pas à faire monter les Volumes logiques 1 et 2 pour que je puisse les lires.
J'ai essayé avec le logiciel et avec les commandes manuels.

J'ai bien créé un point de montage au préalable avec la commande
sudo Mkdir /Données1

mais après ma commande suivante

sudo mount /dev/vg1/volume_1 /Données1

j'obtiens l'erreur suivante :

mount: /Données: wrong fs type, bad option, bad superblock on /de/mapper/vg1-volume_1, missing codepage or helper program, or other error.

avez vous une idée pour résoudre cette erreur ?
merci

  • # SHR = mdadm + LVM

    Posté par  . Évalué à 3.

    Ton message n'est pas explicite à propos du RAID logiciel. Est-il en bonne forme ?
    Par exemple la commande cat /proc/mdstat donne quoi ?
    L'as-tu réparé ou forcé ?

    • [^] # Re: SHR = mdadm + LVM

      Posté par  . Évalué à 1.

      Bonjour

      La commande donne cela;
      (Pour info j'ai dû faire un reset de mon NAS 412 + car il redémarré toutes les 1/2 heures et lors de la reset il me demande de formater les disques au lieu de retrouver la configuration initiale, aussi je suis obligé de récupérer les données d'abord via un autre moyen avant de remettre mes disques dans mon nas)

      ```souillard@souillard-bequiet:~$ sudo cat /proc/mdstat
      [sudo] Mot de passe de souillard :
      Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
      md4 : active raid1 sdf7[0] sdc7[1]
      976742784 blocks super 1.2 [2/2] [UU]

      md3 : active raid5 sde6[0] sdf6[1] sdc6[2]
      1953485568 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]

      md2 : active raid5 sde5[3] sdd5[1] sdf5[2] sdc5[4]
      2916082944 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

      unused devices: ```

      • [^] # Re: SHR = mdadm + LVM

        Posté par  . Évalué à 3. Dernière modification le 09 mai 2020 à 23:39.

        [UUU] … [UUUU]

        Donc les RAID semblent en bon état.

         
        Tu peux ensuite vérifier l'état des éléments LVM avec pvdisplay et vgdisplay et lvdisplay.
        Si tout te semble bon, vérifie quel est le système de fichiers avec blkid puis tente de monter avec mount --verbose --readonly --types ext4 /dev/vg1/volume_1 /Données1 puis affiche le contenu du journal système avec tail /var/log/syslog afin d'avoir plus d'informations sur le problème.

        Également une vérification de l'état SMART n'est pas superflu : smartctl --all /dev/sdX | less

        • [^] # Re: SHR = mdadm + LVM

          Posté par  . Évalué à 3.

          Selon le contenu du journal système, tu peux ensuite faire un vgchange -ay (regarde la page de manuel pour savoir ce que ça fait) et fsck.ext4 /dev/vg1/volume_1 (il est très très très prudent de dupliquer avant de passer au fsck. Mais je suppose que tu n'as pas de quoi dupliquer, sinon tu l'aurais utilisé depuis longtemps pour faire une sauvegarde quotidienne et tu ne serais pas en train de tenter de récupérer tes données).

          • [^] # Re: SHR = mdadm + LVM

            Posté par  . Évalué à 1.

            Bonjour Kerro 
            

            A la commande :
            sudo blkid j'obtiens les deux lignes les plus intéressantes concernant les deux volumes logiques que j'essaye de monter les fichiers sont biens en TYPE ext4 et cela me rassure

            /dev/mapper/vg1-volume_1: LABEL="1.41.10-2660" UUID="2d01f4aa-c415-41f2-8286-4dfcad272cac" TYPE="ext4"
            /dev/mapper/vg1-volume_2: LABEL="1.41.10-2660" UUID="116f4967-f3bc-4044-90a9-ba00c031b3bf" TYPE="ext4"
            j'ai déjà fait depuis longtemps vgechange -ay pour activer le groupe de volume

            A la commande fsck.ext4 /dev/vg1/volume_1

            j'obtiens
            ```
            souillard@souillard-bequiet:~$ sudo fsck.ext4 /dev/vg1/volume_1
            e2fsck 1.45.3 (14-Jul-2019)
            1.41.10-2660 : récupération du journal
            Corruption repérée dans le superbloc. (reserved_gdt_blocks = 8102).

                Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
                ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
                un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
                alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
                e2fsck avec un autre superbloc :
                    e2fsck -b 8193 <périphérique>
                 ou
                    e2fsck -b 32768 <périphérique>
            

            ```ce que je comprends de ma recherche sur le web c'est que la version 19.04 de Ubuntu ne monte pas de bloc > à 8000 et qu'il faudrait que j'installe une version de ubuntu 15.10 pour pouvoir faire le montage, je trouve çà un peu louche

            • [^] # Re: SHR = mdadm + LVM

              Posté par  . Évalué à 3.

              Et bêtement via SSH sur le NAS ?

              Tu tues les éventuelles tâches qui tentent de bricoler les disques et tu fais les manips depuis le NAS. Tu es certain d'avoir des versions logicielles qui conviennent.

              • [^] # Re: SHR = mdadm + LVM

                Posté par  . Évalué à 1. Dernière modification le 10 mai 2020 à 18:28.

                En effet ce serait mieux que j'arrive à remonter le raid sur le nas directement

                Seulement depuis que j'ai fait reset le nas me demande de formater les disques lorsque j'en insère un pour voir.

                Par précaution j'avais sorti les disques avant de faire reset pour pas que le nas me les formates sans demander

                je ne trouve pas de docs sur le web pour m'aider dans cette voie

                C'est quoi SSH ?

                • [^] # Re: SHR = mdadm + LVM

                  Posté par  . Évalué à 3.

                  C'est quoi SSH ?

                  C'est le terminal « ligne de commande » à distance. Si tu connais telnet, c'est le même genre mais avec un protocole sécurisé.
                  Depuis ton PC tu te connectes sur ton NAS et tu obtiens le terminal de ton NAS. De là tu peux entrer des commandes comme si tu avais écran+clavier branchés sur le NAS.

                  Il faut d'abord activer le service SSH :
                  https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/system_terminal

                  Je pense que c'est à essayer.
                  Il te faut l'adresse IP du NAS, le nom d'utilisateur (je crois que c'est « admin » sur ton NAS) et le mot de passe correspondant. Ça donne ssh admin@192.168.x.y puis ça te demande le mot de passe, et tu es connecté.

  • # reinstaller le NAS en utilisant les anciens disques

    Posté par  . Évalué à 2. Dernière modification le 14 mai 2020 à 10:11.

    il faut surement utiliser la procédure de migration via HDD

    https://www.synology.com/en-us/knowledgebase/DSM/tutorial/General_Setup/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later#t2.1

    dans ton cas l'ancien et le nouveau sont le "meme modele"
    il y a une procédure pour migrer d'un NAS à un autre de meme modele, et il te faut un disque temporaire en plus des disques de l'ancien
    https://www.synology.com/en-us/knowledgebase/DSM/tutorial/General_Setup/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later#t3.2

    pour faire simple, tu met le disque temporaire (disque que tu peux sacrifier) dans le NAS, tu le reinstalles.

    puis tu éteins le NAS, tu remet les anciens disques RAID DANS LE MEME ORDRE QU'ILS ETAIENT INTIALEMENT sinon il va proposer de les reformater.

    Et tu démarres le NAS.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.