Operacje na serwerze
Odzyskaj nieosiągalny serwer
Segreguj utratę dostępu, chroń dane możliwe do odzyskania i wybierz najmniej destrukcyjną ścieżkę odzyskiwania wspomaganą przez operatora.
Na tej stronie
Zanim zaczniesz
- Nazwa serwera, region, bieżący stan, adres podstawowy i czas ostatniego udanego dostępu.
- Niedawna niezależna kopia zapasowa i zrozumienie, jakie dane zmieniły się od czasu tej kopii.
- Lokalny klucz prywatny SSH i wszelkie materiały do odzyskiwania szyfrowania dysku; nigdy nie wysyłaj kluczy prywatnych do pomocy technicznej.
- Rekord konserwacji dla ostatnich zmian zapory sieciowej, sieci, rozruchu, pamięci masowej lub systemu operacyjnego.
Sklasyfikuj awarię przed działaniem
Najpierw odróżnij problem ze statusem konta od problemu z łącznością. Stan PROVISIONING lub SUSPENDED, adres oczekujący lub serwer po upływie opłaconego czasu wymaga innej reakcji niż osiągalny serwer, który odrzuca SSH. Zapisz dokładny komunikat, zamiast podsumowywać go jako awarię.
Jeśli to praktyczne, sprawdź z drugiej zaufanej sieci, ale nie uruchamiaj agresywnych skanów. Jeśli adres jest osiągalny, ale uwierzytelnianie się nie powiedzie, potwierdź nazwę logowania i pasujący klucz prywatny. Jeśli klucz hosta zmienił się bez zatwierdzonej ponownej instalacji, zatrzymaj się i potraktuj to jako problem tożsamości.
| Objaw | Możliwa granica | Najmniej destrukcyjny następny krok |
|---|---|---|
| Serwer nadal w trakcie aprowizacji | Dostawa nie została ukończona | Zapytaj operatora o status udostępniania. |
| Limit czasu SSH | Zasilanie, routing, zapora sieciowa lub usługa SSH | Poproś o dostęp KVM przed ponowną instalacją. |
| Brak uprawnień | Niezgodność loginu lub klucza | Zweryfikuj nazwę konta i parę kluczy publiczny/prywatny. |
| Zmieniono klucz hosta | Ponowna instalacja, ponowne przypisanie lub przechwycenie | Zweryfikuj nowy odcisk palca poza pasmem. |
| Błąd systemu plików lub rozruchu | Awaria dysku, RAID lub systemu operacyjnego | Najpierw użyj odzyskiwania tylko do odczytu i zachowaj dowody. |
Wybierz najmniejsze działanie
Nie wybieraj opcji Wyłącz, dopóki operator nie uzgodni, w jaki sposób maszyna zostanie ponownie włączona. Obecny klient API nie udostępnia akcji włączania. Rotacja hasła root również jest tylko żądaniem w kolejce, a API nie zwraca wygenerowanego hasła, więc obecnie nie jest to ścieżka samodzielnego odzyskiwania.
- Przechwyć bieżący stan serwera i wszystkie widoczne identyfikatory przed umieszczeniem czegokolwiek w kolejce.
- Jeśli system operacyjny może być po prostu zawieszony, wyślij jedno żądanie Restart i zanotuj jego sufiks akcji.
- Jeśli konfiguracja sieci lub rozruchu jest podejrzana, umieść w kolejce KVM i poproś operatora o dostarczenie dostępu do konsoli.
- Jeśli wymagane są nośniki ratunkowe, przygotuj zaufane niestandardowe ISO i sumę kontrolną, a następnie skoordynuj jego montaż z operatorem.
- Użyj ponownej instalacji tylko wtedy, gdy odzyskiwanie danych jest zakończone lub zweryfikowano niezależną kopię zapasową.
Chroń dane podczas odzyskiwania
Preferuj inspekcję tylko do odczytu przed naprawą. Zidentyfikuj dyski, partycje, systemy plików i punkty montowania przed wyborem urządzenia. Nazwy mogą się różnić po uruchomieniu z nośnika alternatywnego, zwłaszcza w systemach pamięci masowej NVMe i wielodyskowych. Jeśli awaria może dotyczyć RAID lub uszkodzenia systemu plików, przechwyć diagnostykę i skonsultuj się z wykwalifikowanym operatorem przed składaniem macierzy lub uruchamianiem narzędzi naprawczych.
Nigdy nie inicjuj dysku, nie twórz nowego systemu plików, nie przebudowuj macierzy ani nie instaluj ponownie tylko po to, aby sprawdzić, czy to pomoże. Te operacje mogą nadpisać metadane potrzebne do odzyskania. Trzymaj odzyskane dane poza dotkniętym serwerem i zweryfikuj je przed destrukcyjnymi pracami.
lsblk --fs
ip -brief address
ip route show
ip -6 route showOczekiwany wynik i pakiet eskalacji
Pomyślne odzyskanie przywraca zweryfikowaną ścieżkę administracyjną bez niepotrzebnej utraty danych lub tworzy kontrolowany plan przywrócenia na czystym systemie. Ponieważ akcje w kolejce nie mają widocznego dla klienta stanu ukończenia, prowadź jedną oś czasu zawierającą każdy sufiks akcji i potwierdzenie operatora.
Podczas eskalacji podaj serwer i region, ostatni znany dobry czas w UTC, widoczny stan, sieć źródłową, dokładny błąd SSH lub konsoli, ostatnie zmiany, odwołania do działań oraz informację, czy przetestowano kopię zapasową poza serwerem. Nie podawaj haseł, kluczy prywatnych, kodów odzyskiwania ani aktywnych adresów URL konsoli. Jeśli operator nie może przywrócić bezpiecznego dostępu, uzgodnij granice przechwytywania danych i czyszczenia przed ponowną instalacją.