Server bootet nicht mehr: mit dem Rettungssystem zurück

Ein Server, der nach einem Neustart nicht wiederkommt, fühlt sich wie ein Totalausfall an. Meist ist er es nicht: Die Daten liegen unversehrt auf der Platte, nur der Weg dorthin ist blockiert. Eine falsche Zeile in /etc/fstab, ein halb aktualisierter Bootloader oder eine SSH-Konfiguration, die sich selbst aussperrt. Mit dem Rettungssystem deines Anbieters kommst du von außen an die Platte heran und reparierst das, ohne neu zu installieren.

Zuerst: die Konsole#

Bevor du ins Rettungssystem wechselst, lohnt ein Blick in die Konsole deines Anbieters (oft VNC oder „Serielle Konsole“ genannt). Sie zeigt, was der Server beim Start tut, auch wenn das Netz nicht hochkommt.

Was die Konsole zeigt	Wahrscheinliche Ursache
„You are in emergency mode“	ein Eintrag in `/etc/fstab` passt nicht
„grub rescue>“ oder gar nichts	Bootloader beschädigt
Anmeldeaufforderung, aber kein SSH	Netz oder SSH-Konfiguration
Kernel-Fehler, „No space left“	volle Platte, siehe Platte voll

Im Notfallmodus kannst du dich oft direkt mit dem root-Passwort anmelden und den Fehler an Ort und Stelle beheben. Nur wenn das nicht geht, brauchst du das Rettungssystem.

Ins Rettungssystem#

Das Rettungssystem ist ein kleines Linux, das der Anbieter übers Netz startet, statt von deiner Platte. Du aktivierst es im Kundenbereich, startest den Server neu und meldest dich mit den dort angezeigten Zugangsdaten per SSH an. Deine Platte ist dann ein ganz normaler, nicht eingehängter Datenträger.

lsblk -f

Die Ausgabe zeigt Platten, Partitionen, Dateisysteme und Bezeichnungen. Auf einem KVM-VPS heißt die Platte meist /dev/vda oder /dev/sda, die Root-Partition ist die große ext4- oder xfs-Partition.

mount /dev/vda1 /mnt              # Beispiel, Partition anpassen
ls /mnt                           # sieht aus wie ein Root-Verzeichnis? Gut.

Mit LVM heißen die Partitionen anders. Erst die Volumes aktivieren:

vgchange -ay
lvs                                # zeigt z. B. vg0/root
mount /dev/vg0/root /mnt

Gibt es eine eigene /boot-Partition, gehört die dazu: mount /dev/vda2 /mnt/boot (Nummer anpassen, lsblk -f sagt es dir).

Per chroot ins kaputte System#

Viele Reparaturen gehen nur „von innen“: Bootloader neu schreiben, Pakete reparieren, Passwort setzen. Dafür wechselst du mit chroot in das eingehängte System:

for d in dev proc sys run; do mount --rbind /$d /mnt/$d; done
chroot /mnt /bin/bash

Ab jetzt wirken Befehle auf deinem Server-System, nicht auf dem Rettungssystem. exit bringt dich zurück.

Die vier häufigsten Ursachen#

1. fstab: ein Datenträger fehlt#

Ein Eintrag für eine zusätzliche Platte, die nicht mehr da ist oder eine neue Kennung bekommen hat, hält den Start an.

cat /etc/fstab
blkid                  # aktuelle UUIDs vergleichen

Falsche UUID korrigieren oder den Eintrag auskommentieren. Für alles außer der Root-Partition gehört nofail in die Optionen, dann startet der Server auch ohne diesen Datenträger:

UUID=…  /srv/daten  ext4  defaults,nofail  0  2

2. Bootloader nach einem abgebrochenen Update#

# im chroot
update-initramfs -u -k all
grub-install /dev/vda        # die Platte, nicht die Partition
update-grub

Bei UEFI-Systemen muss zusätzlich die EFI-Partition unter /boot/efi eingehängt sein, bevor du grub-install aufrufst. Brach das Update mitten im Paketlauf ab, räumt dpkg --configure -a und danach apt -f install die halb installierten Pakete auf.

3. SSH sperrt dich aus#

Eine Änderung an /etc/ssh/sshd_config mit Tippfehler, und der Dienst startet nicht mehr. Im chroot prüfst du die Datei:

sshd -t                     # meldet die fehlerhafte Zeile

War es eine bewusste Härtung, die zu weit ging (Passwortanmeldung aus, aber der Schlüssel fehlt), legst du deinen öffentlichen Schlüssel neu ab:

mkdir -p /root/.ssh
echo "ssh-ed25519 AAAA… du@rechner" >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys

Wie du beim nächsten Mal nicht in diese Lage kommst, steht in SSH härten: immer eine zweite Sitzung offen lassen, bevor du sshd neu startest.

4. Passwort vergessen#

passwd root          # im chroot

Zurück ins normale System#

exit                                  # chroot verlassen
umount -R /mnt

Dann im Kundenbereich das Rettungssystem deaktivieren und neu starten. Vergisst du das Deaktivieren, startet der Server wieder ins Rettungssystem, und es sieht aus, als hätte die Reparatur nichts gebracht.

Erst sichern, dann reparieren

Ist die Ursache unklar oder die Platte beschädigt, kopiere zuerst die wichtigsten Daten weg, zum Beispiel mit rsync -a /mnt/srv/ ziel:/sicherung/. Eine Reparatur, die schiefgeht, soll nicht das Letzte sein, was die Daten gesehen haben. Die bessere Absicherung ist ohnehin eine regelmäßige, verschlüsselte Sicherung.

Häufige Fragen#

Mein Anbieter hat kein Rettungssystem. Was dann?#

Viele Anbieter erlauben, ein ISO einzulegen, etwa eine Debian-Live-CD oder SystemRescue. Davon starten, dann ist der Ablauf derselbe. Gibt es beides nicht, bleibt nur der Support des Anbieters. Das ist ein gutes Auswahlkriterium, siehe VPS auswählen.

Das Dateisystem lässt sich nicht einhängen.#

Dann ist es vermutlich beschädigt. Nicht eingehängt prüfen: fsck -f /dev/vda1 für ext4, xfs_repair /dev/vda1 für xfs. Vorher, wenn irgend möglich, ein Abbild sichern.

Muss ich im chroot etwas beachten?#

Dienste startest du dort nicht, systemctl funktioniert im chroot nur eingeschränkt. Du reparierst Dateien und Pakete, gestartet wird nach dem Neustart.

Wie finde ich heraus, was kaputt war?#

Nach dem erfolgreichen Start: journalctl -b -1 -p err zeigt die Fehler des gescheiterten Bootvorgangs, sofern das Journal dauerhaft gespeichert wird. Wie das geht, steht in journalctl.

Kurz gesagt#

Erst in die Konsole schauen: Notfallmodus, grub oder SSH?
Im Rettungssystem mit lsblk -f die Root-Partition finden, einhängen, per chroot hineinwechseln.
fstab-Einträge für Zusatzplatten bekommen nofail.
sshd -t findet Tippfehler, bevor sie dich aussperren.
Nach der Reparatur das Rettungssystem deaktivieren, sonst startet es wieder.