Comment monter / récupérer des données sur un disque qui faisait partie d'un raid mdadm 1 sur une autre machine?


17

Quelques antécédents

  • Le disque lui-même a été "travaillé" par un ami et serait encore intact, intact et toujours montable / récupérable
  • Le disque faisait partie d'un raid logiciel 1 sur Ubuntu 12.04
  • L'autre disque du raid d'origine 1 a été formaté et utilisé à une autre fin, laissant le disque actuel (celui en question) toujours techniquement partie d'un raid qui n'existe plus

Ce que j'ai déjà essayé

  • Montage de base

    • J'ai ajouté une entrée à fstab, marqué le disque comme ext3 / ext4 et essayé de monter.
    • Lors du montage, l'erreur suivante apparaît

      wrong fs type, bad option, bad superblock on

    • Et à Dmesg

      EXT4-fs (sdc1): VFS: Can't find ext4 filesystem

  • J'ai essayé de trouver le type de système de fichiers du disque et j'ai trouvé

    $sudo file -s /dev/sdc
    /dev/sdc: x86 boot sector; partition 1: ID=0x83, starthead 254, startsector 63, 1953520002 sectors, code offset 0xb8

Où j'ai besoin d'aide / Mes questions

  • Existe-t-il un moyen de convertir le disque en ext4 sans endommager les données?
  • Existe-t-il un moyen simple de monter le disque de type de fichier Linux 83 et de récupérer les données?
  • J'ai un autre disque actuellement libre au cas où il serait possible de reconstruire le raid
  • Mon objectif principal est de récupérer les données du disque. Je suis ouvert à toutes les options.

Mise à jour

