Updates ohne Risiko: Was hinter dem monatlichen maxcluster Update-Tag steckt

Unternehmen, die ihre Systeme nicht regelmäßig aktualisieren, spielen ein Spiel mit stetig wachsendem Einsatz. Laut dem BSI-Lagebericht 2025 stieg die Zahl der täglich neu registrierten Schwachstellen zwischen Juli 2024 und Juni 2025 um 24 Prozent. Zur gleichen Zeit stuften Sicherheitsforscher von Outpost24 bei einer Analyse öffentlich erreichbarer Systeme 18 Prozent der untersuchten Assets als hoch oder kritisch gefährdet ein – häufig, weil Patches schlicht ausgeblieben waren.

Noch konkreter: 76 Prozent aller Cyberangriffe im Jahr 2024 begannen laut einer Analyse von Netzpalaver an einem ungeschützten oder vergessenen externen Asset. Systeme, die nicht aktuell gehalten werden, werden nicht einfach nur langsam – sie werden zum Einfallstor. (Quelle: netzpalaver.de)

Für Onlineshops ist das kein abstraktes Risiko. Ein kompromittierter Server bedeutet im schlimmsten Fall: Datenverlust, DSGVO-Meldepflicht, Reputationsschaden – und einen Shop, der offline ist, genau dann, wenn Kunden kaufen wollen. Einen umfassenden Überblick über IT-Sicherheit im E-Commerce – von Angriffsvektoren bis zu Schutzmaßnahmen – bietet unser E-Book: IT-Sicherheit im E-Commerce.

Regelmäßige Updates schützen vor vier zentralen Risiken:

• Sicherheit: Kritische Schwachstellen (CVEs) werden geschlossen, bevor Angreifer sie ausnutzen können.
• Stabilität: Fehler in Paketen, Speicherverwaltung und Kernelmodulen werden behoben – bevor sie sich als Ausfall bemerkbar machen.
• Kompatibilität: Abhängigkeiten bleiben sauber gepflegt, Softwarestände konsistent.
• Compliance: Definierte Update-Prozesse helfen, interne IT-Standards und Datenschutzvorgaben zu erfüllen.
   

Hinter dem Update-Tag steckt mehr als ein automatisches Skript. Ein Team aus vier erfahrenen Linux-Administratoren plant jeden Zyklus im Vorfeld: offene Tickets werden besprochen, Risiken bewertet, Zuständigkeiten verteilt. Transparenz intern ist Voraussetzung dafür, dass draußen nichts schiefgeht.

Der Rollout selbst folgt einem Zwei-Phasen-Modell.

Phase 1: Die Stage-Cluster gehen zuerst

Eine Woche vor dem eigentlichen Live-Update-Tag – also am letzten Dienstag des Vormonats – werden mehr als 700 Stage-Cluster aktualisiert. Warum zuerst die Stage-Systeme? Weil sie den perfekten Testrahmen bieten: reale Infrastruktur, reale Konfiguration, aber kein laufendes Geschäft, das davon abhängt.

In dieser Woche lässt sich in Ruhe beobachten, ob ein Paket-Update sich anders als erwartet verhält. Inkompatibilitäten fallen auf, bevor sie auf einem Live-Shop landen. Und Du als Kunde hast Zeit, Deine Anwendung auf dem Stage-System zu testen – und bei Bedarf zu reagieren.

Mögliche Reaktionen:

• Einen Bug in Deiner Anwendung fixen, der durch das neue Paket sichtbar wird.
• Bei Bedarf den Support kontaktieren, um das Update deines Live-Clusters zu verschieben.

Software-Freeze: Zwischen Stage- und Live-Update-Tag gilt ein Software-Freeze. Stage- und Live-Cluster laufen auf demselben Softwarestand – nur so ist ein valider Vergleich zwischen den Umgebungen möglich.

Phase 2: Die Live-Cluster – kontrolliert und gestaffelt

Am ersten Dienstag des Monats, zwischen 6:00 und 9:00 Uhr, laufen die Updates auf den über 2.500 Live-Clustern. Der Rollout beginnt gestaffelt – nicht alle Systeme gleichzeitig, sondern mit zeitlichem Versatz, um die Infrastruktur nicht zu überlasten.

Während dieser Phase läuft ein zentrales Monitoring-Dashboard. Das Admin-Team sieht in Echtzeit, ob Dienste stabil laufen, Fehler auftreten oder Eingriffe nötig sind. Updates laufen automatisch – die Kontrolle bleibt manuell.

Feiertag in NRW? Fällt der erste Dienstag auf einen gesetzlichen Feiertag in Nordrhein-Westfalen, verschiebt sich der Update-Tag auf den zweiten Dienstag des Monats.

Der Zyklus im Überblick

