Hetzner Rescue-System: So reparierst du deinen Server, wenn nichts mehr geht

Es gibt Situationen, in denen selbst die Hetzner Web-Konsole nicht mehr weiterhilft: Der Server bootet nicht mehr, ein fehlerhaftes Update hat kritische Systemdateien beschädigt, oder ein falsch konfigurierter Dienst verhindert den Start des Systems. Genau für solche Fälle bietet Hetzner das Rescue-System an – ein minimales Linux-System, das unabhängig vom installierten Betriebssystem startet und direkten Zugriff auf alle Festplatten und Volumes ermöglicht.

Was ist das Rescue-System?

Das Hetzner Rescue-System ist ein temporäres Live-System, das beim nächsten Serverstart anstelle des normalen Betriebssystems geladen wird. Es läuft vollständig im Arbeitsspeicher und greift dabei nicht auf die installierten Festplatten zu – man kann also das eigentliche System in Ruhe analysieren und reparieren, ohne es zu verändern. Sobald der Server nach der Reparatur normal neu gestartet wird, bootet wieder das reguläre Betriebssystem.

Rescue-System aktivieren

Das Rescue-System wird für beide Servertypen (Cloud und Dedicated) über die Hetzner Console unter console.hetzner.com aktiviert.

Bei Hetzner Cloud

1. Öffne die Hetzner Console unter console.hetzner.com
2. Wähle das gewünschte Projekt und den betroffenen Server aus
3. Navigiere links zu „Rescue“
4. Klicke auf „Rescue aktivieren“ und wähle das System (z. B. linux64)
5. Das angezeigte Root-Passwort notieren – es wird nur einmal angezeigt!
6. Den Server anschließend neu starten, damit das Rescue-System geladen wird

Bei Hetzner Dedicated

1. Öffne die Hetzner Console unter console.hetzner.com
2. Wähle den Dedicated Server aus
3. Navigiere zu „Rescue“, Betriebssystem wählen (z. B. linux64) und aktivieren
4. Root-Passwort notieren
5. Den Server anschließend neu starten, damit das Rescue-System geladen wird

Per SSH ins Rescue-System einloggen

Nach dem Neustart ist das Rescue-System aktiv. Der Login erfolgt per SSH:

ssh root@<server-ip>

Hinweis: SSH-Fingerprint-Warnung

Da das Rescue-System einen anderen SSH-Fingerprint hat als das normale Betriebssystem, wird SSH sich mit einer Fehlermeldung weigern:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Das ist kein echtes Sicherheitsproblem – sondern liegt schlicht daran, dass ein anderes System auf dem Server läuft. Der alte Eintrag muss aus der known_hosts-Datei entfernt werden. Das geht am schnellsten per Befehl:

ssh-keygen -R <server-ip>

Wer die Datei lieber manuell im Texteditor bearbeiten möchte, findet sie hier:

• Linux/macOS: ~/.ssh/known_hosts
• Windows: C:\Users\<Benutzername>\.ssh\known_hosts

Einfach die Zeile suchen, die mit der IP-Adresse des Servers beginnt, und sie vollständig löschen. Danach kann man sich normal verbinden und den neuen Fingerprint einmalig bestätigen.

Das Live-System mounten

Im Rescue-System sind die Festplatten des eigentlichen Servers zwar vorhanden, aber noch nicht eingehängt. Um auf das Dateisystem zugreifen zu können, müssen die Partitionen zunächst gemountet werden.

Schritt 1: Verfügbare Partitionen anzeigen

lsblk -f

Die Ausgabe zeigt alle vorhandenen Datenträger, ihre Partitionen und Dateisystemtypen. Eine typische Ausgabe könnte so aussehen:

NAME    FSTYPE  LABEL   SIZE MOUNTPOINT
sda
├─sda1  ext4            39.9G
└─sda15 vfat            100M
sdb     ext4            50G

Hier ist sda1 das Root-Volume des eigentlichen Systems, sdb ein zusätzliches Datenvolume.

Schritt 2: Mountpunkte anlegen

Zunächst legen wir saubere Mountpunkte an, damit die Volumes klar voneinander getrennt bleiben:

mkdir -p /mnt/rootdisk
mkdir -p /mnt/dataspace

