Lista kontrolna odzyskiwania serwera domowego: hasło, sieć, rozruch i pamięć masowa

Odzyskiwanie serwera domowego nie powinno zaczynać się od losowych poleceń. Jeśli zapomniałeś hasła, straciłeś adres IP, uszkodziłeś ścieżkę rozruchu lub nie widzisz pamięci masowej, najbezpieczniejszym krokiem jest najpierw zidentyfikować, która warstwa zawiodła: dostęp, sieć, rozruch czy pamięć masowa.

Kolejność ma znaczenie. Najpierw odzyskaj lokalny dostęp do konsoli, zanim zmienisz dane uwierzytelniające. Przywróć sieć, zanim polegasz na SSH. Napraw rozruch dopiero po potwierdzeniu dysku systemowego. Dotykaj pamięci masowej na końcu, ponieważ niewłaściwa komenda naprawcza na zdegradowanej puli, macierzy RAID lub zamontowanym systemie plików może zamienić problem możliwy do odzyskania w utratę danych.

Zatrzymaj się, zanim pogorszysz problem

Pierwszy krok odzyskiwania to nie naprawa. To kontrola szkód. Nie wymuszaj kolejnych restartów, nie zamieniaj dysków, nie przebudowuj macierzy, nie formatuj „nieznanych” dysków ani nie reinstaluj systemu, zanim nie poznasz przyczyny awarii.

Zapisz, co widzisz. Zrób zdjęcia ekranów błędów, kolejności rozruchu BIOS, pozycji zatok dysków, układu kabli, dzierżaw adresów IP routera i ostrzeżeń pamięci masowej. Próba odzyskania często kończy się niepowodzeniem, gdy użytkownik zmienia zbyt wiele rzeczy przed zapisaniem oryginalnego stanu.

Jeśli dane są ważne, pierwszym celem jest zachowanie tego, co nadal jest czytelne. Normalnie wyglądający serwer jest mniej ważny niż utrzymanie odwracalnej ścieżki odzyskiwania.

Znajdź uszkodzoną warstwę, zanim naprawisz niewłaściwą

Wiele problemów z serwerem domowym wygląda z zewnątrz tak samo: interfejs webowy się nie otwiera. To nie oznacza, że zawiodła ta sama część. Uszkodzony kabel, zmieniony adres IP, zatrzymana usługa webowa, zablokowane konto, uszkodzony bootloader, odmontowany pul pamięci lub uszkodzony wolumen Dockera mogą wyglądać jak „serwer nie działa”.

Zacznij od niskiego ryzyka kontroli. Czy urządzenie jest włączone? Czy router je widzi? Czy karta sieciowa pokazuje światła połączenia? Czy możesz podłączyć monitor i klawiaturę? Czy BIOS lub UEFI widzi dysk rozruchowy? Czy system dochodzi do ekranu logowania? Czy dyski danych są widoczne?

Dopiero potem wybierz ścieżkę odzyskiwania. Odzyskiwanie hasła to nie naprawa sieci. Naprawa sieci to nie naprawa rozruchu. Naprawa rozruchu to nie naprawa pamięci masowej. Zbyt wczesne mieszanie tych etapów stwarza niepotrzebne ryzyko.

Odzyskiwanie hasła wymaga najpierw lokalnego dostępu

Jeśli zapomniałeś hasła administratora, nie zaczynaj od reinstalacji systemu operacyjnego. Najpierw sprawdź, czy nadal masz aktywną sesję webową, drugiego użytkownika administratora, klucz SSH, wpis w menedżerze haseł lub fizyczny dostęp do konsoli.

Reset hasła powinien być wykonany tylko na urządzeniu, które posiadasz lub administrujesz. W systemach Linux postępuj zgodnie z udokumentowanym procesem ratunkowym systemu operacyjnego, zamiast kopiować losowe polecenia rozruchowe z forów. Dokumentacja resetowania hasła root w Fedora jest przykładem odniesienia do odzyskiwania specyficznego dla systemu, ale dokładny proces zależy od twojej dystrybucji i konfiguracji rozruchu.

Po przywróceniu dostępu, usuń przyczynę konieczności odzyskiwania. Zaktualizuj menedżera haseł, utwórz konto administratora zapasowego, jeśli potrzeba zmień ujawnione klucze SSH, potwierdź ustawienia dwuskładnikowe i udokumentuj, jak odzyskać lokalny dostęp następnym razem.

Odzyskiwanie sieci jest ważniejsze niż naprawa zdalna

Serwer, do którego nie można się dostać przez sieć, może być nadal w pełni sprawny. Przed zmianą pamięci masowej, bootloaderów lub aplikacji, przywróć lokalną komunikację.

