Server ohne Ausfallzeit aktualisieren
Einen Server dürfen Sie nicht ohne Updates lassen, doch jedes Update birgt das Risiko, die Website lahmzulegen. Dieses Risiko beherrschen Sie mit einem festen Ablauf: Kleine Sicherheitskorrekturen werden automatisch eingespielt, größere Änderungen laufen nach Plan mit Snapshot, Prüfung und vorbereitetem Rollback, und Neustarts werden im Wartungsfenster gebündelt. Hier lesen Sie, wie Sie das auf einem einzelnen VPS einrichten.
Serverupdates gibt es in zwei Arten, und sie verlangen unterschiedlichen Umgang. Sicherheitskorrekturen erscheinen häufig, ändern wenig und machen fast nie etwas kaputt: Sie spielen sie am besten automatisch noch am selben Tag ein. Geplante Upgrades, also eine neue Version des Systems, von PHP, der Datenbank oder des Panels, ändern das Verhalten von Programmen, deshalb werden sie vorbereitet und geprüft. Eine Ausfallzeit entsteht meist nicht durch das Update an sich, sondern dadurch, dass eine große Änderung wie eine kleine eingespielt wurde.
Automatische Sicherheitsupdates
Unter Ubuntu Server ist das Paket unattended-upgrades standardmäßig installiert und aktiv: Einmal täglich spielt es nur Sicherheitsupdates ein, die übrigen Quellen in der Datei /etc/apt/apt.conf.d/50unattended-upgrades sind auskommentiert. Die Häufigkeit legen Sie in 20auto-upgrades fest, das Log landet in /var/log/unattended-upgrades/. Debian nutzt dasselbe Paket, auf einer Minimalinstallation kann es aber fehlen; wie Sie es aktivieren, beschreibt die Seite im Debian Wiki.
Unter AlmaLinux und anderen RHEL-kompatiblen Systemen übernimmt dnf-automatic diese Aufgabe. Standardmäßig installiert es keine Updates: In /etc/dnf/automatic.conf setzen Sie upgrade_type = security und apply_updates = yes und aktivieren danach den Timer dnf-automatic.timer.
Einen Neustart führen beide Werkzeuge standardmäßig nicht durch. Das ist richtig so, denn der Server soll nicht zur Hauptverkehrszeit neu starten. Vergessen dürfen Sie den Neustart aber nicht: Ein aktualisierter Kernel und aktualisierte Bibliotheken werden erst danach wirksam. Unter Ubuntu und Debian zeigt die Datei /run/reboot-required an, dass ein Neustart nötig ist, unter AlmaLinux der Befehl dnf needs-restarting -r. Diese Prüfung gehört ins Servermonitoring, den Neustart selbst erledigen Sie im Wartungsfenster.
Snapshot vor einem geplanten Upgrade
Vor jeder größeren Änderung legen Sie im Panel des Hosters einen Snapshot der Festplatte an. Er versetzt den Server in wenigen Minuten in den Ausgangszustand zurück, falls das Upgrade schiefgeht. Laut dem Katalog von accsly.io, Stand November 2026, beschreiben 1.644 von 2.247 VPS-Hostern ihre Backup-Bedingungen, und 318 nennen darin ausdrücklich Snapshots. Bietet der Hoster keine Snapshots, brauchen Sie vor dem Upgrade ein vollständiges Backup, dessen Wiederherstellung Sie bereits getestet haben.
Zwei Einschränkungen. Ein Snapshot liegt meist am selben Ort wie die Festplatte des Servers und ersetzt kein Backup: Fällt der Speicher aus, sind beide verloren. Außerdem kann der Snapshot einer laufenden Datenbank inkonsistent sein, deshalb erstellen Sie vorher einen Dump der Datenbank oder halten die Schreibzugriffe kurz an. Wie Sie die Datensicherung insgesamt aufbauen, erklärt der Artikel VPS-Backups: Strategien und Werkzeuge, Tarife mit Platz für Backups finden Sie auf der Seite VPS für Backups.
Blue-Green und schrittweises Update auf einem VPS
Verfahren ohne Ausfallzeit stammen aus großen Systemen, in denen mehrere Server hinter einem Load Balancer stehen: Blue-Green hält zwei vollständige Kopien vor und schaltet den Traffic von der einen auf die andere um, ein schrittweises Update (Rolling Update) nimmt die Server einzeln aus dem Betrieb. Auf einem einzelnen VPS lassen sich dieselben Ideen auf die Anwendung übertragen, allerdings nicht auf das System selbst.
- Release-Verzeichnisse. Jede Version der Website wird in ein eigenes Verzeichnis ausgeliefert, etwa
releases/2026-11-07, und der Webserver zeigt auf den symbolischen Linkcurrent. Die neue Version bereiten Sie daneben vor, mit Abhängigkeiten, Build und Cache, und schalten dann den Link mit einem einzigen Befehl um. Für ein Rollback setzen Sie den Link auf das vorherige Verzeichnis zurück. - Zwei Instanzen der Anwendung. Die neue Version startet auf einem anderen Port oder in einem anderen Container, wird geprüft, und danach schalten Sie nginx auf sie um. Das Neuladen der nginx-Konfiguration trennt keine Verbindungen: Laut Dokumentation von nginx prüft der Hauptprozess zuerst die Konfiguration und arbeitet bei einem Fehler mit der alten weiter, und die alten Worker-Prozesse bedienen ihre Clients zu Ende. Vorher führen Sie trotzdem
nginx -taus. Wie Sie Anwendungen in Containern betreiben, beschreibt der Artikel Docker auf einem VPS: der Einstieg. - Kompatible Datenbankmigrationen. Solange beide Versionen laufen, muss die Datenbank zu beiden passen. Änderungen am Schema teilen Sie deshalb in Schritte auf: Zuerst kommen neue Spalten und Tabellen hinzu, dann wird Code ausgeliefert, der sie nutzt, und erst im nächsten Release wird das Alte entfernt.
Ein Upgrade des Systems selbst auf eine neue Hauptversion lässt sich auf einem einzelnen Server nicht ohne Ausfallzeit durchführen. Zuverlässiger ist es, einen zweiten VPS mit dem neuen System aufzusetzen, die Website dorthin umzuziehen, sie zu prüfen und das DNS umzustellen, nachdem Sie vorher die TTL der Einträge gesenkt haben. Wie das geht, erklärt der Artikel Domains und DNS für Serverbetreiber. Den zweiten Server nehmen Sie für die Dauer des Umzugs am besten mit stündlicher Abrechnung. Wie Sie die Systemversion so wählen, dass solche Umzüge seltener nötig sind, lesen Sie im Artikel Linux-Distributionen für den Server: Ubuntu, Debian, AlmaLinux.
Kernel-Update ohne Neustart
Live Patching schließt kritische Sicherheitslücken im laufenden Kernel, ohne den Server neu zu starten. Unter Ubuntu ist das Livepatch aus dem Abonnement Ubuntu Pro: Für den privaten Gebrauch ist es auf fünf Maschinen kostenlos. Für RHEL-kompatible Systeme gibt es eigene Mechanismen, darunter kommerzielle Dienste.
Die Technik hat Grenzen. Korrigieren lassen sich nur Funktionen, die der Kernel tracen kann; diese Einschränkung beschreibt die Dokumentation des Linux-Kernels, deshalb kommt ein Teil der Korrekturen nur mit einem neuen Kernel. Canonical schreibt ausdrücklich, dass Livepatch geplante Neustarts nicht ersetzt, sondern nur erlaubt, sie bis zum Wartungsfenster aufzuschieben. Und das Wichtigste für einen VPS: Einen eigenen Kernel gibt es nur bei der Virtualisierung mit KVM. Unter OpenVZ und LXC ist der Kernel gemeinsam, und der Hoster aktualisiert ihn. Mehr dazu im Artikel KVM oder OpenVZ: was Sie wählen sollten.
Wartungsfenster und Rollback
Das Wartungsfenster ist ein vorab festgelegter Zeitraum mit den wenigsten Besuchern, meist die Nacht in der Zeitzone des Hauptpublikums, in dem Neustarts und geplante Änderungen erlaubt sind. Die Zeit entnehmen Sie der Statistik der Website, statt sie zu raten. Nutzen Kunden oder Mitarbeitende die Website, informieren Sie sie rechtzeitig. Das Fenster brauchen nicht nur Sie: Auch der Hoster führt Wartungsarbeiten durch, und wie er darüber informiert, behandelt der Artikel SLA und Uptime: was Anbieter versprechen.
Den Rollback-Plan erstellen Sie vor Beginn der Arbeiten, nicht erst, wenn etwas kaputtgegangen ist:
- Legen Sie vorab fest, woran Sie einen Fehlschlag erkennen, etwa Fehler in den Logs, steigende Antwortzeiten oder eine fehlgeschlagene Prüfung der wichtigsten Seiten, und nach welcher Frist Sie zurückrollen, ohne weitere Reparaturversuche;
- beim Code schalten Sie den Link oder nginx auf das vorherige Release zurück;
- für Pakete gibt es unter AlmaLinux
dnf history undo, das die letzte Transaktion rückgängig macht; Ubuntu und Debian haben kein reguläres Rollback für Pakete, dort verlassen Sie sich auf den Snapshot; - ein Snapshot setzt die gesamte Festplatte zurück, und alles, was danach geschrieben wurde, also Bestellungen, Nachrichten und Registrierungen, geht verloren. Deshalb versetzen Sie die Website für die Dauer eines riskanten Upgrades in den Wartungsmodus oder in einen Nur-Lese-Modus.
Prüfen Sie nach dem Update die wichtigsten Seiten und die Fehlerlogs und vergleichen Sie die Antwortzeit mit dem gewohnten Wert. Haben Sie vor dem Start einen Lasttest durchgeführt, zeigt dasselbe Szenario nach einem großen Update schnell, ob die Website langsamer geworden ist.