Seminar Cloud&Heat Titan / SecuStack – Backup, Restore und Disaster Recovery

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar entwickelt aus Schutzobjekten, RPO und RTO ein belastbares Sicherungs- und Wiederanlaufkonzept. Plattformzustand, OpenStack-Steuerungsdaten, Volumes, Images, Objektdaten, Schlüsselabhängigkeiten und realistische Notfalltests werden gemeinsam betrachtet.

Lernziele

• Schutzobjekte und Wiederherstellungsabhängigkeiten vollständig erfassen
• RPO, RTO, Sicherungsmethode und Aufbewahrung je Datenklasse festlegen
• Plattform- und Mandantendaten mit geeigneten Verfahren sichern
• Restore-Reihenfolgen für Einzelobjekt, Dienst und Plattform entwickeln
• Disaster-Recovery-Tests mit messbaren Kriterien planen und auswerten

Zielgruppe und Voraussetzungen

Zielgruppe: Plattformadministration, Backup- und Storagebetrieb, IT-Notfallmanagement, Informationssicherheit, Service Management und technische Anwendungsverantwortung.

Voraussetzungen: Grundkenntnisse im Betrieb von OpenStack, Storage und Linux. Verständnis für betriebliche Wiederherstellungsziele und Change-Prozesse.

Seminarinhalte

Tag 1: Schutzobjekte, Datenklassen und Sicherungsverfahren

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Backup-Konzept und Schutzobjekte

Das Backup-Konzept unterscheidet Plattformzustand, Konfiguration, Datenbanken, Images, Volumes, Objekte und externe Abhängigkeiten.

1. Schritt 1 – Schutzobjekte erfassen: Pro Komponente werden Dateninhalt, Konsistenzanforderung, Eigentümer und Wiederherstellungsabhängigkeiten dokumentiert.
2. Schritt 2 – RPO und RTO festlegen: Zulässiger Datenverlust und Wiederanlaufzeit werden je Service- und Datenklasse definiert.
3. Schritt 3 – Sicherungsmethode wählen: Snapshot, anwendungskoordinierte Sicherung, Datenbankbackup, Konfigurationsexport und Replikation werden passend kombiniert.
4. Schritt 4 – Aufbewahrung absichern: Rotation, getrennte Fehlerdomäne, Unveränderbarkeit, Verschlüsselung und Löschfristen werden festgelegt.

Praxisbezug: Erstellung einer Backup-Matrix mit Schutzobjekt, Methode, Intervall, RPO, RTO und Aufbewahrung.

Storage-Architektur und Datenklassen

Block-, Image-, Objekt- und lokale Speicherfunktionen werden nach Persistenz, Leistung, Schutzbedarf und Wiederherstellbarkeit eingeordnet.

1. Schritt 1 – Datenarten klassifizieren: Betriebssystem-Images, Boot-Volumes, Anwendungsdaten, Backups, Protokolle und temporäre Daten werden getrennt betrachtet.
2. Schritt 2 – Dienstzuordnung treffen: Glance, Cinder, Objektspeicher und lokale Ephemeral-Datenträger werden nach Lebenszyklus und Zugriffsmuster ausgewählt.
3. Schritt 3 – Leistungsziele definieren: Kapazität, IOPS, Latenz, Durchsatz und Wiederherstellungsanforderungen werden pro Datenklasse festgelegt.
4. Schritt 4 – Fehlerdomänen prüfen: Knoten-, Datenträger-, Rack- und Standortausfälle werden gegen Replikation und Backupstrategie bewertet.

Praxisbezug: Erstellung einer Datenklassenmatrix mit passendem Storage-Dienst, Schutz und Wiederherstellungsziel.

Sicherung von Plattform- und Mandantendaten

OpenStack-Steuerungsdaten und Mandantenressourcen benötigen unterschiedliche Sicherungsverfahren und Verantwortlichkeiten.

