Hetzner Rescue System starten – Schritt-für-Schritt Anleitung für Server-Admins

Ich zeige dir, wie du das hetzner rescue system in wenigen Minuten startest, dich per SSH einloggst und deinen Server zielgerichtet reparierst. Diese Anleitung führt dich Schritt für Schritt vom Aktivieren bis zur Wiederherstellung, einschließlich Dateisystem-Checks, Backups und Neuinstallation.

Zentrale Punkte

Die folgenden Kernaspekte helfen dir, den Start und die Arbeit im Rettungsmodus ohne Umwege umzusetzen.

• Rescue-Start: Aktivierung in Robot oder Cloud, dann Reboot.
• SSH-Zugriff: Login mit Key oder Passwort und Root-Rechte.
• Fehleranalyse: fsck, Logs, Partitionen prüfen.
• Datensicherung: rsync, tar, scp für schnelle Backups.
• Neuinstallation: installimage für frische Systeme.

Was das Rescue System leistet

Das Rescue System lädt eine eigenständige Linux-Umgebung in den Arbeitsspeicher und verschafft mir sofortigen Root-Zugriff, selbst wenn das installierte Betriebssystem ausfällt. Ich boote unabhängig von defekten Bootloadern, beschädigten Paketen oder fehlerhaften Konfigurationen. So prüfe ich Dateisysteme, rette Daten, analysiere Logs und setze Dienste wieder in Gang. Die Umgebung bleibt schlank, bietet aber alle wichtigen Tools für Diagnose und Recovery. Damit behalte ich die Kontrolle, auch wenn das reguläre System komplett streikt.

Praktisch ist, dass die Rescue-Umgebung bewusst flüchtig ist: Änderungen verschwinden nach dem Reboot, wodurch ich gefahrlos testen kann. Ich installiere bei Bedarf temporäre Tools (z. B. smartmontools, mdadm, lvm2, btrfs-progs oder xfsprogs), ohne das produktive System zu verändern. Die Kernel-Version ist modern und unterstützt aktuelle Hardware, inklusive NVMe, UEFI, GPT, Software-RAID (mdraid), LVM und LUKS-Verschlüsselung. So decke ich auch komplexe Storage-Setups ab und kann selbst seltene Fehlerbilder reproduzierbar isolieren.

Voraussetzungen und Zugang

Für den Start brauche ich Zugang zum Kunden-Interface und meine SSH-Keys oder ein temporäres Passwort. Dedizierte Systeme verwalte ich komfortabel über den Hetzner Robot, während ich Instanzen in der Cloud über die Console steuere. Beide Oberflächen bieten eine klare Option zum Aktivieren des Rettungsmodus. Ich prüfe vorab die korrekte Server-IP, IPv6-Verfügbarkeit und ggf. Out-of-Band-Funktionen für den Reset. Diese Vorbereitung verkürzt die Ausfallzeit deutlich.

Beim ersten SSH-Login bestätige ich den neuen Fingerprint bewusst und aktualisiere bei Bedarf meinen Known-Hosts-Eintrag, damit spätere Verbindungen nicht an Warnungen scheitern. Für Teams hinterlege ich zusätzliche Keys gezielt für den Rescue-Einsatz und entferne sie nach Abschluss wieder. Steht nur ein temporäres Passwort bereit, ändere ich es sofort nach dem Einloggen und tausche es anschließend gegen Key-Auth aus – Passwort-Logins deaktiviere ich zum Ende der Arbeiten konsequent.

Rescue System aktivieren – Schritt für Schritt

Ich öffne das Server-Detailfenster, wähle die Option „Rescue“ und setze die Architektur auf linux64 für aktuelle Systeme, dann hinterlege ich meinen SSH-Key. Je nach Lage starte ich nur den Rettungsmodus und löse den Reboot separat aus oder ich nutze „Rescue aktivieren & Power Cycle“ für einen direkten Neustart. Bleibt die Maschine hängen, setze ich einen Hard-Reset über das Interface. Nach dem Boot zeigt die Oberfläche ein temporäres Root-Passwort, falls ich keinen Key eingetragen habe. Sobald der Server hochfährt, reagiert er auf SSH und ich kann loslegen.