Przydatne kontrole to lista klientów routera, diody łącza, lokalne skanowanie IP, bezpośredni monitor oraz podstawowe polecenia takie jak ip a, ping, oraz ssh. Skup się na celu: najpierw uzyskaj niezawodny dostęp do LAN, potem napraw zdalny dostęp, VPN, tunel, DNS lub reverse proxy.

Naprawa rozruchu dotyczy ścieżki rozruchu, a nie puli danych

Awaria rozruchu nie oznacza automatycznie, że dyski danych są uszkodzone. Prawdziwym problemem może być dysk systemowy, bootloader, kolejność BIOS, wpis UEFI, urządzenie USB, partycja odzyskiwania lub aktualizacja jądra.

Sprawdź kolejność rozruchu przed dotykaniem pamięci masowej. Potwierdź, który dysk zawiera system operacyjny, a które dyski zawierają dane. Jeśli system obsługuje partycję odzyskiwania, zapasowy slot rozruchowy lub opcję ratunkową, użyj ich przed ponowną instalacją. W systemach obsługujących podwójne sloty rozruchowe, ścieżka odzyskiwania może pozwolić serwerowi na uruchomienie z znanej, działającej partycji systemowej, pozostawiając dane użytkownika oddzielnie.

Dla użytkowników ZimaOS, przewodnik po odzyskiwaniu systemu ZimaOS wyjaśnia szybkie metody przywracania systemu za pomocą kopii zapasowych partycji rozruchowych. Taki sposób odzyskiwania jest przydatny, ponieważ skupia się na ponownym uruchomieniu systemu operacyjnego bez traktowania dysków danych jako pierwszego celu naprawy.

Jeśli używasz ogólnego serwera Linux, naprawa rozruchu może wymagać uruchomienia z live USB, zamontowania właściwej partycji root, wejścia do środowiska odzyskiwania i naprawy bootloadera. Rób to dopiero po zidentyfikowaniu dysku rozruchowego. Przypadkowa instalacja bootloadera lub systemu operacyjnego na dysku danych to jeden z najprostszych sposobów na pogorszenie odzyskiwania.

Odzyskiwanie pamięci masowej jest ostatnie, ponieważ niesie największe ryzyko

Pamięć masowa to miejsce, gdzie błędy odzyskiwania są kosztowne. Nie inicjuj, nie formatuj, nie wymuszaj składania, nie odbudowuj ani nie naprawiaj, dopóki nie wiesz, z jaką warstwą pamięci masowej masz do czynienia.

Zacznij od pytań dotyczących tylko do odczytu. Czy wszystkie dyski są wykryte? Który dysk jest brakujący? Czy pula jest zaimportowana? Czy system plików jest zamontowany? Czy pojawiły się ostrzeżenia SMART? Czy macierz jest zdegradowana? Czy udostępnione foldery zniknęły, ponieważ pula uległa awarii, czy dlatego, że system operacyjny uruchomił się bez ich montowania?

Jeśli możesz odczytać krytyczne pliki, skopiuj je przed podjęciem ryzykownej naprawy. Pierwszym celem odzyskiwania pamięci masowej nie jest przywrócenie normalnego wyglądu serwera, lecz zachowanie czytelnych danych zanim sytuacja się zmieni.

ZFS, RAID i pojedyncze dyski wymagają różnych podejść

Pojedynczy dysk ext4 lub XFS, pula ZFS, macierz RAID mdadm, zewnętrzny dysk USB do kopii zapasowej i wolumin aplikacji Docker nie powinny być naprawiane w ten sam sposób.

Dokumentacja Oracle dotycząca rozwiązywania problemów z ZFS i odzyskiwania puli jest przydatna, ponieważ rozdziela problemy ZFS na brakujące urządzenia, uszkodzone urządzenia i uszkodzone dane. To rozróżnienie ma znaczenie. Brakujące urządzenie, uszkodzony dysk i uszkodzone dane wymagają różnych działań.

ZFS również nie używa tradycyjnego modelu fsck. W systemach ZFS kontrole stanu, skanowanie, importy, resilvering i kopie zapasowe są częścią procesu odzyskiwania. Dla systemów plików innych niż ZFS używaj odpowiedniego narzędzia naprawczego specyficznego dla systemu plików dopiero po potwierdzeniu stanu wolumenu i montowania.

Odzyskiwanie aplikacji powinno zaczekać, aż system bazowy będzie stabilny

Nie zaczynaj od Dockera, aplikacji multimedialnych, narzędzi synchronizacji ani pulpitów nawigacyjnych. Aplikacje działają na bazowym systemie. Jeśli system operacyjny, sieć, montowanie pamięci lub uprawnienia są uszkodzone, aplikacja ponownie zawiedzie po jej restarcie.

Najpierw potwierdź podstawowy stos: serwer się uruchamia, lokalna sieć działa, pamięć jest zamontowana, uprawnienia są poprawne, a krytyczne dane są zarchiwizowane. Następnie sprawdź usługi aplikacji, kontenery, porty, reguły reverse proxy, pliki bazy danych i wolumeny aplikacji.

