lire un dd raid1 tout seul

lire un dd raid1 tout seul [Réglé]

Un dd d'une NAS est en raid1 comment récuperer les données Système et matériels / Autres matériels et périphériques

bermisch Membre non connecté

Le 27/10/2021 à 13h16

Bonjour,
On m'a confié un disque dur venant d'une NAS "la cie". Je l'ai reçu sur un boitier USB où est bien vu.et détecté. Néanmoins, il faudrait récupérer les données qui sont sur une partition "user" de type raid, dont le device name est /dev/sdi8 (1.82 Tera Octets) et /dev/md124 pour le raid.
Le disque est probablement sain et c'est le hard de la NAS qui a du péter.

Comme il s'agit d'un raid 1 sur une seule partition, comment faire pour y accéder en USB et monter le /dev/md124, mount en effet ne connaît pas le système de fichier linux-raid. Je suppose qu'il faut utiliser mdadm pour activer/désactiver le raid. Les fichiers doivent être dupliqués d'une façon ou une autre à l'intérieur de la partition. Le même disque contient d'autres partitions raid 1 pour la gestion du NAS.

e2fsck n'aime pas /dev/sdi8

activation par mdadm :

[root@bermisch md]# mdadm --assemble -scan
mdadm: Found some drive for an array that is already active: /dev/md/LaCie-CloudBox:8
mdadm: giving up.
mdadm: Found some drive for an array that is already active: /dev/md/(none):7
mdadm: giving up.
mdadm: Found some drive for an array that is already active: /dev/md/(none):6
mdadm: giving up.
mdadm: Found some drive for an array that is already active: /dev/md/(none):5
mdadm: giving up.
mdadm: Found some drive for an array that is already active: /dev/md/(none):4
mdadm: giving up.
mdadm: No arrays found in config file or automatically

Cela voudrait dire que le "array" LaCie-CloudBox:8 est actif mais je ne vois pas comment y accéder par exemple depuis Dolphin. Néanmoins "giving up" n'est pas bon signe ("je laisse tomber".).
Je ne suis pas familier avec mdadm mais j'aimerais "ne pas tout flinguer" puisque le but est de récupérer le contenu.
Gparted détecte bien /dev/md125 mais pas /dev/md124 qui m'intéresse ni les autres /dev/md* (123-124-126-127)
Un idée, une solution ?
Merci
BM

2 PC intel X86 sous Mageia - 64 bits - 8G bits mémoire, KDE dont un avec serveur LDAP "wake-on-waned "
livebox orange fibre 300Mb/s avec. Wifi ..
Lien pour l'allumage : du pc avec serveur LDAP (allumage à distance hs actuellement) :
https://www.depicus.com/wake-on-lan/woli?m=BCAEC58C7279&i=bermisch.ddns.net&s=255.255.255.255&p=9

Lien pour le site lui-même si pc serveur allumé: http://bermisch.ddns.net
(erreur 403 à ce niveau mais .../ magallerie donne accès à coppermine base de photos en lecture seule..) sur ip dynamique (ddns)

bermisch Membre non connecté

Le 05/11/2021 à 14h30

#293989

Bonjour,
J'ai réussi à me débarrasser du pb "raid" mais j'ai désormais une partition "lvm2_member" formatée parait-il en ext4..
Avec lvm2 j'ai pu récupérer le "vg" volume groupe, le "pv" physical volume et même le "lv" le logical volume.

[root@bermisch pepe]# vgscan
Found volume group "vv_pepe" using metadata type lvm2

root@bermisch pepe]# pvscan
PV /dev/sdg8 VG vv_pepe lvm2 [<1,82 TiB / 0 free]

[root@bermisch pepe]# lvscan
ACTIVE '/dev/vv_pepe/lv' [<1,82 TiB] inherit

Je fais pour activer le lv :

vgchange vv_pepe -a y
File descriptor 9 (pipe:[125643]) leaked on vgchange invocation. Parent PID 11576: bash
File descriptor 11 (pipe:[125644]) leaked on vgchange invocation. Parent PID 11576: bash
1 logical volume(s) in volume group "vv_pepe" now active

J'ai donc mon logical volume lv en principe accessible et actif sous /dev/vv_pepe/lv

Voici ce donne /etc/lvm/backup :

