Comment monter / récupérer des données sur un disque qui faisait partie d'un raid mdadm 1 sur une autre machine?
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 1 d'origine 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 onEt en 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/sdcDisk /dev/sdc: 1000.2 GB, 1000204886016 bytes255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x0005ed9cDevice Boot Start End Blocks Id System/dev/sdc1 63 1953520064 976760001 83 Linuxfichier -s/dev/sdc1
$file -s /dev/sdc1/dev/sdc1: datahexdump -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
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
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, petit-boutiste¹. Les métadonnées 1.2 représentent 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.
À ma grande surprise, j'ai pu/suis en mesure 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.
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. Tu peux courir e2fsck /dev/sdc1?offset=2048 pour le forcer à rechercher le 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/sdc et le unit s commande pour utiliser des unités de secteurs. print la table, notez les secteurs de début et de fin, puis rm la partition, puis recréez-la avec mkpart et utilisez le même secteur de fin, mais ajoutez l'offset au début secteur.
Si 2048 ne fonctionne pas, vous pouvez également essayer 1985.