Jak zamontować / odzyskać dane na dysku, który był częścią RAID 1 na innym komputerze?

Trochę tła

• Sam dysk „pracował” nad przyjacielem i mówi się, że jest nadal nienaruszony, nieuszkodzony i nadal można go montować / odzyskiwać
• Dysk był częścią rajdu programowego 1 na Ubuntu 12.04
• Drugi dysk w pierwotnym rajdzie 1 został sformatowany i wykorzystany do innego celu, pozostawiając bieżący dysk (ten, o którym mowa) nadal technicznie stanowi część nalotu, który już nie istnieje

Co już próbowałem

• Podstawowy montaż

  • Dodałem wpis do fstab, oznaczyłem dysk jako ext3 / ext4 i próbowałem zamontować.

  • Po zamontowaniu pojawia się następujący błąd

    wrong fs type, bad option, bad superblock on

  • I w dmesg

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

• Próbowałem znaleźć typ systemu plików dysku i wymyśliłem

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

Gdzie potrzebuję pomocy / Moje pytania

• Czy istnieje sposób na konwersję dysku na ext4 bez uszkodzenia danych?
• Czy istnieje prosty sposób na zamontowanie dysku typu Linux 83 i odzyskanie danych?
• Mam inny dysk, który jest obecnie wolny, na wypadek, gdyby można było jakoś odbudować nalot
• Moim głównym celem jest odzyskanie danych z dysku. Jestem otwarty na wszystkie opcje.

Aktualizacja

Dane wyjściowe niektórych poleceń

• 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
  

• plik -s / dev / sdc1

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

• hexdump -C -n 32256 / dev / sdc (Nie jestem pewien, czy to może pomóc, czy nie)

  $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
  

Działa to doskonale w Ubuntu 14.04:

sudo -i
mdadm --assemble --scan

Dostaniesz:

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

Następnie zamontuj i zobacz swoje pliki:

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

Linux mdraid ma kilka formatów metadanych . Formaty 0.9 i 1.0 umieszczają metadane na końcu urządzenia zawierającego, a ładunek (system plików) rozpoczyna się na początku urządzenia i można uzyskać do niego bezpośredni dostęp bez przechodzenia przez warstwę rajdową. Formaty 1.1 i 1.2 umieszczają metadane odpowiednio na środku i na początku zawierającego urządzenia, więc ładunek jest przesunięty.

Instalator Ubuntu tworzy woluminy w formacie metadanych 1.2, więc dane zaczynają się po metadanych zamiast na początku urządzenia.

Najprostszym sposobem na uzyskanie dostępu do tych danych jest złożenie urządzenia rajdowego. W woluminie RAID-1 wystarczy jedno urządzenie.

madadm -A /dev/sdc1

(Zatrzymaj się tutaj, chyba że lubisz ból.)

Możesz również uzyskać dostęp do danych z przesunięciem. Jedyną rzeczą, jaką mogę to zrobić, jest to, że musisz pracować w bardzo starym jądrze, które nie obsługuje formatów mdraid 1.x. Najpierw określ przesunięcie mdadm -E /dev/sdc1: poszukaj linii Data Offset : SSS sectors. Sektor mdadm ma 512 bajtów.

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

W desperacji, w formatach 1.x, przesunięcie danych jest przechowywane w bajtach 128–135 metadanych, little-endian¹. 1.2 metadane to 4096 bajtów po uruchomieniu urządzenia.

Możesz także zmienić tablicę partycji, aby zaczęła się dalej. Bądź bardzo ostrożny z arytmetyką. Zrób to tylko, jeśli chcesz nadal używać dysku przez długi czas w starym systemie, który nie ma dostępu do urządzenia rajdowego.

¹ _{Czy z endianizmem platformy? Nie jestem pewny.}

Ku mojemu zdziwieniu udało mi się odzyskać dane, wykorzystując przede wszystkim .

Otrzymana pomoc była nieoceniona. Po wypróbowaniu różnych sugerowanych kombinacji, a także własnych wtyczek, idealna metoda (do zamontowania i używania dysku w normalny sposób) nie wydawała się już opcją. W tym przypadku moim rozwiązaniem jest uciekanie się do odzyskiwania danych.

Wygląda na to, że już zablokowałeś superblok mdadm. Jeśli kiedyś tam był i miał format 1.1 lub 1.2, najprawdopodobniej system plików ma przesunięte 2048 sektorów. Możesz uruchomić, e2fsck /dev/sdc1?offset=2048aby wymusić wyszukiwanie systemu plików od tego przesunięcia. Jeśli go znajdzie, możesz zmodyfikować tablicę partycji, aby wskazywała miejsce, w którym system plików faktycznie się uruchamia. Możesz użyć parted /dev/sdci unit spolecenia, aby użyć jednostek sektorów. printw tabeli, zanotuj sektor początkowy i końcowy, następnie rmpartycję, a następnie utwórz ją ponownie mkparti użyj tego samego sektora końcowego, ale dodaj przesunięcie do sektora początkowego.

Jeśli 2048 nie działa, możesz także spróbować 1985.