Wiele awarii aplikacji po odzyskaniu to problemy ze ścieżkami. Pula pamięci jest zamontowana w innym miejscu. Wolumen Dockera wskazuje na stary folder. Plik bazy danych istnieje, ale należy do niewłaściwego użytkownika. Aplikacja multimedialna się uruchamia, ale nie widzi biblioteki. Napraw ścieżkę pamięci przed ponowną instalacją aplikacji.

Zbuduj zestaw do odzyskiwania przed następną awarią

Najlepsze odzyskiwanie jest przygotowane zanim serwer ulegnie awarii. Serwer domowy jest łatwiejszy do naprawy, gdy ważne szczegóły są przechowywane poza samym serwerem.

Przechowuj ten zestaw w miejscu, do którego uszkodzony serwer nie musi mieć dostępu. Notatka odzyskiwania przechowywana tylko na uszkodzonym NAS-ie nie jest notatką odzyskiwania.

Wiedzieć, kiedy przerwać samodzielną naprawę

Niektóre awarie to już nie zadania diagnostyczne. To sytuacje odzyskiwania danych. Jeśli jedyna kopia ważnych danych znajduje się na serwerze, każde polecenie należy traktować jako ryzyko.

Przerwij samodzielną naprawę, gdy brakuje wielu dysków, dysk wydaje klikające dźwięki, RAID lub pula jest zdegradowana i niejasna, mogło dojść do wymiany niewłaściwego dysku, import puli wymaga destrukcyjnych opcji lub dane są krytyczne dla firmy i nie ma kopii zapasowej.

W tym momencie, jeśli to odpowiednie, wyłącz zasilanie, oznacz dyski, udokumentuj obecny stan, unikaj powtarzanych odbudów i szukaj pomocy, zanim szansa na odzyskanie spadnie. Odzyskiwanie domowego serwera nie polega na udowodnieniu, że potrafisz naprawić wszystko sam. Chodzi o wiedzę, kiedy kolejna komenda może zmniejszyć szansę na odzyskanie.

Ostateczna lista kontrolna odzyskiwania

Odzyskiwanie działa najlepiej, gdy jest nudne. Przechodź od dostępu do sieci, od sieci do rozruchu, od rozruchu do magazynu, a od magazynu do aplikacji. Pomijaj tę kolejność tylko wtedy, gdy dokładnie wiesz, która warstwa zawiodła.

FAQ

Co powinienem zrobić najpierw, jeśli nie mogę uzyskać dostępu do mojego domowego serwera?

Zacznij od sprawdzenia fizycznego i sieciowego: zasilanie, kabel, dzierżawa routera, wyświetlacz, dostęp do klawiatury i konsola lokalna. Nie rozpoczynaj naprawy magazynu, dopóki nie ustalisz, czy problem dotyczy dostępu, sieci, rozruchu czy magazynu.

Jak odzyskać zapomniane hasło do domowego serwera?

Użyj istniejącej sesji administratora, zapasowego konta admina, klucza SSH, konsoli lokalnej lub trybu ratunkowego specyficznego dla systemu operacyjnego. Resetuj hasło tylko na urządzeniu, które posiadasz lub którym zarządzasz, i zaktualizuj menedżera haseł.

Dlaczego mogę pingować mój domowy serwer, ale nie mogę otworzyć interfejsu webowego?

Sieć może działać, podczas gdy usługa webowa, kontener, reverse proxy, zapora lub port aplikacji są uszkodzone. Sprawdź status usługi po potwierdzeniu dostępności puli magazynu i ścieżek aplikacji.

Czy powinienem uruchomić fsck po nieprawidłowym zamknięciu systemu?

Nie automatycznie. Najpierw zidentyfikuj system plików i potwierdź, że wolumin jest bezpieczny do naprawy. ZFS nie działa na zasadzie fsck jak tradycyjne systemy plików, więc używaj narzędzi do statusu i odzyskiwania specyficznych dla puli.

Co powinienem zrobić, jeśli moja pula ZFS jest zdegradowana?

Najpierw sprawdź status puli, zidentyfikuj brakujące lub uszkodzone urządzenie i unikaj tworzenia nowej puli lub nadpisywania etykiet. Jeśli dane są ważne i nie masz kopii zapasowej, zachowaj czytelne pliki przed podjęciem ryzykownych napraw.

Czy reinstalacja systemu operacyjnego usuwa dane z NAS?

To zależy od układu dysków i wyborów instalatora. Wiele domowych serwerów oddziela dyski systemowe od dysków z danymi, ale wybranie niewłaściwego dysku podczas reinstalacji może zniszczyć dane. Przed reinstalacją potwierdź dysk rozruchowy i dyski z danymi.