Bei komplexen Situationen plane ich eine klare Reihenfolge: Aktivieren, Power Cycle, SSH-Login testen, dann erst Troubleshooting starten. Auf Dedicated-Servern kann ein manueller Power Cycle notwendiger sein, während Cloud-Instanzen meist sofort in den Rescue-Mode wechseln. Wichtig: Nach erfolgreicher Reparatur schalte ich den Rettungsmodus wieder aus, damit die Maschine erneut von der lokalen Platte bootet.

SSH-Verbindung und erste Checks

Ich verbinde mich per SSH mit ssh root@<Server-IP> und prüfe zuerst Netzwerk, Datenträger und Logs für einen schnellen Überblick über den Status. Mit ip a und ping kontrolliere ich die Erreichbarkeit; journalctl --no-pager -xb oder Logdateien auf den gemounteten Platten zeigen letzte Fehlermeldungen. Die Kommandos lsblk, blkid und fdisk -l verschaffen Klarheit über Layout und Dateisysteme. Bei RAID nutze ich cat /proc/mdstat sowie mdadm --detail für den Zustand. Für erste Hardware-Indikatoren helfen smartctl -a und ein kurzer hdparm -Tt-Test.

LVM, RAID, LUKS und besondere Dateisysteme

Viele Server nutzen LVM, Software-RAID oder Verschlüsselung. Ich aktiviere zunächst alle relevanten Schichten:

• mdraid: mdadm --assemble --scan bringt vorhandene Arrays hoch; Status prüfe ich mit cat /proc/mdstat.
• LUKS: Verschlüsselte Volumes öffne ich mit cryptsetup luksOpen /dev/<device> <name>.
• LVM: Mit vgscan und vgchange -ay aktiviere ich Volume-Gruppen und sehe sie via lvs/vgs/pvs.

Bei Btrfs achte ich auf Subvolumes und mounte gezielt mit -o subvol=@ beziehungsweise -o subvolid=5 für den Top-Level. XFS prüfe ich mit xfs_repair (niemals auf gemounteten Volumes), während Ext4 klassisch mit fsck.ext4 -f saniert wird. Ich orientiere mich an der GUID/UUID aus blkid, weil Device-Namen bei NVMe (/dev/nvme0n1p1) und bei wechselnder Reihenfolge variieren können. Entsprechend korrigiere ich später die /etc/fstab.

Dateisystem-Reparatur und Datensicherung

Bevor ich repariere, sichere ich wichtige Daten mit rsync, scp oder tar auf ein externes Ziel oder ein lokales Backup-Verzeichnis. Für Checks nutze ich fsck nur auf ungemounteten Partitionen, etwa fsck -f /dev/sda2, um Inkonsistenzen sauber zu korrigieren. Anschließend mounte ich das System unter /mnt, zum Beispiel mit mount /dev/sda2 /mnt, und hänge Unterpfade wie /proc, /sys und /dev an, wenn ich chrooten möchte. Einzelne Konfigurationsdateien wie /etc/fstab oder Netzwerkeinstellungen passe ich direkt im gemounteten System an. Mit behutsamem Vorgehen verhindere ich Folgeschäden und halte die Downtime gering.

Für zuverlässige Backups setze ich auf wiederholbare Befehle: rsync -aHAX --info=progress2 erhält Rechte, Hardlinks, ACLs und xattrs. Bei schwacher Leitung drossele ich mit --bwlimit und parallelisiere Komprimierung mit tar -I pigz. Kritische, fehlerhafte Datenträger bilde ich notfalls blockweise mit ddrescue ab, um die logische Arbeit auf ein Image zu verlagern. Btrfs-Systeme prüfe ich vorsichtig mit btrfs check --readonly und nutze btrfs scrub, um stille Fehler aufzuspüren. XFS verlangt bei Inkonsistenzen oft ein Off-Mount-Repair (xfs_repair) – vorher sichere ich die Partition unbedingt.

