Uruchamianie Hetzner Rescue System - przewodnik krok po kroku dla administratorów serwerów

Pokażę ci, jak uruchomić system ratunkowy hetznera w zaledwie kilka minut. SSH zaloguj się i wprowadź swój Serwer naprawa w ukierunkowany sposób. Ten przewodnik prowadzi krok po kroku od aktywacji do odzyskiwania, w tym sprawdzania systemu plików, tworzenia kopii zapasowych i ponownej instalacji.

Punkty centralne

Poniższe kluczowe aspekty pomogą ci rozpocząć i pracować w trybie ratunkowym bez żadnych objazdów.

• Rozpoczęcie akcji ratunkowejAktywacja w aplikacji Robot lub Cloud, a następnie ponowne uruchomienie.
• Dostęp SSHZaloguj się przy użyciu klucza lub hasła i praw roota.
• Analiza błędówSprawdź fsck, logi, partycje.
• Kopia zapasowa danych: rsync, tar, scp do szybkiego tworzenia kopii zapasowych.
• Nowa instalacjainstallimage dla świeżych systemów.

Co robi system ratunkowy

System ratunkowy ładuje niezależne środowisko Linux do pamięci roboczej i zapewnia mi natychmiastowy dostęp do Korzenie-dostęp, nawet jeśli zainstalowany System operacyjny zawodzi. Uruchamiam niezależnie od wadliwych programów ładujących, uszkodzonych pakietów lub błędnych konfiguracji. Pozwala mi to sprawdzać systemy plików, odzyskiwać dane, analizować dzienniki i ponownie uruchamiać usługi. Środowisko pozostaje szczupłe, ale oferuje wszystkie ważne narzędzia do diagnostyki i odzyskiwania danych. Pozwala mi to zachować kontrolę, nawet jeśli zwykły system ulegnie całkowitej awarii.

Praktyczne jest to, że środowisko ratunkowe jest celowo niestabilne: zmiany znikają po ponownym uruchomieniu, co oznacza, że mogę bezpiecznie testować. W razie potrzeby instaluję tymczasowe narzędzia (np. smartmontools, mdadm, lvm2, btrfs-progs lub xfsprogs) bez zmiany systemu produkcyjnego. Wersja jądra jest nowoczesna i obsługuje najnowszy sprzęt, w tym NVMe, UEFI, GPT, programowy RAID (mdraid), LVM i szyfrowanie LUKS. Pozwala mi to objąć nawet złożone konfiguracje pamięci masowej i wyizolować nawet rzadkie wzorce błędów w powtarzalny sposób.

Wymagania i dostęp

Aby rozpocząć, potrzebuję dostępu do interfejsu klienta i moich Klucze SSH lub tymczasowy hasło. Zarządzam dedykowanymi systemami wygodnie przez Hetzner Robotpodczas gdy instancjami w chmurze steruję za pośrednictwem konsoli. Oba interfejsy oferują wyraźną opcję aktywacji trybu ratunkowego. Z wyprzedzeniem sprawdzam prawidłowe IP serwera, dostępność IPv6 i, jeśli to konieczne, funkcje pozapasmowe do resetu. Takie przygotowanie znacznie skraca czas przestoju.

Kiedy loguję się do SSH po raz pierwszy, świadomie potwierdzam nowy odcisk palca i w razie potrzeby aktualizuję wpis Known Hosts, aby kolejne połączenia nie kończyły się niepowodzeniem z powodu ostrzeżeń. W przypadku zespołów przechowuję dodatkowe klucze specjalnie na potrzeby operacji ratunkowej i usuwam je ponownie po jej zakończeniu. Jeśli dostępne jest tylko tymczasowe hasło, zmieniam je natychmiast po zalogowaniu, a następnie zastępuję je Key-Auth - konsekwentnie dezaktywuję logowanie hasłem po zakończeniu pracy.

Aktywacja systemu ratunkowego - krok po kroku

