Ludzie, proszę, pomóżcie - jestem nowicjuszem z dużym bólem głowy pod ręką (idealna sytuacja sztormowa).

Mam 3 1 TB HDD na moim Ubuntu 11.04 skonfigurowanym jako Raid oprogramowania 5. Dane były kopiowane co tydzień na inny oddzielny dysk twardy komputera, aż całkowicie się nie powiodło i został wyrzucony. Kilka dni temu mieliśmy awarię zasilania, a po ponownym uruchomieniu moje pudełko nie zniosło nalotu. W mojej nieskończonej mądrości weszłam

mdadm --create -f...

polecenie zamiast

mdadm --assemble

i nie zauważyłem parodii, którą zrobiłem później. Rozpoczęła degradację tablicy i przystąpiła do jej budowy i synchronizacji, co zajęło ~ 10 godzin. Po powrocie zobaczyłem, że tablica działa poprawnie, ale nalot nie

Mam na myśli, że poszczególne dyski są podzielone na partycje (typ partycji f8), ale md0urządzenie nie. Z przerażeniem zdając sobie sprawę z tego, co zrobiłem, próbuję znaleźć jakieś rozwiązania. Po prostu modlę się, aby --createnie zastąpiło to całej zawartości twardego sterownika.

Czy ktoś mógłby mi w tym pomóc - dane na dysku są bardzo ważne i unikalne ~ 10 lat zdjęć, dokumentów itp.

Czy jest możliwe, że poprzez określenie uczestniczących dysków twardych w niewłaściwej kolejności można je mdadmzastąpić? kiedy robię

mdadm --examine --scan 

Dostaję coś takiego ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Co ciekawe, nazwa była „nalotowa”, a nie nazwa hosta z dodatkiem: 0.

Oto „skonfigurowane” wpisy konfiguracji:

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Zgodnie z sugestiami wyczyściłem superbloki i odtworzyłem tablicę z --assume-cleanopcją, ale bez powodzenia.

Czy jest jakieś narzędzie, które pomoże mi odzyskać przynajmniej część danych? Czy ktoś może mi powiedzieć, co i jak robi mdadm -create, gdy synchronizuje się, aby zniszczyć dane, abym mógł napisać narzędzie do cofnięcia się co zrobiono?

Po odtworzeniu nalotu uruchamiam fsck.ext4 / dev / md0 i oto wyjście

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22 grudnia 2010) fsck.ext4: Niepoprawny superblok, próba wykonania kopii zapasowej bloków ... fsck.ext4: Zła liczba magiczna w super- blokuj podczas próby otwarcia / dev / md0

Nie można odczytać superbloku lub nie opisuje on prawidłowego systemu plików ext2. Jeśli urządzenie jest prawidłowe i naprawdę zawiera system plików ext2 (a nie swap, ufs lub coś innego), to superblok jest uszkodzony i możesz spróbować uruchomić e2fsck z alternatywnym superblokiem: e2fsck -b 8193

Sugestię Per Shanesa próbowałem

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

i uruchamiam fsck.ext4 z każdym blokiem kopii zapasowej, ale wszystkie zwróciły:

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Jakieś sugestie?

Pozdrowienia!

Ok - coś mnie wkurzało w związku z twoim problemem, więc odpaliłem maszynę wirtualną, aby zanurkować w zachowanie, którego należy się spodziewać. Zaraz dojdę do tego, co mnie wkurzało; najpierw pozwól mi powiedzieć:

Wykonaj kopię zapasową tych dysków przed próbą czegokolwiek !!

Możliwe, że już wyrządziłeś szkody poza tym, co zrobiła ponowna synchronizacja; czy możesz wyjaśnić, co miałeś na myśli, mówiąc:

Zgodnie z sugestiami wyczyściłem superbloki i odtworzyłem tablicę z opcją --assume-clean, ale bez powodzenia.

Jeśli prowadziłeś a mdadm --misc --zero-superblock, powinieneś być w porządku.