Code TEXT :

 
vv_pepe {
    id = "12Vjfh-Dygi-b2ZJ-79BA-sfDR-rc37-bBiryQ"
    seqno = 5
    format = "lvm2"            # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192        # 4 Megabytes
    max_lv = 0
    max_pv = 0
    metadata_copies = 0
 
    physical_volumes {
 
        pv0 {
            id = "JWXUex-7jbg-SQcx-b54n-sqMa-HDlz-3n8qUV"
            device = "/dev/sdh8"    # Hint only
 
            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 3897716600    # 1.81502 Terabytes
            pe_start = 2048
            pe_count = 475795    # 1.81501 Terabytes
        }
    }
 
    logical_volumes {
 
        lv {
            id = "UD9oc1-142q-TmxA-HLVR-K5uE-See1-Cl0jj2"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1
 
            segment1 {
                start_extent = 0
                extent_count = 475795    # 1.81501 Terabytes
 
                type = "striped"
                stripe_count = 1    # linear
 
                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
 
}

A priori ce devrait être ok pour l'accès avec lv2 après montage sur le réperpoire /vg01
mais

[root@bermisch backup]# mount /dev/vv_pepe/lv /vg01
mount: /vg01: impossible de lire le superbloc à l’adresse /dev/mapper/vv_pepe-lv
Alors d'autres outils me disent qu'il existe un fs ext4 sur cette partition.
Dmesg indique :

[nov. 5 14:10] Buffer I/O error on dev dm-0, logical block 487214064, async page read
[ +0,000160] EXT4-fs (dm-0): unable to read superblock

Cela semble un pb de longueur de buffer. J'ai vu ailleurs que sur un NAS les buffer étaient de grande longueur bien supérieure à la longueur habituelle permise pour un dd en ext4.
La NAS était avec un processeur ARM.pas un x86 sous un "linux perso" de LaCie
Maintenant, la définition du lv n'est peut-être pas ok ?
Est-ce récupérable ???
Des modif à faire dans la définition du lv ??? Le superbock n'est pas à l'ndroit cherché ?
Si vous avez des idées, merci d'avance.on du lv ???
Si vous avez des idées, merci d'avance.

[Edit] Formatage

Édité par Papoteur Le 16/11/2021 à 11h24

bermisch Membre non connecté

Le 06/11/2021 à 15h40

#294026

Bonjour,
j'ai un peu avancé : quand le disque (usb) estt détecté au boot le système me demande le mot de passe root pour le monter, et en effet la partition /dev/dm-0 est bien montée sur /run/media/pepe/f2d113a5-5ea3-485b-84cb-dfed74229d33/ une uuid que je ne vois pas ailleurs.
Il est possible d'ouvrir ce répertoire dans dolpin mais l'accès aux fichiers est impossible. sous l'utilisateur lambda.
Hélàs ! Je n'ai pu le faire qu'une fois

Cette manip n'est donc pas répétitive. Il semble bien que le device /dev/dm-0 qui correspond au volume lvm2, soit vv_pepe soit corrompu du point de vue ext4 - ou bien ????

[root@bermisch pepe]# mount -t ext4 /dev/dm-0 /vg01

mount: /vg01: impossible de lire le superbloc à l’adresse /dev/mapper/vv_pepe-lv.

[root@bermisch pepe]# e2fsck /dev/dm-0
e2fsck 1.45.6 (20-Mar-2020)
e2fsck: Erreur d'entrée/sortie lors de la tentative d'ouverture de /dev/dm-0

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>

Ces deux dernières commandes donnent le même résultat.
De plus le disque est long à répondre. Pb hard ? La NAS était partie en botte, et on en a extrait le disque qui est peut-être abimé ?
Chercher un autre superblock ???

cdt

bermisch Membre non connecté

Le 17/11/2021 à 19h29

#294412

Bonsoir,
J'ai démarré une session de copie entre le DD fautif et un disque amovible via l'utilitaire Midnight Commander (eh oui, c'est pratique et ça existe encore) sous console en root. Très curieusement j'ai pu transférer quelques fichiers assez gros, c'est de la video genre AVI , et très vite j'ai eu une erreur I/O. J'ai regardé le fichier /var/log/kernel/errors.log. Le transfert s'est bien passé de 1h15 à 10h26 et plus rien de possible après ça. La partition source est sdg8 les lectures à partir de 10h26.27 (683.879932) pour lire "sector 3907029120 op 0x0:(READ)" on passe en faute on a des
" Buffer I/O error on dev sdg8, logical block 3897716864, async page read" puis d'autres messages d'erreur "à décoder". le device dm-0-8 correspond au système de fichier ext4 de la partition LVM2.

Le fait qu'il s'agisse d'un disque s-ATA de grande capacité 2 Teraoctets dans une boîte d'adaptation USB3 a peut-être une influence ? Peut-être faut-il remonter à plus tôt au moment où on monte la partition sdg8 - le système demande le mot de passe root.

Merci pour l'aide. J'essaie d'attacher le fichier d'erreur mais je n'ai jamais fait ça et ça a l'air de fonctionner.kernel-errors.txt

Édité par bermisch Le 17/11/2021 à 19h41

Répondre

Vous n'êtes pas autorisé à écrire dans cette catégorie

Notre Mission	Liens du site	Nous joindre	MLO est hébergé par
MLO est le forum francophone de la distribution Mageia et vous propose également un portail dédié aux débutants. MLO vous apporte un support sur la distribution grâce à son forum et vous offre des nouvelles de la distribution, des logiciels libres et de l'Open Source en général. Notre site a aussi pour but de vous montrer que Mageia est un système d'exploitation complet et facile à prendre en main. Vous apprendrez à installer simplement et à administrer efficacement votre système en un temps record.	Forum Documentation News du libre Mageia	Contacter MLO Mastodon MLO Flux RSS	MLO est un projet soutenu par Nos partenaires et amis
MLO est mis à disposition selon les termes de la licence Creative Commons.

bermisch Membre non connecté

nic80 Membre non connecté

Papoteur Membre non connecté

nic80 Membre non connecté

steven Membre non connecté

bermisch Membre non connecté

bermisch Membre non connecté

bermisch Membre non connecté

Papoteur Membre non connecté

bermisch Membre non connecté

Papoteur Membre non connecté

bermisch Membre non connecté

bermisch Membre non connecté