Linux (Ubuntu 14.04, 16.04) – Software RAID (mdadm) – ustawienie dysku na ACTIVE ze SPARE po awarii.

Pewien czas temu w jednym z moich serwerów nastąpiła awaria sprzętu i w jej efekcie, jeden z dwóch dysków spiętych w softarową macierz RAID1 (mirror), został oznaczony jako SPARE, dysk oczywiście był w stu procentach sprawny, a sama awaria nie miała nic wspólnego z dyskami, czy też kontrolerem.

Po mimo wielu prób, m.in. dodania dysku na nowo do macierzy (mdadm –add), usuwania macierzy i odbudowania jej na nowo, zawsze dysk zostawał przez macierz potraktowany jako zapasowy (spare). Nawet po przeniesieniu dysków do innej maszyny, sytuacja cały czas się powtarzała.
Dzieje się tak dlatego, że gdy dochodzi do potencjalnie niebezpiecznego dla danych zajścia, zarządca macierzy oznacza dany dysk jako potencjalnie niepewny i ustawia go jako zapas.

Rozwiązanie problemu

Rozwiązaniem problemu okazało się użycie opcji –assume-clean przy odtwarzaniu popsutej macierzy. Parametr ten, przekazany do mdadm podczas odtwarzania macierzy, mówi że macierz którą tworzymy (rekonstruujemy), istniała już prędzej i jesteśmy pewni że dyski i dane na nich zawarte nie są uszkodzone, i poniekąd ‘forsujemy’ mdadm aby podjął akcję odtworzenia macierzy.
Oczywiście wszystkie zmiany, polecenia, wykonujemy na uprzednio wyłączonej macierzy.
A tak to wygląda w praktyce (w przykładzie /dev/md0):

# mdadm -S /dev/md0

Zatrzymujemy macierz, następnie odtwarzamy ją

# mdadm -Cv /dev/md0  --assume-clean --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

lub krócej

# mdadm -Cv /dev/md0 --assume-clean -l1 -n2 /dev/sd[ab]1

w powyższym, odtwarzamy md0, który jest macierzą raid1, która składa się z 2 dysków, sda1 oraz sdb1. Przy czym, aby nie uszkodzić danych (istotne w przypadku stripingu), bardzo ważna jest kolejność w jakiej podajemy dyski. Kolejność tą możemy sprawdzić w pliku /proc/mdstat

# cat /proc/mdstat

Po tym, macierz powinna działać i się synchronizować – RESYNC, możemy sprawdzić czy dyski się dodały i są ACTIVE przy pomocy polecenia

# mdadm -D /dev/md0

natomiast postęp resynca możemy również podejrzeć w /proc/mdstat

# cat /proc/mdstat

Jeśli wszystko jest w porządku, możemy zamątwać naszą macierz i sprawdzić czy pliki na niej zawarte są w porządku. Jeśli jednak korzystamy z LVM’a wewnątrz naszej macierzy, wówczas możemy skorzystać z lvmscan i jeśli oczekiwany LV jest widoczny, to również wszystko powinno być w porządku.
I to na tyle, w moim przypadku była to jedyna metoda, która pozwoliła na odbudowanie i ponowne ustawienie w stanie aktywnym wszystkich dysków macierzy po sprzętowym padzie.