W każdym razie, odszukaj kilka nowych dysków i chwyć ich dokładne bieżące obrazy, zanim zrobisz cokolwiek, co może zrobić więcej zapisu na tych dyskach.

dd if=/dev/sdd of=/path/to/store/sdd.img

To powiedziawszy ... wygląda na to, że dane przechowywane na tych rzeczach są szokująco odporne na błędne resynchronizacje. Czytaj dalej, jest nadzieja i może to być dzień, w którym osiągnąłem limit długości odpowiedzi.

Najlepszy scenariusz

Rzuciłem maszynę wirtualną, aby odtworzyć scenariusz. Dyski mają tylko 100 MB, więc nie czekałbym wiecznie przy każdej ponownej synchronizacji, ale w przeciwnym razie powinna to być dość dokładna reprezentacja.

Zbuduj tablicę tak ogólnie i domyślnie, jak to możliwe - fragmenty 512 tys., Układ symetryczny lewy, dyski w kolejności literowej. Nic specjalnego.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Jak na razie dobrze; stwórzmy system plików i umieśćmy na nim trochę danych.

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Dobrze. Mamy na nim system plików i niektóre dane („dane” datafilei losowe dane o wartości 5 MB z tym hashem SHA1 randomdata); zobaczmy, co się stanie, gdy dokonamy odtworzenia.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Ponowna synchronizacja zakończyła się bardzo szybko z tymi małymi dyskami, ale tak się stało. Oto, co mnie wcześniej denerwowało; twój fdisk -lwynik. mdOczekuje się, że brak tablicy partycji na urządzeniu nie stanowi żadnego problemu. Twój system plików znajduje się bezpośrednio na fałszywym urządzeniu blokowym bez tablicy partycji.

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Tak, brak tablicy partycji. Ale...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Idealnie poprawny system plików po ponownej synchronizacji. To dobrze; sprawdźmy nasze pliki danych:

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Solidny - w ogóle brak uszkodzenia danych! Ale dzieje się tak z dokładnie tymi samymi ustawieniami, więc nic nie było odwzorowane inaczej między dwiema grupami RAID. Opuśćmy to, zanim spróbujemy to zepsuć.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

Cofając się

Zanim spróbujemy to przełamać, porozmawiajmy o tym, dlaczego trudno to przełamać. RAID 5 działa przy użyciu bloku parzystości, który chroni obszar o tym samym rozmiarze co blok na każdym innym dysku w macierzy. Parzystość nie jest tylko na jednym konkretnym dysku, jest równomiernie obracana wokół dysków, aby lepiej rozłożyć obciążenie odczytu na dyskach podczas normalnej pracy.

Operacja XOR do obliczenia parzystości wygląda następująco:

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

Zatem parzystość jest rozłożona na dyski.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

Ponowna synchronizacja jest zwykle wykonywana podczas wymiany martwego lub brakującego dysku; Robi się to również w mdadm createcelu zapewnienia, że ​​dane na dyskach są zgodne z geometrią RAID. W takim przypadku ostatnim dyskiem w specyfikacji macierzy jest dysk „zsynchronizowany” - do synchronizacji wykorzystywane są wszystkie istniejące dane na innych dyskach.

Zatem wszystkie dane na „nowym” dysku są usuwane i odbudowywane; albo budowanie świeżych bloków danych z bloków parzystości dla tego, co powinno tam być, albo budowanie świeżych bloków parzystości.

Fajne jest to, że procedura dla obu tych rzeczy jest dokładnie taka sama: operacja XOR na danych z reszty dysków. Proces resynchronizacji w tym przypadku może mieć w swoim układzie, że określony blok powinien być blokiem parzystości, i myślę, że buduje nowy blok parzystości, podczas gdy w rzeczywistości odtwarza stary blok danych. Więc nawet jeśli myśli, że to buduje:

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... może to być po prostu przebudowa DISK5z powyższego układu.

Dlatego dane mogą pozostać spójne, nawet jeśli tablica jest źle zbudowana.

Rzucanie małpy w dzieła

(nie klucz; cała małpa)

Test 1:

Zróbmy tablicę w niewłaściwej kolejności! sdc, a sddnastępnie sdb…

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Ok, to wszystko dobrze i dobrze. Czy mamy system plików?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Nie! Dlaczego? Ponieważ chociaż wszystkie dane są dostępne, są one w niewłaściwej kolejności; to, co kiedyś było 512 KB A, a następnie 512 KB B, A, B i tak dalej, zostało teraz przetasowane do B, A, B, A. Dysk wygląda teraz jak szarpanie się do kontrolera systemu plików, nie będzie działać. Dane wyjściowe mdadm --misc -D /dev/md1dają nam więcej szczegółów; To wygląda tak:

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

Kiedy powinno to wyglądać tak:

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

To wszystko dobrze i dobrze. Tym razem nadpisaliśmy całą masę bloków danych nowymi blokami parzystości. Utwórz ponownie, teraz we właściwej kolejności:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Zgrabnie, wciąż tam jest system plików! Nadal masz dane?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Sukces!

Test 2

Ok, zmieńmy wielkość porcji i zobaczmy, czy to nas zepsuje.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Tak, tak, jest ustawiony tak, jak skonfigurowano w ten sposób. Ale czy możemy wyzdrowieć?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Sukces ponownie!

Test 3

To jest ten, o którym myślałem, że na pewno zabije dane - zróbmy inny algorytm układu!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

Straszne i złe - myśli, że coś znalazło i chce coś naprawić! Ctrl+ C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

Ok, kryzys uniknął. Zobaczmy, czy dane są nadal nienaruszone po ponownej synchronizacji z niewłaściwym układem:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Sukces!

Test 4

Udowodnijmy również, że zerowanie superbloku nie jest szkodliwe naprawdę szybko:

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Tak, nic wielkiego.

Test 5

Rzućmy na to wszystko, co mamy. Wszystkie 4 poprzednie testy łącznie.

• Zła kolejność urządzeń
• Zły rozmiar porcji
• Błędny algorytm układu
• Zerowane superbloki (zrobimy to między obiema kreacjami)

Naprzód!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

Werdykt?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Łał.

Wygląda więc na to, że żadne z tych działań w żaden sposób nie uszkodziło danych. Szczerze mówiąc, byłem bardzo zaskoczony tym wynikiem; Spodziewałem się umiarkowanych szans na utratę danych przy zmianie wielkości porcji i pewną wyraźną utratę przy zmianie układu. Nauczyłem się dziś czegoś.

Więc .. Jak mogę uzyskać moje dane?

Bardzo dużo informacji na temat starego systemu byłoby bardzo pomocne. Jeśli znasz typ systemu plików, jeśli masz jakieś stare kopie /proc/mdstatz informacjami o kolejności dysków, algorytmie, wielkości porcji i wersji metadanych. Czy masz skonfigurowane powiadomienia e-mail mdadm? Jeśli tak, znajdź starą; jeśli nie, sprawdź /var/spool/mail/root. Sprawdź, ~/.bash_historyczy jest tam oryginalna wersja.

Lista rzeczy, które powinieneś zrobić:

1. Wykonaj kopię zapasową dysków ddprzed zrobieniem czegokolwiek !!
2. Spróbuj fsckużyć bieżącego, aktywnego md - być może właśnie zdarzyło Ci się budować w takiej samej kolejności jak poprzednio. Jeśli znasz typ systemu plików, jest to pomocne; użyj tego konkretnego fscknarzędzia. Jeśli którekolwiek z narzędzi oferuje coś do naprawy, nie pozwól im, dopóki nie masz pewności, że faktycznie znalazły prawidłowy system plików! Jeśli fsckoferujesz coś dla ciebie, nie wahaj się zostawić komentarza z pytaniem, czy to rzeczywiście pomaga, czy tylko nuke danych.
3. Spróbuj zbudować tablicę z różnymi parametrami. Jeśli masz stary /proc/mdstat, możesz po prostu naśladować to, co pokazuje; jeśli nie, to jesteś trochę w ciemności - wypróbowanie wszystkich różnych zamówień dysków jest rozsądne, ale sprawdzanie każdego możliwego rozmiaru porcji przy każdym możliwym zamówieniu jest daremne. Dla każdego fscksprawdź, czy dostaniesz coś obiecującego.

