Odzyskiwanie macierzy RAID 1 w systemie ZimaOS po ponownej instalacji systemu

Jeśli ZimaOS zostanie przeinstalowany, a istniejący RAID 1 pojawi się jako nieużywane dyski, nie klikaj od razu Utwórz RAID. Ponowne utworzenie lub sformatowanie macierzy może zniszczyć dane, które nadal znajdują się na dyskach członkowskich.

Pierwszą ścieżką odzyskiwania powinna być obecna oficjalna metoda ZimaOS: przywrócenie zapisanej local-storage.db plik z poprzedniej instalacji systemu. Poradnik społeczności opisany na tej stronie przedstawia bardziej inwazyjną metodę awaryjną dla trudniejszego przypadku, w którym nie wykonano kopii zapasowej tej bazy danych. Metoda ta została przetestowana w ZimaOS 1.6.1, ale obejmuje destrukcyjne operacje RAID i należy ją rozważać dopiero po niezależnym skopiowaniu i zweryfikowaniu danych źródłowych.

Pierwszy wybór: przywróć local-storage.db

ZimaOS przechowuje informacje o konfiguracji pamięci masowej w:

/ZimaOS-HD/.casaos/db/local-storage.db

Obecny oficjalny przewodnik odzyskiwania zaleca pobranie tego pliku przed reinstalacją systemu, a następnie umieszczenie go z powrotem w tym samym katalogu po zainstalowaniu nowego ZimaOS i ponownym uruchomieniu.

Oficjalne odzyskiwanie RAID w ZimaOS po reinstalacji

Jeśli nadal masz dostęp do starego dysku systemowego, spróbuj odzyskać tę bazę danych, zanim wykonasz jakiekolwiek działania na dyskach członkowskich RAID.

Dlaczego macierz danych może nadal być nienaruszona

ZimaOS korzysta z programowej macierzy RAID systemu Linux. Dyski członkowskie mogą zachować metadane RAID nawet wtedy, gdy nowa instalacja ZimaOS nie ma już starej bazy danych pamięci masowej. Dlatego dyski mogą być fizycznie obecne, podczas gdy interfejs nie rozpoznaje już pierwotnej puli.

ZimaOS 1.6 wprowadził również ulepszone odzyskiwanie metadanych RAID i ponowną identyfikację, dlatego nie należy zakładać, że problem pierwotnie występujący w jednym systemie pojawi się identycznie w każdej nowszej wersji.

Nie twórz nowej macierzy RAID, dopóki nie zostanie ustalony sposób odzyskiwania danych

Jeśli dyski zawierają potrzebne dane, unikaj:

• formatowania któregokolwiek dysku członkowskiego;
• tworzenia nowej macierzy RAID na tych samych dyskach;
• uruchamiania wipefs lub mdadm --zero-superblock przedwcześnie;
• zgadywania, który /dev/sdX które jest urządzeniem.

Przed rozpoczęciem jakichkolwiek działań naprawczych zidentyfikuj dyski na podstawie modelu, numeru seryjnego i pojemności, zamiast polegać wyłącznie na oznaczeniach urządzeń.

Zweryfikuj metadane RAID w trybie tylko do odczytu

Autor poradnika społeczności najpierw użył inspekcji tylko do odczytu, aby potwierdzić, że oba dyski RAID 1 nadal należały do tej samej macierzy.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

W przypadku sprawnego RAID 1 oba dyski członkowskie powinny zgłaszać ten sam identyfikator UUID macierzy oraz zgodne metadane RAID. Jeśli brakuje jednego dysku, macierz działa w trybie zdegradowanym lub zgłasza inne metadane, zatrzymaj się i skorzystaj z pomocy w odzyskiwaniu danych, zamiast postępować według ogólnej instrukcji odbudowy.

Zmontuj starą macierz i zamontuj ją w trybie tylko do odczytu

W przypadku zaawansowanego odzyskiwania montaż w trybie tylko do odczytu zmniejsza ryzyko modyfikacji źródła podczas sprawdzania dostępności plików:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Następnie sprawdź system plików:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

Powyższe nazwy urządzeń są wyłącznie przykładami. Nigdy nie wklejaj ich bez zmian, dopóki nie potwierdzisz, że odpowiadają Twojemu sprzętowi.

Utwórz pełną kopię offload przed wykonaniem jakiegokolwiek destrukcyjnego kroku

Źródłowy przebieg wykorzystywał zewnętrzny dysk ext4 o pojemności wystarczającej do przechowania wszystkich używanych danych RAID. W przypadku danych aplikacji systemu Linux ext4 jest przydatny, ponieważ pozwala zachować standardowego właściciela, uprawnienia, dowiązania, listy ACL i atrybuty rozszerzone.

Typowe kopiowanie w stylu archiwum:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Uruchom kopiowanie w tmux lub w innym trwałym terminalu, jeśli rozłączenie SSH w przeciwnym razie przerwałoby działanie.