Sortie de certaines commandes

  • fdisk -l / dev / sdc

    $fdisk -l /dev/sdc

    Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
    255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0005ed9c

    Device Boot Start End Blocks Id System
    /dev/sdc1 63 1953520064 976760001 83 Linux

  • fichier -s / dev / sdc1

    $file -s /dev/sdc1
    /dev/sdc1: data

  • hexdump -C -n 32256 / dev / sdc (Je ne sais pas si cela pourrait aider ou non)

    $hexdump -C -n 32256 /dev/sdc`
    00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |................|
    00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
    00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
    00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
    00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
    00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001b0  00 00 00 00 00 00 00 00  9c ed 05 00 00 00 00 fe  |................|
    000001c0  ff ff 83 fe ff ff 3f 00  00 00 82 59 70 74 00 00  |......?....Ypt..|
    000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
    00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00007e00
    

Le problème est que la partition pense qu'elle a un certain volume de raid et non un ext4fs. Et le noyau a raison. Cependant, comme il s'agissait d'un raid 1, il se trouve qu'il s'agit d'un ext4fs. un mount -f ext4 /dev/sdc1 /mountpointdevrait faire l'affaire.
Forcer

1
Le montage forcé ne donne aucune erreur, mais le point de montage est vide. Soit les données ont disparu, soit le montage n'a pas fonctionné comme prévu. Faire un dfme montre que le disque nouvellement monté est utilisé à 2%, ce qui est nettement inférieur à celui attendu.
Adam

@ user1129682, si mount dit que ce n'est pas ext4, alors ce n'est pas ... essayer de le forcer ne va pas aider.
psusi

@psusi: a travaillé pour moi. Réponse de Gilles explique pourquoi cela fonctionne dans certaines circonstances
Bananguin

@Bananguin Tu ne veux pas dire mount -t ext4? L'indicateur -f est pour un montage 'faux' (ubuntu 14.04).
Quantum7

Réponses:


11

Cela fonctionne parfaitement dans Ubuntu 14.04:

sudo -i
mdadm --assemble --scan

Tu auras:

mdadm: /dev/md/1 has been started with 1 drive (out of 2)

Montez ensuite et voyez vos fichiers:

cd /mnt && mkdir to-restore-md1 && mount /dev/md1 to-restore-md1
ls -la to-restore-md1

J'obtenais "existe mais n'est pas une matrice md" sur un disque dur défectueux qui faisait partie d'une matrice ... et cela fonctionnait mieux que toutes les autres suggestions. Monté avec succès, la copie des données est actuellement désactivée.
Zayne S Halsall

cette option a bien fonctionné pour moi. 2 SSD Intel en RAID1. Tiré un et asservi du port SATA au PC exécutant suse linux. Initialement apparaît comme seul /dev/sdcet comme /dev/md127. Ensuite, mdadm --assemble --scance qui a abouti à /dev/md/Volume0_0p1et /dev/md/Volume0_0p2ainsi de suite correspondant à 4 partitions qui étaient sur le disque. P2 était celui dont j'avais besoin: mkdir /p2 suivi par le mount /dev/md/Volume0_0p2 /p2montage qui était EXT3 et je peux facilement accéder et copier les données. Il l'a également monté en lecture-écriture.
ron

tu as fait ma journée! Merci!
Gooshan

Parfois, le --scanmode ne démarre pas les tableaux avec des disques manquants, dans mon cas, j'ai dû arrêter le tableau auto-assemblé et le redémarrer avecmdadm --assemble --force /dev/md/1 /dev/sdc1
BrunoJCM

7

Linux mdraid a plusieurs formats de métadonnées . Les formats 0.9 et 1.0 placent les métadonnées à la fin du périphérique contenant, et la charge utile (le système de fichiers) commence au début du périphérique et est accessible directement sans passer par la couche de raid. Les formats 1.1 et 1.2 placent les métadonnées respectivement au milieu et au début du périphérique conteneur, de sorte que la charge utile est décalée.

Le programme d'installation d'Ubuntu crée des volumes au format de métadonnées 1.2, de sorte que vos données commencent après les métadonnées plutôt qu'au début de l'appareil.

Le moyen le plus simple d'accéder à ces données consiste à assembler le périphérique RAID. Dans un volume RAID-1, un seul périphérique suffit.

madadm -A /dev/sdc1

(Arrêtez-vous ici, sauf si vous aimez la douleur.)

Vous pouvez également accéder aux données à un décalage. Le seul point que je peux voir pour faire ceci est si vous devez travailler dans un très vieux noyau qui ne prend pas en charge les formats 1.x mdraid. Déterminez d'abord le décalage mdadm -E /dev/sdc1: recherchez la ligne Data Offset : SSS sectors. Un secteur mdadm fait 512 octets.

sectors=$(mdadm -E /dev/sdc1 | awk -F: '$1 ~ /Data offset/ {print $2}')
bytes=$(($sectors * 512))
losetup -f -o $bytes /dev/sdc1

En désespoir de cause, avec les formats 1.x, l'offset de données est stocké dans les octets 128–135 des métadonnées, little-endian¹. Les métadonnées 1.2 correspondent à 4096 octets après le début du périphérique.

Vous pouvez également modifier la table de partition pour la faire démarrer davantage. Soyez très prudent avec votre arithmétique. Ne faites cela que si vous souhaitez continuer à utiliser le disque à long terme dans un ancien système qui ne peut pas accéder au périphérique de raid.

¹ Ou avec l'endianité de la plateforme? Je ne suis pas sûr.


les données peuvent commencer à différents décalages (voir mdadm -E /dev/sdc1où exactement) mais certainement pas à 4k pour les métadonnées 1.2, car 4k est précisément l'endroit où les métadonnées sont stockées. Voir aussi unix.stackexchange.com/q/57477/22565
Stéphane Chazelas

@StephaneChazelas Oups, oui, pet de cerveau. Merci.
Gilles 'SO- arrête d'être méchant'

3
mdadm -A /dev/sdc1sorties que mdadm: device /dev/sdc1 exists but is not an md array.je suis allé un peu plus loin à l' utilisation mdadm et voir s'il y a des informations supplémentaires ... mdadm --misc --examine /dev/sdc1sorties mdadm: No md superblock detected on /dev/sdc1.. Existe-t-il un moyen de réécrire les superblocs sur ce disque pour le marquer comme disque disponible pour l'assemblage RAID?
Adam

@Gilles A me mdadm -E /dev/sdcrenvoie les informations suivantes: /dev/sdc: MBR Magic : aa55 Partition[0] : 1953520002 sectors at 63 (type 83) mais aucune information pour / dev / sdc1
Adam

1
@Adam Si mdadm ne trouve pas ses métadonnées, vous ne pouvez rien y faire: vous ne pouvez pas le forcer à faire quelque chose car il ne sait pas quoi faire. Vous devez rechercher un système de fichiers, et si les conseils de psusi ne mènent nulle part, les perspectives sont sombres. Peut-être qu'un vidage hexadécimal des premiers kilo-octets du disque pourrait inspirer quelqu'un (attention, il pourrait révéler des données confidentielles).
Gilles 'SO- arrête d'être méchant'

5

À ma grande surprise, j'ai pu / suis capable de récupérer les données en utilisant simplement avant tout .

L'aide reçue ici a été inestimable. Après avoir essayé une variété de combinaisons suggérées, ainsi que mes propres mix-ins, la méthode idéale (pour monter et utiliser le disque normalement) ne semblait plus être une option. Recourir à la récupération de données est ma solution dans ce cas.


Je me rends compte que c'était il y a quelque temps! Mais vous souvenez-vous si vous avez pu utiliser avant tout sans monter la partition?
PhillipOReilly

Désolé, je ne me souviens plus des détails de cela. : /
Adam

3

Il semble que vous ayez déjà zappé le superbloc mdadm. S'il existait auparavant et était au format 1.1 ou 1.2, alors le système de fichiers est probablement à 2048 secteurs décalés. Vous pouvez l'exécuter e2fsck /dev/sdc1?offset=2048pour forcer la recherche du système de fichiers à partir de ce décalage. S'il le trouve, vous pouvez modifier votre table de partition pour indiquer où le système de fichiers démarre réellement. Vous pouvez utiliser parted /dev/sdcet la unit scommande pour utiliser des unités de secteurs. printla table, notez le secteur de début et de fin, puis rmla partition, puis recréez-la avec mkpartet utilisez le même secteur de fin, mais ajoutez le décalage au secteur de début.

Si 2048 ne fonctionne pas, vous pouvez également essayer 1985.


Exécuter e2fsck /dev/sdc1?offset=2048(j'ai également exécuté offset = 1985) des sorties Bad magic number..Superblock invalid...et suggérer que le superbloc est corrompu et essayer d'exécuter e2fsck avec un superbloc alternatif. On dirait que je devrais lui fournir un superbloc alternatif pour aller de l'avant.
Adam

@Adam, non, il vous suffit d'obtenir le bon décalage. testdiskdevrait être en mesure d'effectuer une analyse détaillée et de corriger la table de partition pour vous.
psusi

testdiskest un territoire complètement nouveau pour moi. Un spectacle de base (analyse) No ext2, JFS, Reiser.. marker. Bad relative sector. No partition is bootable.Il fournit également les éléments suivants: 1 P Linux 0 1 1 121600 254 63 1953520002Comment puis-je donner un sens à cela pour aider la situation?
Adam

@Adam, je ne l'ai jamais utilisé moi-même, je sais juste qu'il est censé pouvoir rechercher et trouver le superbloc. Vous l'avez exécuté sur tout le disque, pas sur la partition, non?
psusi

Après avoir exécuté une analyse sur le disque complet, aucune partition n'a été détectée. Exécute actuellement une analyse approfondie maintenant. Si cela ne donne rien, je ne sais pas où aller à partir d'ici.
Adam
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.