1. Schritt 1 – Plattformdaten sichern: Datenbanken, Schlüsselkonfigurationen, Zertifikate, Custom Resources und betriebliche Konfiguration werden konsistent erfasst.
2. Schritt 2 – Mandantendaten sichern: Volumes, Objekte, Images und anwendungseigene Daten werden nach Serviceklasse und Verantwortungsmodell behandelt.
3. Schritt 3 – Sicherungsjobs überwachen: Laufzeit, Datenmenge, Erfolgsstatus, Fehler, Aufbewahrung und Replikationsstand werden zentral kontrolliert.
4. Schritt 4 – Wiederlesbarkeit prüfen: Stichproben und automatisierte Integritätsprüfungen bestätigen, dass Sicherungen vollständig und entschlüsselbar sind.

Praxisbezug: Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.

Tag 2: Wiederherstellung, Notfalltest und Runbooks

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Restore-Verfahren und Wiederanlaufreihenfolge

Wiederherstellung wird als abhängige Reihenfolge von Basisinfrastruktur, Plattformdiensten, Konfiguration und Nutzdaten geplant.

1. Schritt 1 – Wiederherstellungsziel bestimmen: Einzelobjekt, Dienst, Cluster, Standort oder vollständige Plattform werden klar voneinander abgegrenzt.
2. Schritt 2 – Abhängigkeiten ordnen: Identität, Datenbanken, Message Queue, Kubernetes, Operatoren, OpenStack-Dienste und Mandantendaten werden in eine Reihenfolge gebracht.
3. Schritt 3 – Restore isoliert ausführen: Zieldomäne, Netzwerkzugriff, Schlüsselmaterial und Konflikte mit produktiven Ressourcen werden vorab kontrolliert.
4. Schritt 4 – Funktion nachweisen: Integrität, API-Funktion, Zugriffsrechte, Netzwerk, Storage und Beispielworkload werden nach der Wiederherstellung getestet.

Praxisbezug: Durchführung eines dokumentierten Restore-Tests für Konfiguration und ein Testvolume.

Disaster-Recovery-Tests

Notfallverfahren gelten erst nach einem realistischen, wiederholbaren und ausgewerteten Test als belastbar.

1. Schritt 1 – Szenario wählen: Ausfall von Management, Storage, mehreren Knoten, Rack oder Standort wird mit klaren Annahmen beschrieben.
2. Schritt 2 – Erfolgskriterien definieren: RTO, RPO, Datenintegrität, Mindestservice und Kommunikationsziele werden messbar festgelegt.
3. Schritt 3 – Übung steuern: Startzustand, Freigabe, Beobachter, Sicherheitsgrenzen und Abbruchkriterien werden vor Beginn festgehalten.
4. Schritt 4 – Erkenntnisse umsetzen: Zeitabweichungen, fehlende Zugänge, unklare Rollen und technische Lücken werden in konkrete Maßnahmen überführt.

Praxisbezug: Planung einer Tabletop- und einer technischen Wiederanlaufübung mit messbaren Kriterien.

Runbooks und Standardverfahren

Runbooks übersetzen bekannte Betriebsfälle in reproduzierbare Schritte mit Vorbedingungen, Prüfungen und Rückfall.

1. Schritt 1 – Auslöser beschreiben: Symptom, Alarm, Grenzwert oder Änderungsanlass wird eindeutig definiert.
2. Schritt 2 – Vorprüfung festlegen: Berechtigung, Ausgangszustand, betroffene Systeme, Backup und Wartungsfenster werden vor dem Eingriff geprüft.
3. Schritt 3 – Handlungsschritte ordnen: Befehle und Kontrollen werden in kleinste prüfbare Einheiten mit erwarteten Ergebnissen zerlegt.
4. Schritt 4 – Abschluss sichern: Funktionstest, Monitoring, Dokumentation, Ticketabschluss und gegebenenfalls Problem-Record werden festgelegt.