Zweryfikuj kopię zapasową przed kontynuowaniem

Nie polegaj wyłącznie na komunikacie końcowym rsync. Porównaj liczbę plików i sprawdź rozmiary głównych katalogów:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

W przypadku danych niemożliwych do zastąpienia lepsza jest druga, niezależna kopia zapasowa. RAID sam w sobie nie jest kopią zapasową.

Ostatnia deska ratunku: przenieś dane, usuń stare metadane RAID i odtwórz macierz w interfejsie

Pierwotny autor społecznościowej procedury chciał, aby odzyskana macierz wróciła do normalnego zarządzania w interfejsie ZimaOS. Jego metoda ostatniej szansy wyglądała następująco:

1. zweryfikuj starą macierz w trybie tylko do odczytu;
2. skopiuj wszystkie dane na dysk zewnętrzny;
3. zweryfikuj kopię;
4. zatrzymaj starą macierz md;
5. usuń stare metadane RAID;
6. utwórz nową macierz RAID 1 za pomocą interfejsu pamięci masowej ZimaOS;
7. przywróć skopiowane pliki;
8. zweryfikuj przywrócone dane.

Ta procedura celowo niszczy stare metadane RAID. Po wykonaniu tego kroku kopia offload staje się źródłem odzyskiwania. Nie stosuj tego podejścia, jeśli kopia jest niekompletna lub nie masz pewności co do tożsamości urządzeń.

Nieodwracalne polecenie w źródłowym przebiegu

Zastosowana przez społeczność procedura:

mdadm --zero-superblock /dev/sda /dev/sdb

To nie jest polecenie diagnostyczne. Usuwa metadane RAID ze wskazanych dysków. Błędna ścieżka urządzenia może spowodować poważną utratę danych.

Z tego powodu ta strona nie zaleca uruchamiania tej procedury wyłącznie dlatego, że interfejs ZimaOS nie rozpoznaje macierzy. Przywracanie local-storage.dbsprawdź bieżące działanie mechanizmu odzyskiwania ZimaOS i najpierw skontaktuj się z pomocą techniczną, jeśli macierz zawiera ważne dane.

Dlaczego odtwarzać macierz za pomocą interfejsu ZimaOS?

Celem źródłowej procedury było zakończenie pracy z pulą pamięci masowej zarządzaną normalnie przez ZimaOS, zamiast z trwale ręcznie złożonym urządzeniem md znajdującym się poza interfejsem pamięci masowej.

Po bezpiecznym skopiowaniu starych danych poza macierz i celowym zresetowaniu dysków użyj aktualnego interfejsu Pamięć masowa, aby utworzyć RAID 1 i poczekaj na zakończenie początkowej synchronizacji.

Przywróć pliki do nowej puli

Po utworzeniu i zamontowaniu nowej puli przywróć dane z dysku z kopią:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Zastąp /media/Storage z rzeczywistą ścieżką docelową wyświetlaną przez system.

Zweryfikuj przywróconą pulę

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Nie ruszaj dysku z kopią danych poza macierzą, dopóki synchronizacja RAID nie zostanie zakończona i nie zweryfikujesz prawidłowego dostępu za pośrednictwem interfejsu Pliki w ZimaOS oraz aplikacji korzystających z tych danych.

Utwórz kopię zapasową pliku local-storage.db przed kolejną reinstalacją

Najłatwiejsze odzyskiwanie to takie, do którego przygotowano się wcześniej. Zachowaj aktualną kopię:

/ZimaOS-HD/.casaos/db/local-storage.db

poza dyskiem systemowym. Oficjalna dokumentacja zawiera teraz bezpośrednią procedurę przywracania z użyciem tego pliku.

Którą ścieżkę odzyskiwania należy wybrać?

Najczęściej zadawane pytania dotyczące odzyskiwania RAID w ZimaOS

Czy ponowna instalacja ZimaOS automatycznie usuwa dane RAID?

Nie. Ponowna instalacja dysku systemowego różni się od formatowania dysków będących członkami macierzy RAID. Konfiguracja pamięci masowej może zostać utracona, podczas gdy metadane RAID i dane pozostaną na dyskach członkowskich.

Czy kliknąć „Utwórz RAID”, jeśli stare dyski są oznaczone jako nieużywane?

Nie, dopóki nie potwierdzisz, że nie ma żadnych istniejących danych wymagających odzyskania. Utworzenie nowej macierzy RAID może być destrukcyjne.

Jaki jest najbezpieczniejszy sposób odzyskania danych po utworzeniu kopii zapasowej pliku local-storage.db?

Użyj aktualnej oficjalnej procedury ZimaOS, aby przywrócić tę bazę danych, a następnie uruchom ponownie system.

Czy wyzerowanie superbloku mdadm jest bezpieczne?

Działanie to celowo niszczy metadane RAID. Używaj go wyłącznie jako elementu zweryfikowanego planu odzyskiwania, po bezpiecznym skopiowaniu danych w inne miejsce.