Otwieram okno szczegółów serwera, wybieram opcję "Rescue" i ustawiam architekturę na linux64 dla obecnych systemów, a następnie wpłacam moje Klucz SSH. W zależności od sytuacji, uruchamiam tylko tryb ratunkowy i uruchamiam restart osobno lub używam "Activate Rescue & Power Cycle" do bezpośredniego restartu. Jeśli urządzenie się zawiesi, wykonuję twardy reset za pośrednictwem interfejsu. Po uruchomieniu interfejs pokazuje tymczasowe hasło roota, jeśli nie wprowadziłem klucza. Gdy tylko serwer się uruchomi, odpowiada na SSH i mogę rozpocząć pracę.

W złożonych sytuacjach planuję jasną sekwencję: aktywacja, cykl zasilania, test logowania SSH, a następnie rozpoczęcie rozwiązywania problemów. Ręczny cykl zasilania może być bardziej potrzebny na serwerach dedykowanych, podczas gdy instancje w chmurze zwykle natychmiast przełączają się w tryb ratunkowy. Ważne: Po udanej naprawie ponownie wyłączam tryb ratunkowy, aby maszyna uruchomiła się ponownie z lokalnego dysku twardego.

Połączenie SSH i pierwsze kontrole

Łączę się przez SSH z ssh root@ i najpierw sprawdzić sieć, nośniki danych i dzienniki, aby uzyskać szybki przegląd Status. Z ip a oraz ping Sprawdzam dostępność; journalctl --no-pager -xb lub pliki dziennika na zamontowanych dyskach pokazują najnowsze komunikaty o błędach. Polecenia lsblk, blkid oraz fdisk -l zapewniają przejrzystość układu i systemów plików. Dla RAID używam cat /proc/mdstat oraz mdadm --detail dla danego stanu. Początkowe wskaźniki sprzętowe smartctl -a i krótki hdparm -Tt-test.

LVM, RAID, LUKS i specjalne systemy plików

Wiele serwerów korzysta z LVM, programowej macierzy RAID lub szyfrowania. Najpierw aktywuję wszystkie odpowiednie warstwy:

• mdraid: mdadm --assemble --scan wyświetla istniejące tablice; sprawdzam status za pomocą cat /proc/mdstat.
• LUKSOtwieram zaszyfrowane woluminy za pomocą cryptsetup luksOpen /dev/.
• LVMZ vgscan oraz vgchange -ay Aktywuję grupy głośności i widzę je poprzez lvs/vgs/pvs.

W przypadku Btrfs zwracam uwagę na subwoluminy i montuję je specjalnie za pomocą -o subvol=@ odpowiednio -o subvolid=5 dla najwyższego poziomu. Sprawdzam XFS za pomocą xfs_repair (nigdy na zamontowanych woluminach), podczas gdy Ext4 jest klasycznie używany z fsck.ext4 -f jest zreorganizowany. Orientuję się na GUID/UUID od blkidponieważ nazwy urządzeń NVMe (/dev/nvme0n1p1) i może się różnić w zależności od zamówienia. Poprawię /etc/fstab.

Naprawa systemu plików i tworzenie kopii zapasowych danych

Przed naprawą wykonuję kopię zapasową ważnych danych Dane z rsync, scp lub smoła do celu zewnętrznego lub lokalnego Kopia zapasowa-directory. Do kontroli używam fsck tylko na niezamontowanych partycjach, na przykład fsck -f /dev/sda2aby skorygować niespójności. Następnie montuję system pod /mntna przykład z mount /dev/sda2 /mnti dołącz podścieżki, takie jak /proc, /sys oraz /dev kiedy chcę chrootować. Poszczególne pliki konfiguracyjne, takie jak /etc/fstab lub ustawień sieciowych bezpośrednio w zamontowanym systemie. Postępując ostrożnie, zapobiegam szkodom następczym i minimalizuję przestoje.

W przypadku niezawodnych kopii zapasowych polegam na powtarzalnych poleceniach: rsync -aHAX --info=progress2 otrzymuje prawa, hardlinki, ACL i xattrs. Jeśli linia jest słaba, dławię za pomocą --bwlimit i zrównoleglić kompresję z tar -I pigz. Jeśli to konieczne, obrazuję krytyczne, wadliwe nośniki danych w blokach z ddrescue aby przenieść pracę logiczną na obraz. Dokładnie sprawdzam systemy Btrfs za pomocą btrfs check --readonly i używać btrfs scrubdo wykrywania cichych błędów. XFS często wymaga naprawy off-mount w przypadku niespójności (xfs_repair) - zawsze najpierw tworzę kopię zapasową partycji.