To tyle. Przepraszamy za powieść, jeśli masz pytania, zostaw komentarz. Powodzenia!

przypis: poniżej 22 tysięcy znaków; 8k + powyżej limitu długości

Jeśli masz szczęście, możesz odzyskać swoje pliki dzięki oprogramowaniu do odzyskiwania, które może odczytać uszkodzoną macierz RAID-5. Zero Assumption Recovery to taki, z którym miałem wcześniej sukces.

Nie jestem jednak pewien, czy proces tworzenia nowej tablicy przeszedł i zniszczył wszystkie dane, więc może to być wysiłek ostatniej szansy.

Miałem podobny problem:
po awarii programowej macierzy RAID5 odpaliłem mdadm --createją --assume-clean, nie dając jej , i nie mogłem już zamontować macierzy. Po dwóch tygodniach kopania w końcu przywróciłem wszystkie dane. Mam nadzieję, że poniższa procedura pozwoli komuś zaoszczędzić czas.

Krótko mówiąc

Problem był spowodowany faktem, że mdadm --createpowstała nowa tablica, która różniła się od oryginału w dwóch aspektach:

• inna kolejność partycji
• inne przesunięcie danych RAID

Jak pokazuje wspaniała odpowiedź Shane'a Maddena , mdadm --createw większości przypadków nie niszczy danych! Po znalezieniu kolejności partycji i przesunięcia danych mogłem przywrócić tablicę i wyodrębnić z niej wszystkie dane.

Wymagania wstępne

Nie miałem kopii zapasowych superbloków RAID, więc wiedziałem tylko, że była to macierz RAID5 na 8 partycjach utworzonych podczas instalacji Xubuntu 12.04.0. Miał system plików ext4. Inną ważną wiedzą była kopia pliku, który również był przechowywany w macierzy RAID.

Przybory

Do wykonania całej pracy wykorzystano live CD Xubuntu 12.04.1. W zależności od sytuacji możesz potrzebować niektórych z następujących narzędzi:

wersja mdadm, która pozwala określić przesunięcie danych

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - wyszukiwanie danych binarnych

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount i kalkulator szesnastkowy - standardowe narzędzia z repozytoriów

Zacznij od pełnej kopii zapasowej

Nazwy plików urządzeń, np. /dev/sda2 /dev/sdb2Itp., Nie są trwałe, dlatego lepiej zapisać numery seryjne dysków podane przez

sudo hdparm -I /dev/sda

Następnie podłącz zewnętrzny dysk twardy i wykonaj kopię zapasową każdej partycji macierzy RAID w następujący sposób:

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Określ oryginalny układ RAID5

Różne układy są opisane tutaj: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Aby dowiedzieć się, jak pasy danych zostały zorganizowane w oryginalnej tablicy, potrzebujesz kopii losowo wyglądającego pliku, o którym wiesz, że był przechowywane w tablicy. Domyślnie używany obecnie rozmiar porcji mdadmto 512 KB. W przypadku tablicy N partycji potrzebny jest plik o rozmiarze co najmniej (N + 1) * 512 KB. Plik JPEG lub wideo jest dobry, ponieważ zapewnia stosunkowo unikatowe ciągi danych binarnych. Załóżmy, że nasz plik nazywa się picture.jpg. Czytamy 32 bajty danych w pozycjach N + 1, zaczynając od 100k i zwiększając o 512k:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

Następnie wyszukujemy wystąpienia wszystkich tych bajtów na wszystkich naszych surowych partycjach, więc łącznie (N + 1) * N poleceń, jak poniżej:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

Te polecenia można uruchamiać równolegle dla różnych dysków. Skanowanie partycji 38 GB zajęło około 12 minut. W moim przypadku każdy 32-bajtowy ciąg został znaleziony tylko raz spośród wszystkich ośmiu dysków. Porównując odsunięcia zwrócone przez bgrep, uzyskuje się taki obraz:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

