Rollback-Strategie

Beim Change Management ist der Backout-Plan Pflicht. Beim Patch-Management bedeutet das: vor jedem Patch muss klar sein, wie du den Stand zurückrollst, falls etwas schiefgeht. Die Rollback-Strategie beschreibt das systematisch: welche Technik, welche Zeitspanne, welche Daten gehen verloren, wer entscheidet. Es gibt mehrere Rollback-Mechanismen, die je nach Systemtyp passen: Snapshot bei VMs (schnell, sauber), Backup-Restore bei physischen Systemen oder DB-Servern (langsamer), Package-Downgrade bei Linux (gezielt, aber Daten bleiben), Reimage als Holzhammer. Die zweite wichtige Frage: Soll überhaupt zurückgerollt werden? – nicht jeder Hänger rechtfertigt einen Rollback, der seinerseits Risiken birgt. Diese Lektion zeigt dir die wichtigsten Rollback-Typen mit Vor- und Nachteilen, einen Entscheidungs-Pfad für die Frage „rollback oder weitermachen?" und die Stolperfallen.

1) Was Rollback bedeutet

Ein Rollback bringt ein System auf einen früheren Zustand zurück – meist auf den Stand vor einem fehlgeschlagenen Patch. Begriffe, die manchmal vermischt werden:

2) Die vier Hauptarten von Rollback

Klick die Tabs, um die Mechanismen mit Vor- und Nachteilen zu vergleichen:

3) Entscheidung: Rollback ja oder nein?

Vorsicht – ein Rollback ist nicht immer die richtige Antwort. Manche Probleme lassen sich schneller mit einem weiteren Patch (Hotfix oben drauf) lösen. Hier ein Entscheidungs-Pfad – beantworte die Fragen ehrlich:

4) Backout-Plan im RFC

Bei jedem RFC ist der Backout-Plan Pflichtfeld. Was muss drinstehen?

• Konkretes Vorgehen, nicht „wir restoren halt das Backup". Befehl-Sequenz, Wiederherstellungspunkt, getestetes Verfahren.
• Verantwortliche Person. Wer entscheidet das Rollback? Wer führt es durch?
• Zeitschranke. Wann wird die Entscheidung getroffen? „Spätestens 1 h nach Patch-Beginn, wenn Smoke-Test fehlschlägt."
• Kommunikations-Plan. Wer wird über das Rollback informiert? Welche User?
• Datenverlust-Akzeptanz. Welche Daten gehen beim Rollback verloren? Wer akzeptiert das?
• Validierung nach Rollback. Wie wird geprüft, dass das System wieder im funktionierenden Vor-Stand ist?
• Backout-Plan getestet. Wann zuletzt erfolgreich durchgespielt? Vor allem für Notfall-Szenarien.

Ein gutes CAB lehnt einen RFC ohne plausiblen, getesteten Backout-Plan ab. Mehr dazu in Change Management.

5) Spezialfall: Datenbank-Patches

Bei Datenbanken ist Rollback besonders heikel, weil Daten ständig hinzukommen. Ein Snapshot von 22:00 Uhr ist um 23:30 Uhr 1,5 Stunden veraltet – wer hat in der Zwischenzeit produktiv gearbeitet?

Strategien:

• Schema-Migration trennen vom Daten-Patch. Erst Schema (zurückrollbar), dann Daten.
• Forward-only-Migrations. Schema-Änderungen so designen, dass die alte App-Version mit dem neuen Schema noch funktioniert. Dann kein Schema-Rollback nötig, nur App-Code zurück.
• Replikation als Backup. Replica wird nicht gepatcht, Master patchen → bei Problemen Failover zur Replica.
• Point-in-Time-Recovery. Backup + Transaction Log = Restore auf den Zeitpunkt direkt vor dem Patch. Mehr in RTO/RPO.
• Logical Replication / Logical Backups. Daten getrennt von Strukturen wiederherstellbar.

6) Spezialfall: Cluster und HA

Bei Hochverfügbarkeits-Setups ist der Rollback strukturell anders: rollendes Patchen über alle Knoten, einer nach dem anderen – wenn Knoten 1 Probleme zeigt, wird er ausgenommen und die anderen werden gar nicht erst gepatcht.

# Beispiel: rollendes Patchen in Kubernetes via Ansible
- name: Rolling patch cluster
  hosts: k8s_nodes
  serial: 1           # einer nach dem anderen
  max_fail_percentage: 0  # bei jedem Fehler stoppen
  tasks:
    - name: Drain node
      command: kubectl drain {{ inventory_hostname }} --ignore-daemonsets
    - name: Patch node
      apt: upgrade: safe
    - name: Reboot
      reboot:
    - name: Uncordon node
      command: kubectl uncordon {{ inventory_hostname }}
    - name: Verify pods scheduled back
      command: kubectl get nodes {{ inventory_hostname }} -o jsonpath='{.status.conditions}'