UEFI/BIOS, GPT/MBR i naprawa bootloadera

Wiele problemów z uruchamianiem jest spowodowanych interakcją oprogramowania układowego, schematu partycji i programu ładującego. Najpierw należy wyjaśnić, czy serwer uruchamia się w trybie UEFI czy starszego BIOS-u (ls /sys/firmware/efi). W UEFI montuję partycję EFI (typowo /dev/sdX1 lub /dev/nvme0n1p1) do /mnt/boot/efi. Następnie przeszedłem do systemu:

mount /dev/ /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Odpowiednio przeinstalowałem bootloader (grub-install do właściwego urządzenia) i zregenerować konfigurację oraz initramfs: update-grub oraz update-initramfs -u -k all (dla systemów opartych na dracut dracut -f). Jeśli kolejność urządzeń nie jest prawidłowa, używam funkcji /etc/default/grub Identyfikatory UUID i sprawdzanie /etc/fstab dla poprawnych wpisów. Podczas zmiany GPT/MBR sprawdzam, czy istnieje partycja rozruchowa BIOS (dla GRUB/BIOS) lub prawidłowa partycja systemowa EFI.

Pułapki sieciowe w ratownictwie

Problemy z siecią są często powodem, dla którego usługi "znikają". W programie Rescue sprawdzam status łącza (łącze ip), trasy (ip r) i rozdzielczość DNS (resolvectl status Odpowiednio cat /etc/resolv.conf). Testuję IPv4 i IPv6 oddzielnie (ping -4/ping -6). W przypadku serwerów z mostkami lub łączeniem kolejność interfejsów w systemie produkcyjnym może różnić się od środowiska ratunkowego. Notuję adresy MAC i mapuję je poprawnie. Jeśli system produkcyjny korzysta z Netplan, weryfikuję /etc/netplan/*.yaml i włączyć po chroot netplan generate oraz netplan apply na. Dla klasyków /etc/network/interfaces-Zwracam uwagę na spójne nazwy interfejsów (nazwy przewidywalne vs. eth0).

Ponowna instalacja systemu operacyjnego

Jeśli naprawa nie ma już sensu, resetuję system za pomocą installimage całkowicie nowe, a tym samym zaoszczędzić cenne Czas. Narzędzie prowadzi mnie przez wybór dystrybucji, partycjonowanie i program ładujący. Do instalacji dołączam własne pliki konfiguracyjne i klucze SSH, dzięki czemu pierwsze uruchomienie przebiega płynnie. Po instalacji uruchamiam serwer w normalny sposób i sprawdzam usługi, zaporę sieciową i aktualizacje. Na koniec usuwam tryb ratunkowy, aby następny rozruch odbył się ponownie z lokalnego nośnika danych.

Celowo używam mocowań opartych na UUID dla nowych instalacji, aby wykluczyć późniejsze problemy z kolejnością urządzeń. W przypadku konfiguracji RAID, macierze tworzę od początku i sprawdzam stan odbudowy przed przywróceniem danych. Jeśli wdrażasz podobne systemy regularnie, pracujesz z predefiniowanymi szablonami obrazów instalacyjnych i jasną logiką partycjonowania (root, oddzielna partycja danych, swap, EFI w razie potrzeby). Po pierwszym uruchomieniu aktualizuję źródła pakietów i jądra, aktywuję automatyczne aktualizacje zabezpieczeń i wdrażam podstawowe kroki utwardzania.

Bezpieczeństwo, okno czasowe i nawrót

Dostęp jest możliwy wyłącznie przez SSHdlatego konsekwentnie polegam na Klucze zamiast haseł statycznych. Tryb ratunkowy pozostaje gotowy przez ograniczony czas po aktywacji i powraca do lokalnego urządzenia rozruchowego przy następnym normalnym restarcie. Pracuję szybko, dokumentuję każdy krok i utrzymuję drugą sesję otwartą dla większych interwencji. Nie zapisuję wrażliwych danych w historii bash i usuwam pliki tymczasowe po użyciu. Po pomyślnym odzyskaniu danych ponownie dezaktywuję tryb w interfejsie.

Po ponownej aktywacji systemu produkcyjnego rotuję dane dostępowe, usuwam tymczasowe klucze ratunkowe, resetuję zbędne hasła root i tworzę kopie zapasowe świeżo wygenerowanych konfiguracji. Zbieram informacje audytowe (kto co zrobił i kiedy) i dokumentuję odchylenia od standardowej konfiguracji. Zapobiega to utrwalaniu się środków awaryjnych i zapewnia zgodność z wymogami.

Przykład: Ratowanie serwera WordPress

Przechodzę do trybu ratunkowego, montuję partycję systemową i tworzę kopię zapasową. Baza danych za mysqldump i wp-content-katalog z smoła lub rsync. Następnie sprawdzam system plików, resetuję program ładujący i poprawiam nieprawidłowe konfiguracje PHP lub NGINX. Jeśli pakiety są uszkodzone, używam chroot i ponownie instaluję zależności. Jeśli to nie wystarczy, resetuję maszynę za pomocą installimage i przywracam kopię zapasową i konfiguracje. Na koniec weryfikuję frontend, logowanie i cronjobs.

W praktyce zwracam uwagę na spójność InnoDB (MySQL/MariaDB): Fails mysqld na początku, zabezpieczam /var/lib/mysql i uruchamiam zrzut ze świeżej instancji. Opróżniam cache (object cache, page cache, OPCache) selektywnie, ustawiam uprawnienia do plików konsekwentnie (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) i sprawdzić open_basedir i katalogi przesyłania. W ramach testu dezaktywuję krytyczne wtyczki, zmieniając nazwę katalogu wtyczek. Następnie sprawdzam pule PHP FPM, limity czasu FastCGI, limity pamięci i elementy NGINX/Apache. Krótko wp cron event run --due-now (jeśli WP-CLI jest dostępne) pomaga w przetwarzaniu zaległości.

Najlepsze praktyki dla administratorów

Przed głębokimi interwencjami tworzę nowy Kopia zapasowa i zabezpieczyć kluczowe pliki, takie jak /etcdzięki czemu w każdej chwili mogę do nich wrócić. Każdy krok trafia do krótkiego dziennika, który pomaga mi później w audytach lub nowych incydentach. Po ponownym uruchomieniu systemu produkcyjnego dokładnie sprawdzam usługi, dzienniki, sieć i monitoring. W przypadku powtarzających się zadań tworzę mały zestaw skryptów, aby ustandaryzować sekwencje poleceń. Jeśli planujesz dodatkową wydajność lub nowy sprzęt, możesz stworzyć odpowiednie skrypty. Wynajem serwera głównego i okno migracji.

Mam również gotową listę kontrolną, która zawiera obowiązki i ścieżki eskalacji. Zaplanowane "dni gry" (ukierunkowane symulacje awarii) szkolą zespół na wypadek sytuacji awaryjnych. Regularnie testuję kopie zapasowe jako próbkę przywracania - nieprzetestowana kopia zapasowa jest uważana za nieistniejącą. Wersjonuję też konfiguracje systemu, dzięki czemu mogę szybko rozpoznać różnice między stanem "dobrym" i "wadliwym".

Chmura a rozwiązanie dedykowane: różnice w procesie

W chmurze często zmieniam tryb rozruchu bezpośrednio w oknie dialogowym instancji i używam konsoli szeregowej do szybkich kontroli, podczas gdy na serwerach dedykowanych konieczny jest cykl zasilania i ewentualnie dostęp poza pasmem. Wolumeny w chmurze można wygodnie dołączać do innych instancji - jest to skuteczny sposób na tworzenie kopii zapasowych danych bez przestojów na danym hoście. Na serwerach bare metal zwracam większą uwagę na fizyczną kolejność dysków, zwłaszcza przy zakupie dodatkowych modułów SSD/NVMe. W obu światach: Rescue jest narzędziem tymczasowym - planuję drogę powrotną do normalnego rozruchu w odpowiednim czasie.

Porównanie: dostawcy z systemem ratunkowym

Oprócz dobrej jakości pracy, szybki powrót do zdrowia Sprzęt również czysto zintegrowany Ratunek-funkcja. Poniższa tabela zawiera kompaktowy przegląd zakresu funkcji i obsługi. Oparłem to na dostępności, łatwości dostępu i typowych przepływach pracy administratora. Ocena "Rekomendacja" odzwierciedla moje praktyczne zastosowanie w przypadku typowych usterek. Waga może się oczywiście różnić w zależności od zamierzonego zastosowania.

Dostawca	Dostępny system ratunkowy	Łatwość użytkowania	Wydajność	Zalecenie
webhoster.de	Tak	Bardzo dobry	Bardzo wysoki	Zwycięzca testu
Hetzner	Tak	Bardzo dobry	Wysoki
Strato	Częściowo	Dobry	Średni
IONOS	Nie	Średni	Średni

Lista kontrolna: Kolejność działań w sytuacji awaryjnej

• Aktywacja funkcji Rescue, uruchomienie restartu/cyklu zasilania, test SSH.
• Wyświetlanie sprzętu / pamięci masowej: smartctl, lsblk, blkid, mdstat, lvm.
• Aktywuj tablice/LUKS/LVM, sprawdzaj systemy plików tylko do odczytu.
• Utwórz kopię zapasową (rsync/tar), a następnie fsck/Naprawy.
• System pod /mnt mount, bind mounts, chroot.
• Napraw bootloader/initramfs, sprawdź konfigurację sieci.
• Test rozruchu, weryfikacja usług, sprawdzenie monitorowania/alarmów.
• Dezaktywacja Rescue, usunięcie kluczy tymczasowych, aktualizacja dokumentacji.

FAQ System ratunkowy Hetzner

Czy mogę używać mojego Dane ratunkowy, jeśli system przestanie się uruchamiać? Tak, odczytuję nośniki danych bezpośrednio w trybie ratunkowym i tworzę kopie zapasowe ważnych danych. Folder lub całych partycji.

Jak długo tryb ratunkowy pozostaje aktywny? Po aktywacji system jest dostępny przez ograniczony czas i przełącza się z powrotem na system lokalny przy następnym regularnym ponownym uruchomieniu. Łódź-urządzenie, dlatego planuję szybkie Procedura.

Czy działa to w przypadku chmury i serwerów dedykowanych? Tak, uruchamiam tryb zarówno dla maszyn dedykowanych, jak i instancji w chmurze w sekcji Hetzner Cloud.

Co zrobić, jeśli bootloader jest uszkodzony? Montuję roota i ewentualnie EFI, chrootuję do systemu, wykonuję grub-install, update-grub i odbudowuję initramf, a następnie testuję restart.

Jak radzić sobie z LVM/RAID? Najpierw montuję mdraid, aktywuję LVM za pomocą vgchange -ay a następnie zamontować woluminy logiczne. Naprawa odbywa się tylko po utworzeniu kopii zapasowej.

Czy mogę zapisywać tylko pojedyncze pliki? Tak, montuję tylko do odczytu i selektywnie kopiuję konfiguracje, bazy danych (poprzez dump) lub katalogi - minimalnie inwazyjnie i szybko.

Główne przesłanie

Z Hetzner System Rescue, mam szybkie narzędzie, które niezawodnie identyfikuje problemy z uruchamianiem, błędy systemu plików i uszkodzone konfiguracje. Aktywuję tryb, loguję się przez SSH, tworzę kopię zapasową danych, a następnie decyduję między naprawą a ponowną instalacją. To oszczędza Czas w sytuacjach awaryjnych i skraca czas przestoju do niezbędnego minimum. Jeśli zinternalizujesz te kilka kroków, możesz spokojnie poradzić sobie nawet z trudnymi awariami. Oznacza to, że działanie serwera można zaplanować, a ponowne uruchomienie jest kontrolowane.