Supportende im Unterbau: Betriebssystem und Datenbank

Wenn von Shop-Updates die Rede ist, sind meist drei Dinge gemeint: der Kern des Shopsystems, die Erweiterungen und das Theme. Darunter liegt eine zweite Kette, die im Wartungsalltag seltener auftaucht, obwohl alles auf ihr steht. Ganz unten die Linux-Distribution mit Kernel, Systembibliotheken und Paketverwaltung. Darauf der Datenbankserver, meist MariaDB oder MySQL, der Bestellungen, Kundenkonten, Artikel und Sitzungen hält. Daneben die PHP-Laufzeit, aus der jede Seite erzeugt wird, und der Webserver, der Anfragen annimmt und an PHP weiterreicht. Jede dieser Schichten hat einen eigenen Hersteller, einen eigenen Veröffentlichungstakt und ein eigenes Enddatum.

Das Tückische an dieser Kette ist, dass ihre Fristen im Shop nicht sichtbar werden. Das Backend eines Shopsystems zeigt die eigene Version und meldet verfügbare Updates für Kern und Erweiterungen. Ob die Distribution darunter noch gepflegt wird, erfährt es nicht. Der Datenbankserver beantwortet Abfragen nach seinem Enddatum genauso schnell wie davor. Der Unterschied liegt allein darin, dass für neu entdeckte Lücken keine Korrektur mehr erscheint - und das bemerkt man erst, wenn eine solche Lücke ausgenutzt wird.

Wie weit Lauffähigkeit und Pflege auseinanderliegen können, zeigt die Anforderungsseite von WordPress. Empfohlen werden dort PHP ab 8.3 (WordPress.org) sowie MariaDB ab 10.11 oder MySQL ab 8.0 (WordPress.org). Zugleich hält dieselbe Seite fest, dass WordPress in älteren Umgebungen auch mit PHP 7.4 und MySQL 5.5.5 (WordPress.org) noch läuft - mit dem ausdrücklichen Hinweis, dass diese Versionen ihr offizielles Lebensende erreicht haben und die Website Sicherheitslücken aussetzen können. Ein Shop auf solcher Grundlage funktioniert. Er ist nur nicht mehr gepflegt. Für die WordPress-Wartung mit Blick auf den Server heißt das: Die Prüfung endet nicht bei Kern und Plugins.

Debian 12 hat seine reguläre Pflege am 11. Juli 2026 (Debian) abgeschlossen und läuft seitdem in der Langzeitpflege, die am 30. Juni 2028 (Debian) endet. Debian 13 ist am 9. August 2025 (Debian) erschienen, seine LTS-Phase reicht bis zum 30. Juni 2030 (Debian). Wer im Herbst 2026 von Debian 11 aus springt, hat damit zwei Ziele mit sehr unterschiedlicher Restlaufzeit: Der Sprung auf Debian 12 bringt knapp zwei Jahre, der Sprung auf Debian 13 knapp vier. Der Aufwand unterscheidet sich weniger als die Laufzeit, denn beide Ziele verlangen einen Probelauf mit neuer PHP-Version.

Für Server auf Ubuntu gilt dieselbe Logik mit anderem Kalender. Ubuntu 22.04 LTS erhält Standard-Sicherheitspflege bis Mai 2027 (Canonical), die erweiterte Sicherheitspflege reicht bis Mai 2032 (Canonical) und läuft über das Abonnement Ubuntu Pro (Canonical). Ubuntu 24.04 LTS ist bis Mai 2029 (Canonical) in der Standardpflege, Ubuntu 26.04 LTS ist im April 2026 erschienen und bis Mai 2031 (Canonical) gepflegt. Die erweiterte Pflege ist ein eigener Baustein, der gebucht und auf jedem Server aktiviert sein muss. Ein Server, auf dem sie nur geplant, aber nicht eingerichtet ist, bekommt nach Mai 2027 keine Sicherheitskorrekturen aus der Standardpflege mehr.

Bei MariaDB steht die nächste große Frist für 10.11 an: Die Community-Pflege endet am 16. Februar 2028 (MariaDB Foundation). Das ist die Version, die Debian 12 mitbringt und die WordPress als Mindestempfehlung nennt. Sie betrifft also jeden Server, auf dem Debian 12 mit der Datenbank aus der Distribution läuft.

Nach Version 11.4 hat die MariaDB Foundation ihre Regel geändert. Bis einschließlich 11.4 gab es Binärpakete fünf Jahre lang (MariaDB Foundation). Für spätere Langzeitversionen stellt sie Community-Binärpakete nur noch drei Jahre (MariaDB Foundation) nach der allgemeinen Verfügbarkeit bereit und liefert Korrekturen für kritische und sicherheitsrelevante Fehler danach noch zwei weitere Jahre (MariaDB Foundation) als Quellcode. Die Folge steht in derselben Tabelle: MariaDB 11.8 ist neuer als 11.4, erhält aber nur bis zum 4. Juni 2028 (MariaDB Foundation) Community-Binärpakete, 11.4 dagegen bis zum 29. Mai 2029 (MariaDB Foundation). Die jüngste Version in der Tabelle, 12.3, ist im Mai 2026 erschienen und wird als Community-Version bis zum 12. Juni 2029 (MariaDB Foundation) gepflegt - kaum länger als 11.4.