7) Backout-Test

Eine entscheidende, gerne vergessene Disziplin: den Backout-Plan üben. Nicht erst im Notfall ausprobieren – sondern regelmäßig (z. B. quartalsweise) in der Test-Umgebung durchspielen:

1. Test-Umgebung patchen.
2. Rollback gemäß Plan durchführen.
3. Zeit messen: wie lange dauert das Rollback?
4. Funktioniert hinterher alles?
5. Wo waren die Stolpersteine?
6. Plan überarbeiten, falls nötig.

Pflicht-Übung vor allem für: Datenbank-Rollback, Failover-Rollback, Disaster-Recovery-Pfad. Mehr in MTBF/MTTR und RTO/RPO.

8) Was nach einem Rollback passiert

Rollback ist kein Erfolg – es ist die Notbremse. Was danach folgt:

• RFC als FAILED schließen, nicht als CLOSED-SUCCESS.
• Incident dokumentieren – warum musste rolled back werden? Welche Symptome?
• Problem-Management einleiten – mit Root-Cause-Analyse klären, warum der Patch nicht funktioniert hat.
• KEDB-Eintrag erstellen, damit nicht alle dieselbe Falle erneut betreten.
• Hersteller informieren bei Patch-Bug.
• Lessons Learned – was hätte den Fehler früher erkennen lassen? Test-Umgebung verbessern.
• Neuer Patch-Versuch mit korrigierter Vorgehensweise oder erst auf Hersteller-Fix warten.

9) Antipatterns

• „Wir restoren halt das Backup." Klingt einfach – ist es nicht. Letzter erfolgreicher Backup-Restore? Vor zwei Jahren in der Test-Umgebung. Lösung: Restore regelmäßig üben.
• Snapshot vor Patch vergessen. Bei VMs trivial, oft trotzdem nicht gemacht. Lösung: in Automation-Skript einbauen – immer vor Patch ein Snapshot.
• Snapshot „läuft eh nur 2 Stunden, dann lösche ich ihn". 6 Stunden später ist die VM extrem langsam, weil der Snapshot riesig wurde und nie konsolidiert. Lösung: Snapshot-Lebensdauer monitoren.
• Rollback ohne Datenverlust-Bewertung. Snapshot zurückgespielt – 500 produktive Transaktionen weg. Niemand vorher informiert. Lösung: Datenverlust-Abschätzung vor jedem Rollback.
• Backout-Plan nie getestet. Im Notfall stellt sich raus: Pfad funktioniert nicht, Backup-Restore dauert 8 Stunden, niemand hat das geübt.
• Mehrere Patches in einer Aktion, Rollback nur für alle. Wenn 3 Patches gleichzeitig laufen und einer schiefgeht, muss alles zurück – Granularität fehlt. Lösung: Patches einzeln rollen wenn möglich.
• Rollback statt Root-Cause-Suche. Patch immer wieder probieren und immer wieder rollen – ohne zu klären, warum er nicht funktioniert. Lösung: nach 2. Rollback wird Problem-Management Pflicht.
• Schweigen über Rollbacks. Niemand erfährt, dass gestern Abend ein wichtiger Patch zurückgerollt wurde. Anwender wundern sich, dass ihre Daten anders sind. Lösung: Kommunikations-Plan im Backout.

Zusammenfassung

Eine Rollback-Strategie beschreibt, wie ein Patch zurückgerollt wird, falls er Probleme verursacht. Vier Hauptmechanismen: Snapshot (schnell, sauber, ideal für VMs, aber Daten gehen verloren), Backup-Restore (langsamer, klassisch, mit Point-in-Time bei DBs), Package-Downgrade (gezielt für Linux/Windows-Updates, Daten bleiben), Reimage (Holzhammer, aber sicher). Entscheidung „Rollback ja/nein": abhängig von Schadensumfang, Verfügbarkeit eines Forward-Fix, Datenverlust-Akzeptanz. Backout-Plan im RFC: konkretes Vorgehen, Verantwortliche, Zeitschranke, Kommunikation, Datenverlust-Akzeptanz, Validierung. Spezialfälle: Datenbanken (Point-in-Time, Replikation, Forward-only-Migrations), Cluster/HA (rollendes Patchen, Knoten-Failover). Backout-Test als Pflicht-Übung (mind. quartalsweise). Nach Rollback: RFC als FAILED, Problem Management, KEDB-Eintrag, Hersteller informieren, Lessons Learned. Antipatterns: ungeübter Backout, Snapshot vergessen, Daten-Verlust ohne Bewertung, mehrere Patches in einer Aktion.

Verwandte Lektionen: Test vs. Produktiv · RTO/RPO · Change Management · und mehrWeitere relevante LektionenPatch-Management-ProzessPatch-DokumentationProblem ManagementKEDBFailoverMTBF/MTTRAnsible