Widzimy normalny układ symetryczny lewy , który jest domyślny mdadm. Co ważniejsze, teraz znamy kolejność partycji. Nie wiemy jednak, która partycja jest pierwsza w tablicy, ponieważ można je cyklicznie przenosić.

Zwróć także uwagę na odległość między znalezionymi odsunięciami. W moim przypadku było to 512 KB. Rozmiar porcji może być faktycznie mniejszy niż ta odległość, w takim przypadku rzeczywisty układ będzie inny.

Znajdź oryginalny rozmiar porcji

Używamy tego samego pliku picture.jpgdo odczytu 32 bajtów danych w różnych odstępach czasu. Wiemy z góry, że dane przy przesunięciu 100k leżą /dev/sdh2, przy przesunięciu 612k jest na /dev/sdb2, a na 1124k jest na /dev/sdd2. To pokazuje, że wielkość porcji nie jest większa niż 512 KB. Sprawdzamy, czy nie jest mniejszy niż 512 KB. W tym celu zrzucamy testowanie z przesunięciem 356k i sprawdzamy, na której partycji on siedzi:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

Jest na tej samej partycji co offset 612k, co wskazuje, że wielkość porcji nie jest 256KB. W podobny sposób eliminujemy mniejsze porcje. Skończyło się na tym, że fragmenty 512 KB są jedyną możliwością.

Znajdź pierwszą partycję w układzie

Teraz znamy kolejność partycji, ale nie wiemy, która partycja powinna być pierwsza i jakie przesunięcie danych RAID zostało użyte. Aby znaleźć te dwie niewiadome, stworzymy macierz RAID5 z poprawnym układem porcji i małym przesunięciem danych, i szukamy początku naszego systemu plików w tej nowej macierzy.

Na początek tworzymy tablicę z prawidłową kolejnością partycji, którą znaleźliśmy wcześniej:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Sprawdzamy, czy zamówienie jest przestrzegane przez wystawienie

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

Teraz określamy przesunięcia znanych bajtów N + 1 w macierzy RAID. Na noc uruchamiam skrypt (Live CD nie pyta o hasło w sudo :):

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Dane wyjściowe z komentarzami:

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

Na podstawie tych danych widzimy, że trzeci ciąg nie został znaleziony. Oznacza to, że porcja /dev/sdd2jest używana do parzystości. Oto ilustracja pozycji parzystości w nowej tablicy:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

Naszym celem jest ustalenie, z której partycji należy uruchomić tablicę, aby przesunąć porcje parzystości we właściwe miejsce. Ponieważ parzystość powinna zostać przesunięta o dwa fragmenty w lewo, sekwencja podziału powinna zostać przesunięta o dwa kroki w prawo. Dlatego poprawny układ dla tego przesunięcia danych to ahbdcefg:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

W tym momencie nasza macierz RAID zawiera dane we właściwej formie. Możesz mieć szczęście, że przesunięcie danych RAID jest takie samo jak w oryginalnej macierzy, a wtedy najprawdopodobniej będziesz w stanie zamontować partycję. Niestety to nie był mój przypadek.

Sprawdź spójność danych

Sprawdzamy, czy dane są spójne na pasku fragmentów, wyodrębniając kopię picture.jpgz tablicy. W tym celu znajdujemy przesunięcie 32-bajtowego ciągu o wartości 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Następnie odejmujemy od wyniku 100 * 1024 i używamy uzyskanej wartości dziesiętnej w skip=parametrze dla dd. Jest count=to rozmiar picture.jpgw bajtach:

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Sprawdź, czy extract.jpgto samo co picture.jpg.

Znajdź przesunięcie danych RAID

Drobna sprawa: domyślne przesunięcie danych dla mdadmwersji 3.2.3 wynosi 2048 sektorów. Ale z czasem wartość ta uległa zmianie. Jeśli pierwotna tablica używała mniejszego przesunięcia danych niż bieżąca mdadm, wówczas mdadm --createbez --assume-cleanmoże zastąpić początek systemu plików.