Aus dem Inventar wird ein Kalender. Jede Zeile trägt eine Komponente, ihre Version, das Enddatum mit Quelle und das Datum, an dem die Vorbereitung beginnen muss. Dieser zweite Termin ist der eigentlich wichtige. Ein Versionssprung im Unterbau braucht einen Probelauf, einen freigegebenen Termin, ein Wartungsfenster außerhalb der umsatzstarken Zeiten und Luft für einen zweiten Anlauf, falls der erste abgebrochen wird. Wer erst am Enddatum anfängt, arbeitet schon im ungepflegten Zustand.

Wie viel Vorlauf nötig ist, hängt am Umfang. Ein Sprung der Datenbank auf einem ansonsten unveränderten Server lässt sich in der Regel in einem Fenster erledigen. Ein Sprung des Betriebssystems mit neuer PHP-Version und geänderten Voreinstellungen im Webserver braucht meist mehrere Probeläufe. Für Shops mit Saisongeschäft kommt ein Änderungsstopp hinzu: Fällt ein Enddatum in den Spätherbst, gehört der Sprung vor das Weihnachtsgeschäft, nicht dahinter.

Der Kalender ist nur so gut wie seine Pflege. Herstellerfristen können verschoben oder präzisiert werden, und die MariaDB Foundation hat mit ihren Versionen nach 11.4 gezeigt, dass sich sogar die Regel ändern kann, nach der Fristen entstehen. Jede Zeile gehört darum regelmäßig gegen die Quelle geprüft, mindestens einmal im Quartal. Unter Sicherheitsupdates als laufende Leistung überwachen wir die eingesetzten Komponenten bis hinunter zu Betriebssystem, Webserver und PHP-Version. Ein solcher Kalender lässt sich dort einbinden, sodass Vorläufe gemeldet und Sprünge terminiert werden, bevor die Pflege endet.

Jeder dieser Sprünge wird zuerst auf einer Kopie gemacht. Die Kopie muss dem Produktivserver in den Punkten gleichen, auf die es ankommt: dieselbe Distribution, dieselbe Datenbankversion, dieselben PHP-Module, ein aktueller Datenstand. Eine Staging-Umgebung, die seit einem Jahr niemand angefasst hat, prüft den Sprung von einem Stand aus, den es in der Produktion nicht mehr gibt. Wie eine solche Umgebung aufgebaut und aktuell gehalten wird, beschreibt unser Beitrag zur Staging-Umgebung für sichere Updates.

Der Probelauf folgt einem Drehbuch, das später in der Produktion Schritt für Schritt wiederholt wird. Dazu gehören die Befehle in ihrer Reihenfolge, die Dauer jedes Schritts und die Prüfungen danach: Startseite, Kategorie, Artikel, Suche, Warenkorb, Checkout mit Testzahlung, Kundenkonto, Backend, Export an die Warenwirtschaft und geplante Aufgaben. Gemessen wird auch die Gesamtdauer, denn sie bestimmt die Länge des Wartungsfensters ohne Umsatzausfall.

Ein Sonderfall ist der Neuaufbau. Statt den bestehenden Server Version für Version anzuheben, wird ein neuer Server mit dem Zielstand eingerichtet, der Shop dorthin übertragen und der alte Server als Rückweg stehen gelassen, bis der neue sich im Betrieb bewährt hat. Das kostet mehr Vorbereitung und einen Umzug der Daten, dafür bleibt der Ausgangszustand vollständig erhalten. Bei Sprüngen über zwei Distributionsversionen hinweg ist das oft der ruhigere Weg. Was geschieht, wenn ein Update trotz Probelauf scheitert, beantwortet unsere FAQ was bei einem fehlgeschlagenen Update passiert.

Die Rechnung für einen verschobenen Sprung sieht zunächst günstig aus: kein Probelauf, kein Wartungsfenster, keine Projektzeit. Sie kippt, sobald eine Lücke in einer Komponente bekannt wird, für die keine Korrektur mehr erscheint. Das Ausnutzen von Schwachstellen ist inzwischen der häufigste Erstzugang und liegt bei 31 % (Verizon) der ausgewerteten Vorfälle mit ermitteltem Erstzugang, vor dem Missbrauch von Zugangsdaten. Und selbst dort, wo Korrekturen vorliegen, dauert die vollständige Behebung kritischer Schwachstellen im Median 43 Tage (Verizon).

Die Gegenseite ist schneller. Zwischen der Aufnahme einer Schwachstelle in den Katalog aktiv ausgenutzter Lücken und ihrer massenhaften Ausnutzung liegen im Median fünf Tage (Verizon, Bericht 2025). Ein Server ohne Pflege nimmt an diesem Rennen gar nicht mehr teil: Für ihn kommt keine Korrektur, egal wie lange man wartet. Laufendes Monitoring des Shops meldet Ausfälle und Auffälligkeiten, ersetzt aber nicht den Kalender - ein Enddatum löst keinen Alarm aus.

Dazu kommt ein Effekt, der sich erst beim Nachholen zeigt. Je länger ein Server steht, desto größer wird der Sprung: Aus einem Wechsel von Debian 11 auf 12 wird einer über zwei Versionen, aus einem PHP-Wechsel um eine Nebenversion einer über mehrere. Jeder zusätzliche Schritt vergrößert die Zahl der Stellen, an denen Erweiterungen, Konfiguration oder Datenbankabfragen brechen können. Der aufgeschobene Sprung wird also nicht billiger, sondern teurer - und er fällt dann oft in einen Zeitraum, den niemand dafür vorgesehen hat.