Schritt 3: Volumes mounten

mount /dev/sda1 /mnt/rootdisk
mount /dev/sdb  /mnt/dataspace

Bei einem BTRFS-Dateisystem (bei neueren Hetzner-Images üblich) muss für das Root-Volume der Subvolume-Pfad angegeben werden:

mount -o subvol=@ /dev/sda1 /mnt/rootdisk

Schritt 4: Systempfade einbinden

Damit Werkzeuge wie chroot korrekt funktionieren, müssen noch die virtuellen Dateisysteme eingebunden werden:

mount --bind /dev  /mnt/rootdisk/dev
mount --bind /proc /mnt/rootdisk/proc
mount --bind /sys  /mnt/rootdisk/sys

Das System ist jetzt vollständig eingehängt und bereit zur Analyse oder Reparatur.

Logfiles einsehen

Einer der häufigsten Gründe für einen Serverausfall steckt in den Logfiles. Sie liegen nach dem Mounten direkt zugänglich unter /mnt/rootdisk/var/log/:

# Systemlog (allgemeine Systemmeldungen)
cat /mnt/rootdisk/var/log/syslog

# Kernel-Meldungen beim Boot
cat /mnt/rootdisk/var/log/kern.log

# Authentifizierungs- und Login-Fehler
cat /mnt/rootdisk/var/log/auth.log

# Meldungen von systemd-Diensten
journalctl -D /mnt/rootdisk/var/log/journal

Für eine bequemere Suche in langen Logs empfiehlt sich grep:

grep -i "error\|fail\|critical" /mnt/rootdisk/var/log/syslog | tail -50

Grundlegende Reparaturen durchführen

Konfigurationsdateien bearbeiten

Da das Dateisystem gemountet ist, können alle Konfigurationsdateien direkt bearbeitet werden:

# Nginx-Konfiguration reparieren
nano /mnt/rootdisk/etc/nginx/nginx.conf

# SSH-Konfiguration korrigieren
nano /mnt/rootdisk/etc/ssh/sshd_config

# Netzwerkkonfiguration anpassen (Ubuntu Netplan)
nano /mnt/rootdisk/etc/netplan/50-cloud-init.yaml

In das System wechseln (chroot)

Mit chroot kannst du in die Umgebung des gemounteten Systems „einsteigen“ – so als wärst du direkt auf dem laufenden Server eingeloggt. Das ist besonders nützlich, um Pakete zu installieren, Passwörter zu ändern oder den Bootloader zu reparieren:

chroot /mnt/rootdisk /bin/bash

Ab jetzt bist du in der Umgebung des Live-Systems. Du kannst z. B.:

# Passwort eines Benutzers zurücksetzen
passwd root

# Defekte Pakete reparieren
apt --fix-broken install

# Einen Dienst neu konfigurieren
dpkg-reconfigure openssh-server

# Grub-Bootloader neu installieren
grub-install /dev/sda
update-grub

Mit exit verlässt du die chroot-Umgebung wieder.

Dateisystem auf Fehler prüfen

Falls der Verdacht besteht, dass das Dateisystem selbst beschädigt ist, kann fsck helfen. Wichtig: Die Partition darf dabei nicht gemountet sein!

# Zuerst aushängen
umount /mnt/rootdisk

# Dann prüfen und reparieren
fsck -y /dev/sda1

# Danach wieder mounten
mount /dev/sda1 /mnt/rootdisk

Zurück zum normalen Betrieb

Wenn alle Reparaturen abgeschlossen sind, reicht ein normaler Neustart:

reboot

Das Rescue-System ist nur für einen einzigen Boot aktiv – danach startet der Server automatisch wieder mit dem normalen Betriebssystem. Falls das Rescue-System erneut benötigt wird, muss es in der Hetzner Console neu aktiviert werden.

Rescue-System als Präventivmaßnahme verstehen

Das Rescue-System ist kein Zeichen dafür, dass etwas schiefgelaufen ist – es ist ein professionelles Werkzeug, das jeder Serveradministrator kennen sollte, bevor er es im Notfall braucht. Wer einmal in Ruhe geübt hat, wie man das System mountet und Logs liest, ist im echten Ernstfall deutlich entspannter.