W poprzedniej sekcji utworzyliśmy macierz RAID. Sprawdź, jakie przesunięcie danych RAID miał, wydając dla niektórych poszczególnych partycji:

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512-bajtowych sektorów to 1 MB. Ponieważ wielkość porcji wynosi 512 KB, bieżące przesunięcie danych to dwie porcje.

Jeśli w tym momencie masz przesunięcie dwuczęściowe, prawdopodobnie jest ono wystarczająco małe i możesz pominąć ten akapit.
Tworzymy macierz RAID5 z przesunięciem danych o jeden fragment 512 KB. Rozpoczęcie jednego fragmentu wcześniej przesuwa parzystość o krok w lewo, dlatego kompensujemy przesunięcie sekwencji podziału o krok w lewo. Dlatego dla przesunięcia danych 512 KB prawidłowy układ to hbdcefga. Używamy wersji mdadmobsługującej przesunięcie danych (patrz sekcja Narzędzia). To zajmuje przesunięcie w kilobajtach:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Teraz szukamy prawidłowego superbloku ext4. Strukturę superbloku można znaleźć tutaj: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Skanujemy początek tablicy pod kątem występowania liczby magicznej, s_magica następnie s_statei s_errors. Do obejrzenia są:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Przykładowe polecenie:

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

Magiczna liczba rozpoczyna 0x38 bajtów w superbloku, więc odejmujemy 0x38, aby obliczyć przesunięcie i zbadać cały superblok:

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

To wydaje się być prawidłowym superblokiem. s_log_block_sizepole 0x18 ma wartość 0002, co oznacza, że ​​rozmiar bloku wynosi 2 ^ (10 + 2) = 4096 bajtów. s_blocks_count_lopod 0x4 jest blokami 03f81480, co stanowi 254 GB. Wygląda dobrze.

Teraz skanujemy występowanie pierwszych bajtów superbloku, aby znaleźć jego kopie. Zwróć uwagę na przerzucanie bajtów w porównaniu z wyjściem zrzutu heksowego:

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

Jest to idealnie dopasowane do oczekiwanych pozycji zapasowych bloków superblokowych:

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Dlatego system plików zaczyna się od przesunięcia 0xdc80000, tj. 225792 KB od początku partycji. Ponieważ mamy 8 partycji, z których jedna służy do parzystości, dzielimy przesunięcie przez 7. Daje to 33030144 bajtów przesunięcia na każdej partycji, czyli dokładnie 63 porcje RAID. A ponieważ obecne przesunięcie danych RAID to jedna porcja, dochodzimy do wniosku, że pierwotne przesunięcie danych wynosiło 64 porcje lub 32768 KB. Przesunięcie hbdcefga63 razy w prawo daje układ bdcefgah.

W końcu budujemy prawidłową macierz RAID:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

Voilà!

Miałem podobny problem. Sformatowałem i ponownie zainstalowałem dysk OS / boot z czystą instalacją Ubuntu 12.04, a następnie uruchomiłem polecenie mdadm --create ... i nie mogłem go zamontować.

Powiedział, że nie ma prawidłowego superbloku lub partycji.

Co więcej, kiedy zatrzymałem nalot mdadm, nie mogłem już zamontować zwykłego urządzenia.

Byłem w stanie naprawić superblok za pomocą mke2fs i e2fsck:

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

Następnie pobiegł:

e2fsck -b 32768 -y /dev/sdc1

To przywróciło superblok, żebym mógł zamontować i odczytać dysk.

Aby tablica działała bez niszczenia superbloku lub partycji, użyłem kompilacji:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

Po weryfikacji danych dodam drugi dysk:

mdadm --add /dev/md0 /sdd1

Właśnie aktualizuję niektóre informacje podane wcześniej. Miałem 3-dyskową macierz RAID5 działającą poprawnie, gdy moja płyta główna uległa awarii. Tablica zawierała / dev / md2 jako partycję / home 1.2TB i / dev / md3 jako partycję / var 300GB.

