Wartungsfenster und der Weg zurück

Automatische Sicherheitsupdates decken das Distributionsarchiv ab. Alles andere, Anwendungen, Container-Images, Datenbanken, Hauptversionen, braucht einen bewussten Ablauf. Und zwar einen, dessen wichtigster Teil vor dem eigentlichen Update steht.

Der Ablauf#

Vorher (der Teil, der zählt)#

# 1. Wo stehen wir? Diese Ausgabe ist der Rückweg.
dpkg -l > /root/paketstand-$(date +%F).txt
docker compose config --images > /root/images-$(date +%F).txt

# 2. Datenbestand sichern, außerhalb der Maschine
docker compose exec -T db pg_dump -U app app | zstd -9 > /var/backups/app-vor-update.sql.zst
restic backup /var/backups/app-vor-update.sql.zst --tag vor-update

# 3. Snapshot, falls die Plattform es kann
# (Proxmox, Anbieter-Panel, ZFS)

Punkt 2 ist nicht optional. Ein Zurücksetzen des Images ist einfach; ein Zurücksetzen einer Datenbankmigration ist es nicht. Viele Anwendungen migrieren beim Start automatisch und ohne Nachfrage, danach kann die alte Programmversion mit dem neuen Schema nichts mehr anfangen.

Während#

# Images holen, ohne zu starten — trennt Netzwerkprobleme vom Update
docker compose pull

# Umschalten
docker compose up -d

# Hinsehen. Nicht wegklicken.
docker compose ps
docker compose logs -f --tail=100 app

Zwischen pull und up gehört ein Blick ins Änderungsprotokoll des Projekts. Die drei Punkte, auf die es ankommt:

1. Migrationen, ändert sich das Schema, ist der Schritt umkehrbar?
2. Entfernte Konfiguration, sind Umgebungsvariablen weggefallen oder umbenannt?
3. Übersprungene Versionen, verlangt das Projekt, von 15 über 16 nach 17 zu gehen? Bei Datenbanken ist das der Regelfall.

Danach#

# Antwortet der Dienst wirklich, nicht nur der Prozess?
curl -fsS -o /dev/null -w '%{http_code}\n' https://app.example/healthz

# Läuft etwas in eine Neustartschleife?
docker compose ps --format 'table {{.Service}}\t{{.Status}}'

# Fehler seit dem Umschalten
docker compose logs --since 15m | grep -iE 'error|fatal|panic' | head -20

Und: den Zustand notieren, bevor man Feierabend macht. Der Satz „lief sauber durch, Version 1.9.0, 21:40“ ist in vier Wochen mehr wert, als man beim Schreiben denkt.

Der Rückweg#

# Image zurücksetzen: Tag in der compose.yaml auf die alte Version
docker compose up -d

# Falls migriert wurde: Dump zurückspielen
zstd -d < /var/backups/app-vor-update.sql.zst | docker compose exec -T db psql -U app app

Dringende Patches außerhalb des Fensters#

Wenn eine Lücke im KEV-Katalog steht und die Software erreichbar ist, wartet man nicht auf Donnerstagabend. Der verkürzte Ablauf:

1. Gegenmaßnahme aus dem Bulletin zuerst. Modul abschalten, Pfad sperren, Port schließen, das schließt das Fenster in Minuten, während der Patch noch geprüft wird.
2. Nur die betroffene Komponente patchen, nicht gleich alles mitnehmen. Ein kleiner Änderungsumfang ist ein kleiner Fehlerraum.
3. Dump trotzdem. Auch bei Eile. Er dauert Sekunden bis Minuten.
4. Danach ins reguläre Fenster nacharbeiten, was liegen geblieben ist.

Die Frage, ob es überhaupt dringend ist, beantworten CVSS richtig lesen und Betroffenheit prüfen.

Ein Rhythmus, der hält#

Der wöchentliche Termin macht den Unterschied. Wer alle sechs Monate aktualisiert, hat kein Update mehr vor sich, sondern eine Migration und die ist genau der Grund, warum das nächste Update wieder aufgeschoben wird.

Wenn andere betroffen sind#

Ein Wartungsfenster, von dem niemand weiß, ist ein Ausfall. Drei Zeilen genügen: was, wann, wie lange voraussichtlich. Und danach eine Meldung, wenn es durch ist, auch das gehört dazu, sonst fragt jemand nach.