Jak przywrócić do pracy nieaktywne urządzenie RAID?

Na pytanie bonusowe:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Odkryłem, że muszę dodać tablicę ręcznie w /etc/mdadm/mdadm.conf, aby Linux zamontował ją przy ponownym uruchomieniu. W przeciwnym razie dostaję dokładnie to co masz tutaj - md_d1-urządzenia, które są nieaktywne itp.

Plik conf powinien wyglądać jak poniżej - tzn. jedna linia ARRAY dla każdego urządzenia md. W moim przypadku brakowało nowych tablic w tym pliku, ale jeśli masz je wymienione, to prawdopodobnie nie jest to rozwiązanie twojego problemu.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Dodaj jedną tablicę na każde urządzenie md, i dodaj je po komentarzu zawartym powyżej, lub jeśli taki komentarz nie istnieje, na końcu pliku. Identyfikatory UUID uzyskasz wykonując operację sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Jak widzisz, możesz po prostu skopiować dane wyjściowe ze scan-result do pliku.

I uruchomić ubuntu desktop 10.04 LTS, i o ile pamiętam to zachowanie różni się od wersji serwerowej Ubuntu, jednak było to tak dawno temu stworzyłem moje md-devices na serwerze, że mogę się mylić. Może być też tak, że po prostu przegapiłem jakąś opcję.

W każdym razie, dodanie tablicy w pliku conf wydaje się załatwiać sprawę. Używam powyższego raid 1 i raid 5 od lat bez żadnych problemów.

Ostrzeżenie: Po pierwsze pozwól mi powiedzieć, że poniższe rozwiązanie (ze względu na użycie “–force”) wydaje mi się ryzykowne i jeśli masz nieodwracalne dane, zalecałbym wykonanie kopii partycji zanim zaczniesz próbować którejkolwiek z poniższych rzeczy. Jednakże, to zadziałało dla mnie.

Miałem ten sam problem, z tablicą pokazującą się jako nieaktywna, i nic co zrobiłem, włączając “mdadm –examine –scan >/etc/mdadm.conf”, jak sugerowali inni tutaj, nie pomogło w ogóle.

W moim przypadku, kiedy próbował uruchomić macierz RAID-5 po wymianie dysku, mówił, że jest brudna (przez dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Powodując, że pokazywała się jako nieaktywna w /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Zauważyłem, że wszystkie urządzenia miały te same zdarzenia na nich, z wyjątkiem dysku, który wymieniłem (/dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Jednak szczegóły macierzy pokazały, że miała ona 4 z 5 dostępnych urządzeń:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number Major Minor RaidDevice State
       0 8 4 0 inactive dirty /dev/sda4
       2 8 36 2 inactive dirty /dev/sdc4
       3 8 52 3 inactive dirty /dev/sdd4
       5 8 68 4 inactive dirty /dev/sde4

(Powyższe jest z pamięci na kolumnie “State”, nie mogę jej znaleźć w moim buforze przewijania wstecz).

Udało mi się to rozwiązać poprzez zatrzymanie tablicy, a następnie ponowne jej złożenie:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

W tym momencie tablica była w górze, działała z 4 z 5 urządzeń, a ja byłem w stanie dodać urządzenie zastępcze i jest ona odbudowywana. Mam dostęp do systemu plików bez problemu.

Miałem problemy z Ubuntu 10.04, gdzie błąd w FStab uniemożliwiał uruchomienie serwera.

Uruchomiłem tę komendę, jak wspomniano w powyższych rozwiązaniach:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Spowoduje to dołączenie wyników z “mdadm –examine –scan” do “/etc/mdadm/mdadm.conf”

W moim przypadku było to:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

To jest fakeraid 0. Moje polecenie w /etc/fstab do automatycznego montowania to:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Ważną rzeczą jest to, że masz “nobootwait” i “nofail”. Nobootwait pominie wszelkie komunikaty systemowe, które uniemożliwiają uruchomienie systemu. W moim przypadku było to na zdalnym serwerze, więc było to niezbędne.

Mam nadzieję, że to pomoże niektórym ludziom.

Możesz aktywować swoje urządzenie md za pomocą

mdadm -A /dev/md_d0

Przypuszczam, że jakiś skrypt startowy uruchamia się zbyt wcześnie, zanim jeden z członków RAID został wykryty lub jakiś podobny problem. Jako szybkie i brudne obejście, powinieneś być w stanie dodać tę linię do /etc/rc.local :

mdadm -A /dev/md_d0 && mount /dev/md_d0

Edycja: najwyraźniej twój plik /etc/mdadm/mdadm.conf nadal zawiera starą nazwę konfiguracji. Edytuj ten plik i zastąp występowanie md0 przez md0.

Miałem podobny problem… mój serwer nie chciał zamontować md2 po tym, jak powiększyłem partycje urządzeń towarzyszących. Po przeczytaniu tego wątku stwierdziłem, że urządzenie RAID md2 miało nowy UUID, a maszyna próbowała używać starego.

Zgodnie z sugestią… używając wyjścia ‘md2’ z

mdadm --examine --scan

edytowałem /etc/mdadm/mdadm.conf i zastąpiłem starą linijkę UUID linijką z powyższego polecenia i mój problem zniknął.

md_d0 : inactive sda4[0](S) wygląda źle dla macierzy RAID1. Wydaje się, że sugeruje, iż macierz nie ma żadnych aktywnych urządzeń i jedno urządzenie zapasowe (wskazywane przez (S), w przypadku uszkodzonego urządzenia zobaczyłbyś (F), a w przypadku urządzenia OK/aktywnego nie zobaczyłbyś nic) - w przypadku macierzy RAID1, która nie jest zdegradowana, powinny być co najmniej dwa urządzenia OK/aktywne (a w przypadku macierzy zdegradowanej co najmniej jedno urządzenie OK/aktywne) i nie można uaktywnić macierzy RAID1 bez żadnych nieuszkodzonych urządzeń zapasowych (ponieważ urządzenia zapasowe nie zawierają kopii danych, dopóki nie zostaną uaktywnione w przypadku awarii innego dysku). Jeśli dobrze odczytuję wyjście /proc/mdstat, nie będzie można aktywować macierzy w jej obecnym stanie.

Czy masz jakieś fizyczne dyski w maszynie, które nie zdążyły się rozkręcić? Czy na liście ls /dev/sd* są wszystkie dyski i partycje, których normalnie można by się spodziewać na tej maszynie?

Kiedy udajesz, że chcesz coś zrobić z /dev/md[012346789}, przechodzi on na /dev/md{126,127...}./dev/md0 jest nadal montowany na /dev/md126 lub /dev/md127 musisz:

umount /dev/md127 lub umount /dev/md126.

Jest to tymczasowe, aby umożliwić wykonywanie poleceń i niektórych aplikacji bez zatrzymywania systemu.

Prostym sposobem na uruchomienie macierzy, zakładając, że nie ma problemu sprzętowego i masz wystarczająco dużo dysków/partycji, aby uruchomić macierz, jest wykonanie następujących czynności:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20 --run

Może być tak, że z jakiegokolwiek powodu macierz jest w porządku, ale coś uniemożliwiło jej uruchomienie lub zbudowanie. W moim przypadku było to spowodowane tym, że mdadm nie wiedział, że oryginalna nazwa macierzy to md127 i wszystkie dyski były odłączone od tej macierzy. Podczas ponownego podłączania musiałem ręcznie złożyć (prawdopodobnie błąd, w którym mdadm myślał, że macierz jest już aktywna ze względu na starą nazwę macierzy offline).