Seit gestern befindet sich Debian 12 Bookworm im Long Term Support. Das klingt zunächst beruhigend, ist es aber nicht, wenn man die Konsequenzen für Proxmox-Infrastrukturen durchdenkt.
Was LTS konkret bedeutet
Debian unterscheidet zwischen regulärem Support durch das Debian Security Team und dem anschließenden LTS-Zeitraum, der von einem separaten Freiwilligenteam betreut wird. Der Unterschied ist gravierend:
Das Debian Security Team hat gestern die aktive Pflege von Debian 12 abgegeben. Ab sofort übernimmt das Debian LTS Team - allerdings in einem deutlich kleineren Umfang. Konkret heißt das:
- Sicherheits-Patches erscheinen mit geringerer Frequenz und Priorität.
- Nicht alle Pakete erhalten weiterhin Updates. Das LTS-Team pflegt nur einen definierten Paketumfang.
- Architekturen wie armel, armhf, i386 und s390x fallen aus dem LTS-Unterstützungsbereich heraus. Für Server-Infrastrukturen, die ausschließlich auf amd64 laufen, ist das weniger relevant, aber es zeigt den allgemeinen Trend.
- Der Zeitraum bis zum endgültigen End of Life ist begrenzt: LTS-Support für Debian 12 Bookworm läuft bis 30. Juni 2028.
Für eine Betriebssystem-Basis, auf der produktionskritische Hypervisoren laufen, ist das ein relevanter Statuswechsel.
Die Proxmox-Abhängigkeiten im Überblick
Proxmox orientiert seinen Support-Zyklus eng an Debian. Die Regel lautet: Eine Proxmox-Version wird mindestens so lang unterstützt wie die zugrunde liegende Debian-Version durch das Debian Security Team über den regulären, jedoch nicht den LTS-Zeitraum unterstützt wird.
Das hat direkte Konsequenzen für drei Produkte, die alle auf Debian 12 aufsetzen:
Proxmox VE 8
Proxmox Virtual Environment 8 ist seit Juni 2023 verfügbar und nutzt Debian 12 Bookworm als Basis. Das offizielle End of Life ist der 31. August 2026 und damit in knapp drei Monaten.
Die aktuelle Version 8.4 erhält bis dahin noch Sicherheits-Patches. Danach entfällt jeglicher Support durch Proxmox.
Wer heute noch PVE 8.x betreibt, fährt ab September 2026 ohne Sicherheitsupdates und ohne Support-Anspruch. Auf Infrastruktur, die möglicherweise Hunderte virtueller Maschinen trägt, kann das zu einem steigenden Risiko werden.
Proxmox Backup Server 3
PBS 3 folgt demselben Debian-Zyklus. Auch hier läuft der Support parallel zu Proxmox VE 8 aus. PBS ist oft das stille Rückgrat von Backup-Strategien: Wer vergisst, PBS zu aktualisieren, riskiert eine Backup-Infrastruktur ohne Sicherheitsupdates.
Proxmox Mail Gateway 8.x
PMG 8.x ist ebenfalls auf Debian 12 Bookworm aufgebaut. Auch hier gilt: Mit dem Debian-12-EOL läuft der reguläre Herstellersupport von Proxmox aus. PMG sitzt per Definition im Netzwerk-Perimeter und verarbeitet eingehende E-Mails. Eine veraltete Basis an dieser Stelle ist ein konkretes Risiko.
Was der Nachfolger bringt
Proxmox hat den Wechsel bereits vor einiger Zeit vollzogen: Alle drei Produkte sind in neueren Versionen erschienen, jeweils auf Basis von Debian 13 Trixie.
- Proxmox VE 9.0 wurde am 5. August 2025 veröffentlicht. Mit Linux-Kernel 6.14, verbesserter Hardware-Unterstützung und direktem In-place-Upgrade-Pfad von PVE 8.
- Proxmox Backup Server 4.x bringt die aktuelle Backup-Infrastruktur auf Debian 13.
- Proxmox Mail Gateway 9.0 basiert ebenfalls auf Debian Trixie, mit nahtlosem Upgrade-Pfad von PMG 8.
Der Upgrade-Pfad existiert, ist dokumentiert und wird von Proxmox offiziell unterstützt.
Warum trotzdem viele zu spät reagieren
In mittleren und großen IT-Umgebungen, in der öffentlichen Verwaltung und Bildungseinrichtungen, sind Wartungsfenster selten und Change-Management-Prozesse langwierig. Ein Proxmox-Cluster mit 20 Nodes, 2000 VMs, produktivem Ceph Storage und stündlichen Backup-Jobs lässt sich nicht gut zwischen zwei Meetings upgraden.
Dazu kommt: Wer Proxmox VE, PBS und PMG parallel betreibt, sollte die Upgrades koordinieren, um Abhängigkeiten zu meistern. So ist im ungünstigsten Fall ein Upgrade von Ceph 17.2 auf 19.2 notwendig, bevor das Proxmox VE 8 auf 9 Upgrade durchgeführt werden kann. Wer das nicht auf dem Schirm hat, riskiert eine holprige Migration.
Folgende Szenarien haben wir in der Praxis häufig gesehen:
Szenario 1 - Upgrade vergessen: PVE 8 läuft noch auf Debian 12, eine CVE mit Score >= 7 erscheint im Oktober 2026. Kein Patch verfügbar, weil out of support.
Szenario 2 - PBS vergessen: PVE wurde auf Version 9 gehoben, der Backup Server läuft noch auf PBS 3. Die Kompatibilität ist auf's Erste gegeben, aber sobald PBS 3 keine Updates mehr erhält, ist das Backup-Fenster zur Schwachstelle geworden und neue Features sind ebenfalls nicht nutzbar.
Szenario 3 - Compliance-Problem: Viele Unternehmen und Behörden sind verpflichtet, ausschließlich Software im Support-Zeitraum zu betreiben, sei es aus Versicherungsgründen, wegen DSGVO-Anforderungen oder internen Security-Policies. Ein Proxmox-Stack ohne aktiven Herstellersupport kann einen Compliance-Verstoß auslösen.
Szenario 4 - Abhängigkeiten nicht im Blick: Betreibt man Proxmox VE hyperconverged im HCI-Stack mit Ceph, hantiert man mit unterschiedlichen Support-Zyklen. Die erste Proxmox 8.0 kam mit Ceph Quincy 17.2 raus, für Proxmox VE 9.0 ist dagegen Ceph Squid 19.2 die erste unterstützte Version. Dazwischen liegen die Upgrades von Ceph Qunicy 17.2 auf Ceph Reef 18.2 sowie das Upgrade von Ceph Reef 18.2 auf Ceph Squid 19.2 als letzte unterstützte Version für Proxmox VE 8.4. Erst Squid wird sowohl von PVE 8 wie auch von PVE 9 unterstützt und ist daher für die Migration als Grundlage notwendig.
Was jetzt zu tun ist
Die folgenden Schritte sind keine theoretischen Empfehlungen, sondern der tatsächliche Migrationspfad, den wir bei Kunden umsetzen:
1. Bestandsaufnahme durchführen
Welche Proxmox-Versionen laufen wo? pveversion -v liefert auf einem Proxmox VE Server den aktuellen Stand. Welche VMs sind kritisch? Gibt es besondere Abhängigkeiten oder Wartungsfenster zu beachten?
2. Upgrade-Pfad pro Produkt klären
PVE 8 auf 9: Proxmox stellt eine offizielle Upgrade-Anleitung unter https://pve.proxmox.com/wiki/U... bereit. Vor dem Start lässt sich mit dem Script pve8to9 prüfen, ob es bestimmte Konstellationen gibt, die ein Upgrade stören könnten. PBS 3 auf 4: Analog, mit Backup-Verifikation vor dem Upgrade. Und auch für PMG 8.2 auf 9 steht ebenso eine ausführliche Anleitung im Proxmox PMG Wiki bereit.
3. Testumgebung aufsetzen
Wer kritische Infrastruktur betreibt, sollte das Upgrade zuerst in einem Testsystem validieren, besonders wenn Drittanbieter-Plugins, Custom-Scripts oder non-standard Konfigurationen im Einsatz sind.
4. Wartungsfenster planen
Ein Node-Upgrade dauert je nach Hardware und VM-Last zwischen 30 und 90 Minuten. Bei einem Cluster mit Rolling Upgrades, also ein Node nach dem anderen, VMs dazwischen migrieren, ist der Betrieb unterbrechungsfrei möglich, aber er muss geplant werden.
5. Upgrade bis Ende Juli 2026 abschließen
Der 31. August 2026 ist die Deadline für PVE 8, PBS 3 und PMG 8. Wer den Upgrade-Prozess jetzt startet, hat sechs Wochen Puffer für Tests, Abstimmung und unvorhergesehene Probleme.
Unterstützung durch inett
inett begleitet Kunden durch genau diese Upgrade-Zyklen - von der Bestandsaufnahme über die Planung bis zur Durchführung. Wir kennen die typischen Stolperstellen, weil wir solche Upgrades in unterschiedlichen Umgebungen jede Woche durchführen. Ceph-Pools mit non-default Pool-Einstellungen, SDN-Konfigurationen, die nach dem Upgrade manuell angepasst werden müssen, oder PBS-Datastores, die nach einem Kernel-Upgrade geprüft werden sollen.
Wenn Sie Unterstützung bei der Migration benötigen oder wissen möchten, ob Ihre Proxmox-Infrastruktur betroffen ist: Sprechen Sie uns an.
Solche Informationen direkt ins Postfach
Debian-Lifecycle-Daten, Proxmox-EOL-Fristen, kritische CVEs für Linux-basierte Infrastruktur - wir fassen zusammen, was für Administratoren und IT-Manager relevant ist, ohne Werbe-Newsletter-Füllmaterial.
Tragen Sie sich in unsere Mailingliste ein und erhalten Sie solche Hinweise rechtzeitig bevor die Frist drei Monate entfernt ist: inett.de/newsletter