Beim Update-Tag werden alle Ubuntu-Pakete auf dem Cluster aktualisiert, für die neue Versionen verfügbar sind. Das bedeutet: die gesamte Tool-Chain des Betriebssystems – von grundlegenden Systembefehlen über PHP bis hin zu Datenbankdiensten und Webservern.
Was nicht aktualisiert wird: alle Anwendungen, die Du oder Deine Agentur selbst installiert und verwaltet. Dazu gehören:

• Shopware, Magento und andere Shop-Systeme
• WordPress, TYPO3 und andere CMS
• PM2-Applikationen und benutzerdefinierte Dienste

Klare Grenze: maxcluster aktualisiert die Infrastruktur – Deine Anwendung bleibt in Deiner Hand. Wir fassen sie nicht an.

Keine Überraschungen: Warum wir nur abwärtskompatibel updaten

Damit Updates keine unerwarteten Brüche verursachen, folgt maxcluster konsequent der semantischen Versionierung. Das bedeutet: Wir aktualisieren nur innerhalb derselben Major- und Minor-Version – also ausschließlich Patch-Updates, die abwärtskompatibel sind.

Ein Beispiel: MySQL 8.0.1 wird auf MySQL 8.0.2 aktualisiert – nicht auf 8.4.1. Der Unterschied: Patch-Updates (die dritte Stelle) sind sicher. Sprünge in der zweiten oder ersten Stelle können Inkompatibilitäten mitbringen.

Sollte sich trotzdem einmal eine Major- oder Minor-Versionsnummer ändern, informieren wir Dich vorab – mit ausreichend Zeit, Deine Anwendung vorzubereiten.

Was passiert, wenn doch etwas schiefläuft?

In aller Regel verlaufen die Updates problemlos. Ubuntu zeichnet sich durch gepflegte Paketqualität und stabile Abhängigkeiten aus. Gelegentlich kommt es trotzdem zu Sonderfällen: Ein Dienst startet nicht neu, eine Konfigurationsdatei muss angepasst werden, ein Service braucht einen manuellen Eingriff. Das sind Ausnahmen – und sie werden in der Regel noch am gleichen Tag behoben.

Für den ernsteren Fall gibt es einen klaren Eskalationsplan:

• Das Monitoring-Team erkennt Probleme in Echtzeit über das Dashboard.
• Innerhalb von ein bis fünf Minuten kann auf den passiven Server umgeschaltet werden.
• Der passive Server hält den Datenbestand von 6:00 Uhr – kein Backup muss eingespielt werden.
• Der Rollback ist minimal, schnell und ohne großen Datenverlust möglich.

Backup-Strategie und Update-Prozess ergänzen sich: Wer beides im Griff hat, ist auch im Ernstfall handlungsfähig. Wie eine solide Datensicherung für Deinen Shop aussehen sollte, erklärt unser Artikel Backups im E-Commerce.

Bei kritischen Sicherheitslücken – Heartbleed, Ghost, ShellShock und ähnliche – reagieren wir außerhalb des regulären Zyklus, unverzüglich nach unserer Analyse. In solchen Fällen kommt es vor, dass Dienste außerplanmäßig neu gestartet werden müssen.

Was Du am Update-Tag konkret erwarten kannst

Für die meisten Shopbetreiber läuft der Update-Tag ruhig ab. Trotzdem gibt es einige Punkte, die Du kennen solltest:

• Kurze Dienstneustarts sind möglich. Pakete wie php-fpm, MySQL, Apache oder NGINX benötigen nach einem Update einen Neustart. In dieser kurzen Phase sind einzelne Dienste nicht erreichbar. Das Zeitfenster ist in der Regel sehr kurz – aber es ist da.
• Teste nach dem Update-Tag. Auch wenn wir mit keinen Inkompatibilitäten rechnen: Ein kurzer Funktionstest deines Shops nach dem Update-Tag ist eine gute Angewohnheit. Im Managed Center findest du unter Zugriff & Verwaltung → Paket Updates eine vollständige Liste aller eingespielten Pakete, nach Datum sortiert.
• Was tun, wenn doch eine Inkompatibilität auftritt? In seltenen Ausnahmefällen ist es möglich, einzelne Pakete auf die Vorversion zurückzusetzen – als kurzfristige Notlösung. Wichtig zu wissen: Ein Downgrade schließt das betreffende Paket langfristig von weiteren Updates aus und vergrößert damit genau die Sicherheitslücke, die man schließen wollte. Die sauberere Lösung ist daher immer, die eigene Anwendung an den neuen Paketstand anzupassen.
• Kritische Sicherheitslücken: Bei schwerwiegenden Schwachstellen wie Heartbleed, Ghost oder ShellShock warten wir nicht bis zum nächsten Update-Tag. Wir reagieren unverzüglich nach unserer Analyse – auch außerhalb des regulären Zyklus. In solchen Fällen können Dienste zu unplanmäßigen Zeiten neu gestartet werden. Wir informieren Dich in diesen Fällen proaktiv.

Mehr Details zum Ablauf und zu den möglichen Risiken findest Du in unserer Knowledge Base zum Update-Tag.