Praxisbezug: Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.

Tag 3: Objektablagen, Incident-Steuerung und Nachweise

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Objektspeicher und unveränderbare Ablagen

Objektspeicher eignet sich für große, unstrukturierte Datenbestände, Artefakte und je nach Auslegung für Backup- oder Archivzwecke.

1. Schritt 1 – Namespace planen: Container beziehungsweise Buckets, Objektpfade, Mandantentrennung und Namenskonventionen werden festgelegt.
2. Schritt 2 – Zugriff absichern: Rollen, temporäre Zugriffe, Netzwerkpfade und Verschlüsselungsanforderungen werden definiert.
3. Schritt 3 – Lebenszyklus steuern: Versionierung, Aufbewahrung, Ablaufregeln und gegebenenfalls Unveränderbarkeit werden nach Datenklasse eingerichtet.
4. Schritt 4 – Integrität prüfen: Prüfsummen, Stichproben, Kapazitätsentwicklung und Wiederlesbarkeit werden regelmäßig kontrolliert.

Praxisbezug: Entwurf einer Objektablage für Artefakte und Backups mit Aufbewahrungs- und Berechtigungskonzept.

Incident Management und Eskalation

Störungen werden nach Auswirkung priorisiert, technisch stabilisiert und mit klarer Kommunikation bis zur Ursachenanalyse geführt.

1. Schritt 1 – Incident eröffnen: Zeitpunkt, Auswirkung, betroffene Services, aktuelle Symptome und verantwortliche Leitung werden festgehalten.
2. Schritt 2 – Stabilisierung priorisieren: Schadensbegrenzung, Wiederherstellung und Beweissicherung werden vor nicht notwendigen Detailanalysen behandelt.
3. Schritt 3 – Arbeitsstränge koordinieren: Infrastruktur, Kubernetes, OpenStack, Netzwerk, Storage und Kommunikation erhalten klar abgegrenzte Aufgaben.
4. Schritt 4 – Nachbereitung durchführen: Ursache, beitragende Faktoren, Wirksamkeit der Reaktion und dauerhafte Maßnahmen werden dokumentiert.

Praxisbezug: Bearbeitung eines simulierten Major Incidents mit Rollen, Lageprotokoll, Stabilisierung und Nachbereitung.

Auditnachweise und revisionsfähige Dokumentation

Nachweise müssen aktuell, vollständig, manipulationsgeschützt und einer konkreten Kontrolle zuordenbar sein.

1. Schritt 1 – Evidenz definieren: Konfigurationsauszug, Protokoll, Ticket, Freigabe, Scanbericht oder Testergebnis wird je Kontrolle festgelegt.
2. Schritt 2 – Erzeugung standardisieren: Quelle, Zeitraum, Filter, Exportformat und verantwortliche Stelle werden reproduzierbar beschrieben.
3. Schritt 3 – Integrität sichern: Zeitstempel, Zugriffsschutz, Versionierung und gegebenenfalls Signatur schützen Nachweise vor Veränderung.
4. Schritt 4 – Abweichung verfolgen: Feststellung, Risiko, Maßnahme, Frist und Wirksamkeitsprüfung werden bis zum Abschluss nachgehalten.

Praxisbezug: Zusammenstellung eines kleinen Auditpakets für Berechtigungsprüfung, Patchstand und Restore-Test.

Praxislabor

• Erstellung einer Backup-Matrix mit Schutzobjekt, Methode, Intervall, RPO, RTO und Aufbewahrung.
• Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.
• Durchführung eines dokumentierten Restore-Tests für Konfiguration und ein Testvolume.
• Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.
• Entwurf einer Objektablage für Artefakte und Backups mit Aufbewahrungs- und Berechtigungskonzept.
• Zusammenstellung eines kleinen Auditpakets für Berechtigungsprüfung, Patchstand und Restore-Test.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.