Ubuntu Server 2026: Die Wahl zwischen den LTS-Releases (und das Upgrade)
Drei Ubuntu-LTS-Releases sind derzeit im Einsatz: 22.04 nähert sich dem Ende des regulären Supports, 24.04 befindet sich in seinen komfortablen mittleren Jahren, und das neue 26.04 "Resolute Raccoon" bringt Linux 7.0 mit. Welches auf Ihren Server gehört, hängt davon ab, wo Sie im Zyklus stehen, und die Antwort unterscheidet sich für Neubereitstellungen und bestehende Flotten. Dieser Leitfaden liefert die Tabelle der Support-Fenster, was sich in 26.04 für Serverbetreiber tatsächlich geändert hat, die ehrlichen Gründe, vorerst bei 24.04 zu bleiben, sowie die Mechanik des Upgrades, einschließlich des Termins im August 2026, an dem der Weg von LTS zu LTS sich öffnet.
Loading...
Die Antwort vorab
- Neuer Server heute? Setzen Sie 24.04 LTS oder 26.04 LTS ein: 26.04, wenn Sie den neuen Kernel wollen und eine Support-Uhr, die bis 2031 läuft, 24.04, wenn ein Drittanbieter-Repository, von dem Sie abhängen, noch keine 26.04-Pakete veröffentlicht hat (prüfen Sie das, bevor Sie sich festlegen; drei Monate nach Release haben manche das immer noch nicht).
- Sie betreiben 24.04? Alles in Ordnung: regulärer Support bis 2029, und das freigegebene In-Place-Upgrade auf 26.04 öffnet erst mit dem Point-Release 26.04.1, erwartet im August 2026. Keine Eile; aktualisieren Sie nach Ihrem eigenen Zeitplan zwischen dann und 2029.
- Sie betreiben 22.04? Beginnen Sie jetzt mit der Planung. Die reguläre Sicherheitspflege endet im Frühjahr 2027, und Ihr Weg zu 26.04 führt über zwei Etappen (22.04 → 24.04 → 26.04). Planen Sie entweder diese Etappen ein, oder buchen Sie Ubuntu Pro hinzu, um Zeit bis 2032 zu gewinnen.
- Sie betreiben eine Interimsversion (Nicht-LTS) auf einem Server? Wechseln Sie zu einer LTS: Interimsversionen erhalten neun Monate Support und sind für Early Adopters und Desktops gedacht, nicht für Produktivserver.
Die Übersicht
| Release | Kernel (GA) | Regulärer Support endet | Mit Ubuntu Pro | Pro + Legacy-Add-on |
|---|---|---|---|---|
| 22.04 "Jammy" | 5.15 | Frühjahr 2027 | 2032 | 2037 |
| 24.04 "Noble" | 6.8 (HWE: neuer) | 2029 | 2034 | 2039 |
| 26.04 "Resolute" | 7.0 | April 2031 | 2036 | 2041 |
Termine laut Canonicals Release-Zyklus; die Genauigkeit auf Monatsebene verschiebt sich gelegentlich, planen Sie also in Quartalen, nicht in Tagen. Zwei strukturelle Anmerkungen: Jede LTS erhält fünf kostenlose Jahre Sicherheitspflege für das main-Repository; das weitverbreitete universe-Repository erhält systematische Abdeckung durch Ubuntu Pros ESM (kostenlos für bis zu fünf Maschinen, mehr dazu weiter unten unter "Ubuntu Pro"). Und mitten in der LTS-Laufzeit bietet der HWE-Stack (Hardware Enablement) neuere Kernel auf älteren Releases: Die Point-Releases von 24.04 liefern Kernel weit jenseits von 6.8, was oft alles ist, was "ich brauche neuere Treiber" tatsächlich erfordert.
Was sich in 26.04 für Serverbetreiber ändert
Resolute Raccoon (veröffentlicht am 23. April 2026) ist ein größerer Plattformschritt als eine typische LTS. Die Punkte, die auf Servern zählen:
- Linux 7.0. Eher ein Meilenstein in der Versionsnummerierung als ein architektonischer: Upstream nummerierte nach 6.19 neu durch, sodass 7.0 der normale nächste Kernel ist, keine Neuentwicklung. Was Sie gegenüber der 6.8 von 24.04 tatsächlich bekommen: zwei Jahre zusätzliches Hardware Enablement, Verbesserungen bei io_uring und Networking sowie Arbeiten am Scheduler.
- systemd 259 entfernt cgroup v1 vollständig. Der Release-Upgrader weigert sich, auf Systemen zu laufen, die noch v1 verwenden. Alles Moderne läuft bereits auf v2 (zur Bestätigung
mount | grep cgroup2); die Leidtragenden sind uralte Docker-Engines und alte LXC-Setups; beheben Sie das vor dem Betriebssystem-Upgrade, nicht währenddessen. - OpenSSH 10.2 mit standardmäßigem Post-Quanten-Schlüsselaustausch und vollständig entferntem DSA.
- APT 3.1 mit dem neuen Solver und einer aufgeräumteren CLI.
- Speichersichere Userland:
sudo-rsund die Rust-Coreutils ersetzen standardmäßig ihre C-Vorfahren. Die Kompatibilität ist hoch, aber Skripte, die von obskurem Flag-Verhalten vonsudo/cp/dateabhängen, verdienen einen Testlauf. - Bisher gemeldete Ecken und Kanten: Postfix läuft standardmäßig nicht mehr in einem Chroot (prüfen Sie Ihre Konfiguration beim Upgrade), Mountpunkte für Wechselmedien wanderten von
/medianach/run/media(Skriptbrüche), Kernel 7.0 lässt sehr alte NVIDIA-Treiberreihen fallen, und die Release Notes verzeichnen eine PostgreSQL-Leistungsregression unter bestimmten Konfigurationen. Betreiben Sie eine datenbanklastige Maschine, lesen Sie die aktuellen bekannten Probleme, bevor Sie den Umzug einplanen.
Keiner dieser Punkte ist ein Grund, 26.04 zu meiden; alle sind Gründe, bewusst statt beiläufig zu aktualisieren.
Das ehrliche Argument, (vorerst) bei 24.04 zu bleiben
- Drittanbieter-Repositories hinken hinterher. PPAs und Vendor-Repositories (Datenbanken, PHP, Monitoring-Agenten) veröffentlichen für eine neue LTS nach ihrem eigenen Zeitplan. Wenn
apt updateauf 26.04 eine kritische Abhängigkeit zurücklassen würde, ist das entscheidend. Warten. - Die .1-Regel hat einen Grund. Canonical selbst bietet bestehenden LTS-Nutzern das Upgrade erst ab 26.04.1 an (erwartet im August 2026): Das erste Point-Release fängt die Fixes aus dem Launch-Fenster ab. Produktivflotten verlieren selten etwas, wenn sie dieses Gate respektieren.
- Ihre Uhr tickt nicht. 24.04 wird kostenlos bis 2029 unterstützt. Ein Upgrade Ende 2026 oder im Laufe von 2027 ist eine vollkommen zeitgemäße Haltung.
Die Kehrseite: Neue Maschinen tragen kein Migrationsrisiko, sodass eine frische Bereitstellung von 26.04 heute, wo Ihre Abhängigkeiten es zulassen, den längstmöglichen Support-Zeitraum startet.
Ubuntu Pro und ESM, kurz gefasst
Ubuntu Pro macht aus den fünf Jahren jeder LTS zehn (plus einem "Legacy"-Add-on auf fünfzehn), fügt ESM-Abdeckung für das universe-Repository hinzu, dazu Livepatch (Kernel-Sicherheitsfixes ohne Neustart) und das USG-Hardening-Tooling (CIS/DISA-STIG-Profile). Es ist kostenlos für bis zu fünf Maschinen und kostet darüber hinaus laut Preisliste 500 $/Server/Jahr (Support-SLAs kosten mehr; Preise ändern sich, aktuellen Stand prüfen).
Wann es sich lohnt: für Flotten, die den Upgrade-Rhythmus nicht mitgehen können (Pro macht aus "muss bis 2027 von 22.04 weg" ein "bis 2032"), für Compliance-Regime, die FIPS/CIS-Artefakte wollen, und für alle, deren kritische Pakete in universe liegen. Wann nicht: bei einer gut gepflegten kleinen Flotte, die jeden LTS-Zyklus aktualisiert und größtenteils aus main bezieht. Die kostenlose Stufe deckt ohnehin Ihre ersten fünf Maschinen ab.
In-Place-Upgrade
Der freigegebene Weg ist do-release-upgrade, LTS zu LTS, eine Etappe nach der anderen: 22.04-Maschinen laufen über 24.04. Die Mechanik, kompakt (die ausführlichere Disziplin für Remote-Server ist dieselbe wie in unserem Debian-Upgrade-Leitfaden; die Vorsichtsmaßnahmen lassen sich vollständig übertragen):
apt update && apt full-upgrade # be fully current first
# backups + snapshot; then, inside tmux:
do-release-upgrade # offers 26.04 once 26.04.1 is out
Bevor Sie beginnen: cgroup v2 verifizieren (mount | grep cgroup2), erneut prüfen, dass jedes Drittanbieter-Repository bereits 26.04-Pakete bereitstellt (der Upgrader deaktiviert sie während des Laufs; Sie aktivieren sie danach wieder), und den Out-of-Band-Konsolenzugriff vorab testen. Auf einem Dedicated Server ist KVM-over-IP der Unterschied zwischen "interessantem Zwischenfall" und "Neuprovisionierung". Danach: systemctl --failed, Smoke-Tests der Dienste, und Ihre Repositories wieder aktivieren.
Häufig gestellte Fragen
Ist Ubuntu 26.04 schon stabil genug für den Produktivbetrieb?
Für Neubereitstellungen ja, mit dem üblichen Vorbehalt: Prüfen Sie die aktuelle Liste bekannter Probleme gegen Ihre Workload (die PostgreSQL-Regression ist das naheliegende Beispiel) und bestätigen Sie, dass Ihre Drittanbieter-Repositories bereits 26.04-Pakete veröffentlichen. Für In-Place-Upgrades bestehender Maschinen liefert Canonicals eigenes Gate die Antwort: Der Upgrader bietet LTS-Nutzern 26.04 erst ab 26.04.1 im August 2026 an, und das ist eine sinnvolle Standardeinstellung für Produktivflotten, keine Bürokratie.
Sollte ich jemals interimistische Releases (25.10, 26.10…) auf einem Server betreiben?
Fast nie. Interimsversionen erhalten neun Monate Support, was auf einem Server mehr als eine Betriebssystemmigration pro Jahr bedeutet, nur um gepatcht zu bleiben. Ihr Zweck ist es, einen Vorgeschmack darauf zu geben, was die nächste LTS enthalten wird. Der einzige vertretbare Servereinsatz ist eine kurzlebige Maschine, die Monate vor der nächsten LTS wirklich ein Feature braucht, und selbst dann bringt Sie ein Container oder ein HWE-Kernel auf der aktuellen LTS meist mit weniger Aufwand ans Ziel.
Ich brauche einen neueren Kernel auf 24.04. Muss ich auf 26.04 upgraden?
Meist nicht: Installieren Sie den HWE-Stack (apt install linux-generic-hwe-24.04), der neuere Kernel über die Point-Releases der LTS mitliefert. Das ist die vorgesehene Antwort für "neue Hardware, stabile Userland". Aktualisieren Sie das Betriebssystem, wenn Sie die neue Plattform wollen (systemd, OpenSSL, Sprach-Stacks), nicht nur den Kernel.
Ubuntu oder doch etwas ganz anderes?
Wenn Sie Distributionen statt Versionen abwägen, ist das ein anderer Artikel: Ubuntu vs Debian behandelt die naheliegendste Alternative, und wie Sie die richtige Linux-Distribution wählen deckt das gesamte Feld ab, einschließlich der RHEL-Familie. Die Kurzfassung: Ubuntus LTS-Rhythmus und Pro-Fenster sind seine Unterscheidungsmerkmale; wenn Ihnen das nicht wichtig ist, öffnet sich das Feld.
Bereitstellung auf Serverside
Wir spielen auf Ubuntu Dedicated Servern die von Ihnen gewählte unterstützte LTS-Version in unter einer Minute auf, in unserem ASN-55285-Netzwerk mit dauerhaft aktiver DDoS-Mitigation und einer Self-Service-Edge-Firewall. KVM-over-IP ist Standard, genau das Out-of-Band-Sicherheitsnetz, von dem der Abschnitt zum In-Place-Upgrade ausgeht, und wenn Sie lieber sauber mit 26.04 neu beginnen, statt in-place zu aktualisieren, macht die Neuprovisionierung in unter einer Minute aus Neuinstallation-plus-Wiederherstellung eine echte Strategie statt eines letzten Auswegs.
Nach der Bereitstellung: die Hardening-Checkliste für die erste Stunde und sinnvolle Standard-Firewall-Regeln.

Geschrieben von
Co-founder & CTO, Serverside.com
Jesse is the co-founder and CTO of Serverside.com, where he leads the engineering behind the company's bare-metal cloud: from the ASN 55285 backbone to the core automation that drives day-to-day operation. He writes about dedicated servers, operating systems, and running production workloads on bare metal.
Weiterlesen
Alle Artikel ansehenHat der Artikel weitergeholfen?
Neue Guides und Engineering-Artikel direkt ins Postfach. Kein Spam, jederzeit abbestellbar.




kanadisch und
niederländisch