Miałem dwie kopie zapasowe „ważnych” rzeczy i kilka przypadkowych rzeczy, które wziąłem z różnych części Internetu, które naprawdę powinienem było przejrzeć i selektywnie zrzucić. Większość kopii zapasowych została podzielona na pliki .tar.gz o wielkości 25 GB lub mniejszej, a także utworzono kopię zapasową oddzielnej kopii pliku / etc.

Reszta systemu plików była przechowywana na dwóch małych dyskach RAID0 o pojemności 38 GB.

Mój nowy komputer był podobny do starego sprzętu i uruchomiłem go po prostu podłączając wszystkie pięć dysków i wybierając stare ogólne jądro. Miałem więc pięć dysków z czystymi systemami plików, chociaż nie byłem pewien, czy dyski są w odpowiedniej kolejności, i musiałem zainstalować nową wersję Debian Jessie, aby mieć pewność, że będę mógł zaktualizować maszynę w razie potrzeby i uporządkować inne problemy.

Po zainstalowaniu nowego systemu ogólnego na dwóch dyskach Raid0 zacząłem ponownie układać tablice. Chciałem mieć pewność, że mam dyski w odpowiedniej kolejności. Powinienem był wydać:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Ale ja nie. Wygląda na to, że mdadm jest całkiem sprytny i ma identyfikator użytkownika, może dowiedzieć się, które dyski idą gdzie. Nawet jeśli bios oznacza / dev / sdc jako / sda, mdadm poprawnie go połączy (choć YMMV).

Zamiast tego wydałem: mdadm --create /dev/md2 without the --assume-cleani zezwoliłem na resynchronizację na / dev / sde1, aby zakończyć. Kolejnym błędem, jaki popełniłem, była praca na / dev / sdc1 zamiast na ostatnim dysku w / dev / md2, / sde1. Za każdym razem, gdy mdadm pomyśli, że jest problem, jest to ostatni dysk, który zostaje wyrzucony lub zsynchronizowany.

Po tym mdadm nie mógł znaleźć żadnego superbloku, a e2fsck -n też nie mógł.

Po znalezieniu tej strony przeszedłem procedurę próby znalezienia sekwencji napędów (gotowe), sprawdzenia poprawności danych (zweryfikowano 6 MB pliku 9 MB), dostałem dyski we właściwej kolejności, cde, złapałem uuida z / md2 i / md3 ze starego pliku /etc/mdadm.conf i próbowałem asemblowania.

Cóż, /dev/md3zaczął i mdadm --misc -D /dev/md3pokazał trzy zdrowe partycje oraz dyski w odpowiedniej kolejności. /dev/md2też wyglądał dobrze, dopóki nie próbowałem zamontować systemu plików.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

System plików odmówił zamontowania, a e2fsck nie mógł znaleźć żadnych superbloków. Ponadto, podczas sprawdzania superbloków, jak opisano powyżej, całkowita liczba bloków znaleziona jako a880 0076 lub a880 0076 lub 5500 1176 nie zgadza się z pojemnością dysku wynoszącą 1199,79, zgłosiła mój mdadm. Również żadna z lokalizacji „superbloków” nie była zgodna z danymi w powyższych postach.

Utworzyłem kopię zapasową wszystkich plików / var i przygotowałem się do wyczyszczenia dysków. Aby sprawdzić, czy można wyczyścić tylko / md2, (w tym momencie nie miałem już nic do stracenia), wyłączam następujące elementy:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

Wszystko wydawało się w porządku, z wyjątkiem zmiany na UUID. Po kilku kolejnych sprawdzeniach zapisałem 600 GB danych z kopii zapasowej na / dev / md2. Następnie odmontowano i próbował ponownie zamontować dysk:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

Czy ty żartujesz? co z moim 600 GB na pliku?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

Ah - łatwo naprawić. odkomentowano jedną linię w /etc/mdadm.conf

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Yippie!