UEFI/BIOS, GPT/MBR und Bootloader-Reparatur

Viele Bootprobleme stecken im Zusammenspiel aus Firmware, Partitionsschema und Bootloader. Ich kläre zuerst, ob der Server im UEFI- oder Legacy-BIOS-Modus startet (ls /sys/firmware/efi). Bei UEFI mounte ich die EFI-Partition (typisch /dev/sdX1 oder /dev/nvme0n1p1) nach /mnt/boot/efi. Danach chroote ich in das System:

mount /dev/<root> /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Ich installiere den Bootloader passend neu (grub-install auf das richtige Device) und regeneriere Konfiguration und Initramfs: update-grub sowie update-initramfs -u -k all (bei dracut-basierten Systemen dracut -f). Stimmt die Reihenfolge der Devices nicht, nutze ich in der /etc/default/grub UUIDs und prüfe /etc/fstab auf korrekte Einträge. Bei GPT/MBR-Wechseln kontrolliere ich, ob eine BIOS-Boot-Partition (bei GRUB/BIOS) bzw. eine gültige EFI-Systempartition existiert.

Netzwerk-Fallstricke im Rescue

Netzwerkprobleme sind häufig der Grund, warum Dienste „weg“ sind. Im Rescue prüfe ich Link-Status (ip link), Routen (ip r) und DNS-Auflösung (resolvectl status bzw. cat /etc/resolv.conf). Ich teste IPv4 und IPv6 getrennt (ping -4/ping -6). Bei Servern mit Bridges oder Bonding kann die Reihenfolge von Interfaces im produktiven System von der Rescue-Umgebung abweichen. Ich notiere die MAC-Adressen und mappe sie korrekt. Wenn das Produktivsystem Netplan verwendet, verifiziere ich die /etc/netplan/*.yaml und wende nach dem Chroot netplan generate und netplan apply an. Bei klassischen /etc/network/interfaces-Setups achte ich auf konsistente Interface-Namen (predictable names vs. eth0).

Betriebssystem neu installieren

Wenn Reparaturen keinen Sinn mehr ergeben, setze ich das System mit installimage vollständig neu auf und spare so wertvolle Zeit. Das Tool führt mich durch Auswahl von Distribution, Partitionierung und Bootloader. Eigene Konfigurationsdateien und SSH-Keys binde ich in die Installation ein, damit der erste Boot reibungslos läuft. Nach der Installation starte ich den Server regulär und prüfe Dienste, Firewall und Updates. Zum Abschluss entferne ich den Rettungsmodus, damit der nächste Boot wieder vom lokalen Datenträger erfolgt.

Ich setze bei der Neuinstallation bewusst auf UUID-basierte Mounts, um spätere Device-Order-Probleme auszuschließen. Für RAID-Setups lasse ich die Arrays von Beginn an erzeugen und überprüfe den Rebuild-Status, bevor ich Daten zurückspiele. Wer wiederkehrend ähnliche Systeme bereitstellt, arbeitet mit vordefinierten installimage-Templates und einer klaren Partitionierungslogik (Root, getrennte Daten-Partition, Swap, ggf. EFI). Nach dem ersten Boot aktualisiere ich Paketquellen, Kernel, aktiviere Security-Autoupdates und rolle meine Basis-Hardening-Schritte aus.

Sicherheit, Zeitfenster und Rückfall

Der Zugang läuft ausschließlich über SSH, daher setze ich konsequent auf Keys statt statischer Passwörter. Der Rettungsmodus bleibt nach Aktivierung zeitlich begrenzt bereit und fällt beim nächsten normalen Neustart auf das lokale Boot-Device zurück. Ich arbeite zügig, dokumentiere jeden Schritt und halte bei größeren Eingriffen eine zweite Session offen. Sensible Daten schreibe ich nicht in bash-Historien und lösche temporäre Dateien nach dem Einsatz. Nach erfolgreicher Wiederherstellung deaktiviere ich den Modus wieder im Interface.

Nach der Reaktivierung des Produktivsystems rotiere ich Zugangsdaten, entferne temporäre Rescue-Keys, setze überflüssige Root-Passwörter zurück und sichere frisch generierte Konfigurationen. Ich sammele Audit-Informationen (wer hat wann was getan) und dokumentiere Abweichungen vom Standard-Setup. So werden Notmaßnahmen nicht zu Dauerzustand, und ich halte Compliance-Vorgaben ein.

Beispiel: WordPress-Server retten

Ich boote in den Rettungsmodus, mounte die Systempartition und sichere die Datenbank per mysqldump sowie das wp-content-Verzeichnis mit tar oder rsync. Danach prüfe ich das Dateisystem, setze den Bootloader neu und korrigiere fehlerhafte PHP- oder NGINX-Konfigurationen. Falls Pakete zerschossen sind, nutze ich chroot und installiere Abhängigkeiten nach. Reicht das nicht, setze ich die Maschine mit installimage neu auf und spiele Backup und Konfigurationen gezielt zurück. Zum Schluss verifiziere ich Frontend, Login und Cronjobs.

In der Praxis achte ich auf InnoDB-Konsistenz (MySQL/MariaDB): Scheitert mysqld am Start, sichere ich die /var/lib/mysql und führe den Dump aus einer frischen Instanz heraus. Caches (Object Cache, Page Cache, OPCache) leere ich gezielt, setze Dateirechte konsistent (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) und kontrolliere open_basedir sowie Upload-Verzeichnisse. Kritische Plugins deaktiviere ich testweise, indem ich das Plugin-Verzeichnis umbenenne. Anschließend überprüfe ich PHP-FPM-Pools, FastCGI-Timeouts, Memory-Limits und die NGINX/Apache-Includes. Ein kurzer wp cron event run --due-now (falls WP-CLI verfügbar) hilft, Backlogs abzuarbeiten.

Best Practices für Admins

Vor tiefen Eingriffen erstelle ich ein frisches Backup und sichere Schlüsseldateien wie /etc, damit ich jederzeit zurückspringen kann. Jeder Schritt wandert in ein kurzes Log, das mir später bei Audits oder erneuten Zwischenfällen hilft. Nach dem Reboot in das produktive System prüfe ich Dienste, Logs, Netzwerk und Monitoring gründlich. Für wiederkehrende Arbeiten baut sich ein kleines Skript-Set auf, um Kommandofolgen zu standardisieren. Wer zusätzliche Leistung oder neue Hardware plant, kann vorab passende Root-Server mieten und Migrationsfenster sauber vorbereiten.

Ich halte zusätzlich eine Runbook-Checkliste bereit, die Verantwortlichkeiten und Eskalationswege enthält. Geplante „Game Days“ (gezielte Ausfall-Simulationen) trainieren das Team für den Ernstfall. Backups teste ich regelmäßig als Restore-Probe – ein nicht getestetes Backup gilt als nicht vorhanden. Und ich versioniere meine Systemkonfigurationen, damit ich Unterschiede zwischen „gutem“ und „defektem“ Zustand schnell erkenne.

Cloud vs. Dedicated: Unterschiede im Ablauf

In der Cloud wechsle ich den Bootmodus oft direkt im Instanz-Dialog und nutze die serielle Konsole für schnelle Checks, während auf Dedicated-Servern ein Power Cycle und ggf. Out-of-Band-Zugriff nötig sind. Cloud-Volumes lassen sich komfortabel an andere Instanzen anhängen – ein effizienter Weg, um Daten ohne Downtime am betroffenen Host zu sichern. Auf Bare Metal achte ich stärker auf die physische Reihenfolge der Laufwerke, insbesondere bei Zukauf zusätzlicher SSDs/NVMe-Module. In beiden Welten gilt: Rescue ist ein temporäres Werkzeug – ich plane den Rückweg ins normale Boot frühzeitig ein.

Vergleich: Anbieter mit Rescue-System

Für schnelle Wiederherstellung zählt neben guter Hardware auch ein sauber integriertes Rescue-Feature. Die folgende Tabelle zeigt einen kompakten Überblick zu Funktionsumfang und Handhabung. Ich orientiere mich dabei an Verfügbarkeit, einfachem Zugriff und typischen Admin-Workflows. Die Einstufung „Empfehlung“ spiegelt meinen praktischen Nutzen bei typischen Störungen wider. Je nach Einsatzziel kann die Gewichtung natürlich variieren.

Anbieter	Rescue System verfügbar	Bedienkomfort	Leistung	Empfehlung
webhoster.de	Ja	Sehr gut	Sehr hoch	Testsieger
Hetzner	Ja	Sehr gut	Hoch
Strato	Teilweise	Gut	Mittel
IONOS	Nein	Mittel	Mittel

Checkliste: Schrittfolge im Ernstfall

• Rescue aktivieren, Reboot/Power Cycle auslösen, SSH testen.
• Hardware/Storage sichten: smartctl, lsblk, blkid, mdstat, lvm.
• Arrays/LUKS/LVM aktivieren, Dateisysteme read-only inspizieren.
• Backup erstellen (rsync/tar), dann erst fsck/Reparaturen.
• System unter /mnt mounten, Bind-Mounts, chroot.
• Bootloader/Initramfs reparieren, Netzwerk-Konfig prüfen.
• Testboot, Dienste verifizieren, Monitoring/Alarme checken.
• Rescue deaktivieren, temporäre Keys entfernen, Doku aktualisieren.

FAQ Hetzner Rescue System

Kann ich meine Daten retten, wenn das System nicht mehr bootet? Ja, ich lese die Datenträger direkt im Rettungsmodus und sichere wichtige Ordner oder ganze Partitionen.

Wie lange bleibt der Rettungsmodus aktiv? Nach der Aktivierung steht das System begrenzt zur Verfügung und wechselt beim nächsten regulären Reboot wieder auf das lokale Boot-Device, ich plane deshalb einen zügigen Ablauf.

Funktioniert das für Cloud- und Dedicated-Server? Ja, ich starte den Modus sowohl für dedizierte Maschinen als auch für Cloud-Instanzen in der Hetzner Cloud.

Was mache ich bei beschädigtem Bootloader? Ich mounte Root und ggf. EFI, chroote ins System, führe grub-install, update-grub und ein Rebuild des Initramfs aus, dann teste ich den Reboot.

Wie gehe ich mit LVM/RAID um? Ich assemble zuerst mdraid, aktiviere LVM mit vgchange -ay und mounte anschließend die Logik-Volumes. Reparaturen passieren erst nach einem Backup.

Kann ich nur einzelne Dateien retten? Ja, ich mounte read-only und kopiere selektiv Konfigs, Datenbanken (via Dump) oder Verzeichnisse – minimalinvasiv und schnell.

Kernbotschaft

Mit dem Hetzner Rescue System halte ich ein schnelles Werkzeug bereit, das Bootprobleme, Dateisystemfehler und beschädigte Konfigurationen zuverlässig einkreist. Ich aktiviere den Modus, logge mich per SSH ein, sichere Daten und entscheide danach zwischen Reparatur oder Neuinstallation. Das spart Zeit im Ernstfall und reduziert Ausfälle auf das Nötigste. Wer die wenigen Schritte verinnerlicht, meistert auch schwierige Ausfälle mit Ruhe. So bleibt der Serverbetrieb planbar und der Restart verläuft kontrolliert.