Hetzner serwer dedykowany rescue mode: odbudowa mdadm RAID po wymianie dysku
Odbudowa macierzy mdadm RAID na serwerze dedykowanym Hetzner po wymianie dysku: rescue mode, partycjonowanie i ponowne złożenie macierzy.
Jeśli zarządzasz serwerami dedykowanymi w EU, zobacz naszą stronę zarządzanie serwerami dedykowanymi. Dla kwestii rezydencji danych przy wyborze dostawcy hostingu w EU zobacz case study o przeniesieniu infrastruktury do EU.
Objawy
Twój serwer dedykowany Hetzner jest nieosiągalny lub wystartował w trybie zdegradowanym. Panel Hetzner Robot pokazuje, że wymiana dysku została wykonana:
# Powiadomienie Hetzner Robot:
# Temat: Hardware replacement completed for server EX44 (10.0.0.1)
# Treść: Drive /dev/sdb has been replaced. Server is in rescue mode.
Lub zauważasz zdegradowany RAID po restarcie:
# Z rescue mode lub zdegradowanego bootu
cat /proc/mdstat
# md0 : active raid1 sda1[0]
# 524224 blocks super 1.2 [2/1] [U_]
# md1 : active raid1 sda2[0]
# 1953382336 blocks super 1.2 [2/1] [U_]
Wzorzec [U_] oznacza, że jeden dysk brakuje w mirrorze.
Przyczyna
Zespół sprzętowy Hetzner fizycznie wymienił uszkodzony dysk, ale nowy dysk przychodzi pusty (brak tablicy partycji, brak superbloku mdadm). Macierz RAID (md0, md1 itd.) działa w trybie zdegradowanym na pozostałym sprawnym dysku. Serwer może:
- Wystartować automatycznie w rescue mode (jeśli support Hetzner uruchomił rescue)
- Wystartować normalnie w trybie zdegradowanym (jeśli sprawny dysk ma bootloader)
- Nie wystartować wcale (jeśli sprawny dysk nie jest skonfigurowany jako boot fallback)
Potrzebujesz: podzielić nowy dysk identycznie jak ocalały, dodać każdą partycję do odpowiedniej macierzy mdadm, poczekać na rebuild i upewnić się, że GRUB jest zainstalowany na obu dyskach.
Rozwiązanie
Krok 1: Uruchom rescue mode przez Hetzner Robot
Jeśli nie jesteś jeszcze w rescue mode:
- Zaloguj się do Hetzner Robot
- Wybierz serwer → zakładka Rescue
- Aktywuj system ratunkowy (Linux 64-bit)
- Zanotuj tymczasowe hasło root
- Wyzwól reset sprzętowy (zakładka Reset → “Send Ctrl+Alt+Del” lub “Execute automatic hardware reset”)
- Połącz się SSH do systemu ratunkowego:
ssh root@ip-serwera
Krok 2: Zidentyfikuj dyski i układ macierzy
# Wylistuj wszystkie dyski
lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL
# Sprawdź, który dysk jest nowy (brak partycji)
fdisk -l /dev/sda
fdisk -l /dev/sdb
# Sprawdź istniejące macierze mdadm (działające na sprawnym dysku)
cat /proc/mdstat
# Pobierz układ partycji ze sprawnego dysku
sgdisk -p /dev/sda
# Uwaga: zakładamy, że sda to ocalały dysk. Dostosuj jeśli przetrwał sdb.
Krok 3: Sklonuj tablicę partycji na nowy dysk
# Skopiuj tablicę partycji ze sprawnego dysku (sda) na nowy (sdb)
sgdisk -R /dev/sdb /dev/sda
# Wylosuj nowe GUID na nowym dysku (wymagane dla GPT)
sgdisk -G /dev/sdb
# Zweryfikuj, że układ partycji się zgadza
sgdisk -p /dev/sdb
Krok 4: Dodaj partycje do macierzy mdadm
# Dodaj każdą partycję do odpowiedniej macierzy
# Dostosuj numery urządzeń md i partycji do swojej konfiguracji
mdadm --add /dev/md0 /dev/sdb1
mdadm --add /dev/md1 /dev/sdb2
# Jeśli masz partycję swap na md:
# mdadm --add /dev/md2 /dev/sdb3
# Sprawdź, czy rebuild wystartował
cat /proc/mdstat
# Oczekiwane: [2/1] [U_] z procentem recovery
Krok 5: Poczekaj na zakończenie rebuildu
# Monitoruj postęp rebuildu
watch -n 10 cat /proc/mdstat
# Dla dysku 2 TB spodziewaj się ~2-4 godziny na SATA, ~30-60 min na NVMe
# Możesz przyspieszyć:
echo 200000 > /proc/sys/dev/raid/speed_limit_min
echo 500000 > /proc/sys/dev/raid/speed_limit_max
Krok 6: Zainstaluj GRUB na obu dyskach
# Zamontuj główny system plików
mount /dev/md1 /mnt
# Bind mount wymaganych systemów plików
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
# Jeśli osobna partycja /boot (md0):
mount /dev/md0 /mnt/boot
# Chroot i instalacja GRUB na obu dyskach
chroot /mnt
grub-install /dev/sda
grub-install /dev/sdb
update-grub
exit
# Odmontuj
umount /mnt/boot 2>/dev/null
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt
Krok 7: Wyłącz rescue mode i zrestartuj
- W Hetzner Robot → zakładka Rescue → Deactivate rescue system
- Restart:
reboot - Poczekaj 2-3 minuty, potem połącz się SSH do serwera normalnie
Weryfikacja
# 1. Zweryfikuj, że RAID jest w pełni zsynchronizowany
cat /proc/mdstat
# Oczekiwane: [2/2] [UU] dla wszystkich macierzy (brak rebuildu w toku)
# 2. Zweryfikuj, że oba dyski są obecne w każdej macierzy
mdadm --detail /dev/md0 | grep -E "State|Devices|/dev/"
# Oczekiwane: State: clean, Active Devices: 2
mdadm --detail /dev/md1 | grep -E "State|Devices|/dev/"
# Oczekiwane: State: clean, Active Devices: 2
# 3. Zweryfikuj, że GRUB jest zainstalowany na obu dyskach
dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -i grub
dd if=/dev/sdb bs=512 count=1 2>/dev/null | strings | grep -i grub
# Oczekiwane: ciąg GRUB znaleziony na obu
# 4. Przetestuj boot z drugiego dysku (opcjonalne ale zalecane)
# W Robot → Reset → Boot next from /dev/sdb (jeśli dostępne)
# 5. Zweryfikuj zdrowie systemu plików
dmesg | grep -i "error\|fail\|corrupt"
# Oczekiwane: brak błędów systemu plików
Jeśli wszystkie macierze pokazują [UU] (oba dyski aktywne), GRUB jest na obu dyskach i nie ma błędów systemu plików w dmesg, rebuild jest zakończony. Twój serwer wrócił do pełnej redundancji.
Praca na serwerze dedykowanym ze zdegradowanym RAID oznacza, że kolejna awaria dysku to całkowita utrata danych. Okno między wymianą dysku przez Hetzner a Twoim rebuildem RAID jest momentem najwyższego ryzyka w cyklu życia serwera. Im szybciej odbudujesz, tym krótsze narażenie. Dla serwerów produkcyjnych zalecamy monitoring statusu mdadm z alertami i posiadanie tej procedury udokumentowanej i przetestowanej zanim będzie potrzebna.
Zarządzasz serwerami dedykowanymi w EU?
Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom utrzymywać infrastrukturę bare-metal w Hetzner, OVH i Scaleway z monitoringiem i planem odtwarzania po awarii.