Zum Inhalt springen

Server Cloud und zuverlässiger IT-Betrieb – Verfügbarkeit und Ausfallszenarien planen

Aus MOOCsWiki Staging
aiMOOC-Siegel aiMOOC

Server Cloud und zuverlässiger IT-Betrieb – Verfügbarkeit und Ausfallszenarien planen

QR-Code


Server Cloud und zuverlässiger IT-Betrieb – Verfügbarkeit und Ausfallszenarien planen

Zielgruppe: IT-Ausbildung, insbesondere Fachinformatik Systemintegration und Digitale Vernetzung. Dauer: sieben kurze Lerneinheiten à 8–15 Minuten plus Projektaufgaben. Leitfrage: Welche Dienste hängen voneinander ab – und in welcher Reihenfolge bekommst Du sie nach einem Ausfall wieder zum Laufen?

Lernziele: Du erkennst einzelne Ausfallpunkte, unterscheidest Verfügbarkeit, RTO und RPO, simulierst Störungen offline und entwickelst einen überprüfbaren Wiederanlaufplan.

Sicherheitsregel: Alle Firmen, Bestellungen, Zeiten und Messwerte sind erfunden. Führe den Code ausschließlich lokal mit Python 3 aus. Er liest nur Tastatureingaben und schreibt auf die Konsole: kein Netzwerkzugriff, keine Cloud-Konten, keine Dateien, keine Produktivsysteme. Übe niemals ungefragt an fremden Netzen, Kundendaten oder echten Anlagen.


Einleitung

Ausbildungsfall: Die fiktive Lernfirma Nordlicht-Werkstatt betreibt einen Bestellshop. Der Shop braucht einen Netzzugang, DNS zur Namensauflösung und eine Datenbank. Ein Defekt kann deshalb weitere Funktionen unbenutzbar machen, obwohl diese selbst nicht beschädigt sind.

Mediennachweis: Carl Lender, Wikimedia Commons, CC BY 2.0; unverändert.

Arbeitsauftrag zum Einstieg: Zeichne die Kette „Netz → DNS / Datenbank → Shop“ und markiere den Baustein, dessen Ausfall die meisten Dienste trifft.


Lerneinheiten


Lerneinheit 1: Die Servicekette verstehen (10 Minuten)

Mediennachweis: Lubaochuan, Wikimedia Commons, CC BY-SA 4.0; unverändert.

Modell der Lernfirma:

              NETZ
             /    \
           DNS    DATENBANK
             \    /
               SHOP
Baustein Benötigt Wirkung bei Defekt
Netz – DNS und Datenbank nicht erreichbar; Shop fällt aus
DNS Netz Shop über Namen nicht erreichbar
Datenbank Netz Shop kann Bestellungen nicht bearbeiten
Shop DNS und Datenbank Bestellen nicht möglich

Merksatz: „Nicht erreichbar“ heißt nicht automatisch „kaputt“. Erstelle für kritische Geschäftsprozesse zuerst eine Abhängigkeitsanalyse.

Mini-Aufgabe: Was passiert mit dem Shop, wenn nur die Datenbank ausfällt?


Lerneinheit 2: Ausfallszenarien erkennen (8 Minuten)

Mediennachweis: Sam Johnston, Wikimedia Commons, CC BY-SA 3.0; unverändert.

Mediennachweis: Foobaz / Malyszkz / Reise Reise, Wikimedia Commons, CC0; unverändert.

Drei Fehlerklassen: Einzelkomponente (DNS), Datenkomponente (Datenbank), gemeinsame Infrastruktur (Netz/Standort). Ein gemeinsamer Ausfallpunkt heißt SPOF. Auch in der Cloud bleiben eigene Anwendungsabhängigkeiten und Zuständigkeiten bestehen; eine Provider-Verfügbarkeitszusage ersetzt keinen Ende-zu-Ende-Test.

Mini-Aufgabe: Markiere im Diagramm einen SPOF und entwirf eine zweite, unabhängige Variante.


Lerneinheit 3: Verfügbarkeit, RTO und RPO (12 Minuten)

Verfügbarkeit ist der Anteil der betrachteten Zeit, in der ein Dienst nutzbar ist. RTO ist die angestrebte maximale Wiederherstellungsdauer. RPO beschreibt den maximal akzeptierten Zeitraum potenziellen Datenverlusts vor einem Ausfall. Beide Ziele werden aus dem Geschäftsbedarf abgeleitet; sie sind keine automatisch erreichten Garantien.

Fiktive Vorgabe Nordlicht-Werkstatt: RTO = 60 Minuten; RPO = 15 Minuten.

Rechenbild: maximaler Ausfall in einem angenommenen 30-Tage-Monat (43.200 Minuten)
Zeitbasierte Verfügbarkeit Gesamtes Ausfallbudget Diagramm: ein Block ungefähr 20 Minuten
99 % 432 Minuten ██████████████████████
99,9 % 43,2 Minuten ██
99,99 % 4,32 Minuten ▏

Achtung: Ein Monats-Ausfallbudget ist nicht dasselbe wie eine RTO-Grenze für einen einzelnen Vorfall. Für teilverfügbare Dienste können anfragenbasierte Messungen geeigneter sein.

Video (Englisch): SrcCodes, „What is RPO and RTO in Disaster Recovery (DR)?“ – zur Unterscheidung beider Ziele.

Mini-Aufgabe: Eine Wiederherstellung dauert 40 Minuten, die letzte brauchbare Kopie ist 20 Minuten alt. Welche Nordlicht-Zielvorgabe wird verfehlt?


Lerneinheit 4: Vorbeugen ist nicht wiederherstellen (10 Minuten)

Mediennachweis: Cburnett, Wikimedia Commons, CC BY-SA 3.0; unverändert.

Mediennachweis: Work With Sounds, Wikimedia Commons, CC BY-SA 4.0; unverändert.

Technik Hilft gegen Reicht nicht gegen
RAID 1 Ausfall einer gespiegelten Platte Irrtümliches Löschen, Verschlüsselungstrojaner
USV Kurze Stromunterbrechung Längeren Standortausfall ohne weitere Vorsorge
Failover Ausfall eines aktiven Knotens Gemeinsame Fehlerquelle oder fehlerhafte Replikation
Backup und Restore-Test Verlust oder Beschädigung von Daten Sofortige Verfügbarkeit ohne Wiederanlaufzeit

Mini-Aufgabe: Begründe, warum RAID kein Backup ist.

Video (Englisch, Anbieterperspektive): Google Cloud Tech, „Introduction to Google Cloud Backup and DR“. Prüfe, welche Schritte weiterhin der Betreiber verantwortet.


Lerneinheit 5: Sicherungen und Datenstand prüfen (10 Minuten)

Mediennachweis: Olaf Pichler, Wikimedia Commons, CC BY-SA 4.0; unverändert.

Mediennachweis: Inowen, Wikimedia Commons, CC BY-SA 4.0; unverändert.

3-2-1 ist eine verbreitete Backup-Faustregel: drei Datenkopien, zwei unterschiedliche Medientypen, eine Kopie außerhalb des Primärstandorts. Zusätzlich wichtig: getrennte Zugriffsrechte, Manipulationsschutz, Überwachung und regelmäßig geprüfte Wiederherstellbarkeit. Ein erfolgreicher Backup-Job allein beweist keine brauchbare Wiederherstellung.

Mini-Aufgabe: Erkläre, warum ein vorhandenes Backup das RPO trotzdem verfehlen kann.


Lerneinheit 6: Isoliertes Praxislabor (15 Minuten)

Labor A – Wiederanlauf und Fehlerkaskade. Speichere den folgenden vollständigen Code als ausfalllabor.py. Starte ihn nur auf Deinem eigenen Lernrechner mit python3 ausfalllabor.py (unter Windows gegebenenfalls py ausfalllabor.py). Er nutzt nur Python-Standardfunktionen, Eingaben und Konsolenausgabe.

# Datei: ausfalllabor.py | Python 3, nur Standardbibliothek
ABH = {"Netz": (), "DNS": ("Netz",), "DB": ("Netz",),
       "Shop": ("DNS", "DB")}
MIN = {"Netz": 15, "DNS": 10, "DB": 40, "Shop": 15}
FAELLE = {
    "1": ("Nur DNS gestört", {"DNS"}, 0),
    "2": ("Datenbank gestört", {"DB"}, 20),
    "3": ("Standortstörung", {"Netz", "DNS", "DB", "Shop"}, 10)
}

def auswirkung(defekt):
    betroffen = set(defekt)
    while True:
        neu = betroffen | {
            dienst for dienst, voraus in ABH.items()
            if any(v in betroffen for v in voraus)
        }
        if neu == betroffen:
            return sorted(betroffen)
        betroffen = neu

print("OFFLINE-AUSFALLLABOR: rein fiktive Minuten und Daten")
print("1 DNS | 2 DB | 3 Standort")
wahl = input("Szenario [1]: ").strip() or "1"
if wahl not in FAELLE:
    raise SystemExit("Bitte 1, 2 oder 3 wählen.")
try:
    rto = int(input("RTO in Minuten [60]: ") or "60")
    rpo = int(input("RPO in Minuten [15]: ") or "15")
except ValueError:
    raise SystemExit("Bitte ganze Minuten eingeben.")
if rto < 0 or rpo < 0:
    raise SystemExit("Ziele dürfen nicht negativ sein.")

titel, defekt, datenalter = FAELLE[wahl]
print("\nFall:", titel)
print("Nicht nutzbar:", ", ".join(auswirkung(defekt)))
print("Sequenzieller Wiederanlauf (jedes # = 5 Minuten):")
dauer = 0
for dienst in ("Netz", "DNS", "DB", "Shop"):
    if dienst in defekt:
        dauer += MIN[dienst]
        print(f"{dienst:>5}: {'#' * (MIN[dienst] // 5):<8} bis Minute {dauer}")
zeit_ok = dauer <= rto
daten_ok = datenalter <= rpo
print(f"Ausfall: {dauer} min | RTO: {rto} min ->",
      "OK" if zeit_ok else "NICHT OK")
print(f"Datenalter: {datenalter} min | RPO: {rpo} min ->",
      "OK" if daten_ok else "NICHT OK")
print("Ergebnis:", "beide Ziele erfüllt" if zeit_ok and daten_ok
      else "Plan anpassen")

Drei isolierte Testumgebungen: Wähle 1 (DNS), 2 (Datenbank) und 3 (Standort). Verändere danach die eingegebenen Grenzwerte. Die Wiederanlaufdauern sind Modellannahmen, keine realen Messwerte. Es wird nur bei tatsächlich defekten Komponenten Reparaturzeit addiert; abhängige Dienste können anschließend ohne eigenen Defekt wieder nutzbar sein. Erkennung, Freigabe und Funktionsprüfung sind noch nicht eingerechnet.

Erwartete Labordaten bei RTO 60 min und RPO 15 min
Szenario Errechnete Ausfallzeit Potenzieller Datenverlustzeitraum RTO RPO
DNS 10 min 0 min erfüllt erfüllt
Datenbank 40 min 20 min erfüllt verfehlt
Standort 80 min 10 min verfehlt erfüllt

Visualisierung für Standortstörung (je # = 5 Minuten):

Netz   ###      Ende 15 min
DNS    ##       Ende 25 min
DB     ######## Ende 65 min
Shop   ###      Ende 80 min

Labor B – Restore-Freigabe. Speichere als restorelabor.py und starte mit python3 restorelabor.py. Dieses zweite Labor prüft fiktive Listen gegen einen unabhängigen Soll-Datenstand. Es erzeugt kein echtes Backup und nutzt keine fremden Daten.

# Datei: restorelabor.py | rein fiktive Listen, kein Datei-/Netzzugriff
KOPIEN = {
    "1": (5, ["B-001", "B-002", "B-003"],
          ["B-001", "B-002", "B-003"]),
    "2": (25, ["B-001"], ["B-001"]),
    "3": (5, ["B-001", "FEHLER", "B-003"],
          ["B-001", "B-002", "B-003"])
}
print("OFFLINE-RESTORELABOR: 1 intakt | 2 zu alt | 3 beschädigt")
wahl = input("Testkopie [1]: ").strip() or "1"
if wahl not in KOPIEN:
    raise SystemExit("Bitte 1, 2 oder 3 wählen.")
alter, restore, soll = KOPIEN[wahl]
rpo = 15
integritaet = restore == soll
zeit_ok = alter <= rpo
print("Fiktiver wiederhergestellter Datenstand:", restore)
print(f"Alter: {alter} min; erlaubtes RPO: {rpo} min")
print("Integrität:", "OK" if integritaet else "FEHLER")
print("RPO:", "OK" if zeit_ok else "FEHLER")
print("Freigabe:", "JA" if integritaet and zeit_ok else "NEIN")

Prüfe nacheinander: Kopie 1 ist intakt und frisch; Kopie 2 ist intakt, aber zu alt; Kopie 3 ist frisch, aber beschädigt. Ein echter Restore-Test benötigt zusätzlich Systemstart, Anwendungsprüfung, Sicherheitskontrollen und dokumentierte Messung.


Lerneinheit 7: Wiederanlaufplan und Teamübung (12 Minuten)

Runbook der Lernfirma – Reihenfolge vor Tempo:

Phase Aktivität Nachweis / Entscheidung
Erkennen Alarm und Nutzersymptom vergleichen Ist der Shop wirklich nicht nutzbar?
Eingrenzen Netz, DNS, DB getrennt prüfen Welcher Defekt verursacht Folgewirkungen?
Entscheiden Freigegebenen Notbetrieb wählen Verantwortliche und Kommunikationsweg bekannt?
Wiederanlaufen Netz → DNS / DB → Shop Voraussetzungen je Dienst erfüllt?
Validieren Fiktive Testbestellung und Datenstand prüfen RTO und RPO tatsächlich gemessen?
Nachbereiten Verlauf, Ursache und Verbesserungen dokumentieren Neuer Testtermin festgelegt?

Rollenspiel: Eine Person meldet den Ausfall, eine entscheidet über Notbetrieb, eine dokumentiert Zeitstempel, eine prüft die fiktive Testbestellung. Nutzt ausschließlich das Offline-Labor.

Video (Englisch): Peace Of Code, „Disaster Recovery on AWS“; zur Vertiefung besonders Minute 0–15 zu RTO, RPO und Wiederanlaufstrategien. Anbieterbeispiele sind keine universelle Lösung.


Gestufte Hilfen

Stufe Wenn Du nicht weiterkommst ...
Hilfe 1 – Hinweis Suche im Abhängigkeitsbild den Dienst direkt vor dem Shop.
Hilfe 2 – Struktur Trenne Ursache, betroffene Dienste, Reparaturdauer und Datenstand in vier Spalten.
Hilfe 3 – Muster Szenario 2: DB fällt aus, Shop ist betroffen; Reparatur 40 min erfüllt RTO 60 min, Backupalter 20 min verfehlt RPO 15 min. Warum? Wiederanlauf und Datenverlust sind verschiedene Messgrößen.


Interaktive Aufgaben


Quiz: Teste Dein Wissen

Was bezeichnet RTO? (Maximal angestrebte Wiederherstellungsdauer) (!Anzahl gespeicherter Backups) (!Stromverbrauch eines Servers) (!Dauer eines Softwareupdates)




Was misst RPO? (Maximal akzeptierten Zeitraum potenziellen Datenverlusts) (!Anzahl der Datenbanktabellen) (!Reparaturdauer einer Festplatte) (!Anzahl gleichzeitiger Nutzer)




Welcher Dienst ist im Ausbildungsfall direkt von DNS und Datenbank abhängig? (Shop) (!Netz) (!USV) (!Backupmedium)




Was ist ein SPOF? (Eine einzelne kritische Ausfallstelle) (!Eine zweite unabhängige Sicherung) (!Ein erfolgreiches Wiederherstellungstestprotokoll) (!Eine identische Reserve in anderem Standort)




Warum ersetzt RAID 1 kein Backup? (Fehlerhafte Löschungen können beide Spiegel betreffen) (!RAID 1 speichert niemals Daten) (!Ein Backup funktioniert nur ohne Festplatten) (!RAID 1 stellt keine Daten bereit)




Welches Ziel wird im Laborszenario Datenbank mit Standardgrenzen verfehlt? (RPO) (!RTO) (!Beide Ziele) (!Keines der Ziele)




Wie viele Minuten dauert der modellierte Standortwiederanlauf insgesamt? (80 Minuten) (!15 Minuten) (!40 Minuten) (!100 Minuten)




Was prüft das Restorelabor zusätzlich zum Datenalter? (Übereinstimmung mit dem Soll-Datenstand) (!Stromverbrauch) (!Physische Kabellänge) (!Internetgeschwindigkeit)




Was gehört vor die Freigabe eines wiederhergestellten Shops? (Eine fachliche Funktionsprüfung) (!Nur das Vorhandensein einer Backupdatei) (!Das Abschalten aller Alarme) (!Das Löschen des Testprotokolls)




Was gilt für eine Cloud-Verfügbarkeitszusage? (Sie ersetzt keine Prüfung der gesamten Servicekette) (!Sie garantiert die fehlerfreie eigene Anwendung) (!Sie macht Backups überflüssig) (!Sie beseitigt sämtliche gemeinsamen Abhängigkeiten)





Memory

RTO Zeit bis zum angestrebten Wiederanlauf
RPO Akzeptierter Datenverlustzeitraum
DNS Namensauflösung
SPOF Einzelne kritische Ausfallstelle
Failover Umschalten auf Ersatzbetrieb
Restore Wiederherstellen gesicherter Daten





Drag and Drop

Ordne die richtigen Begriffe zu. Bedeutung im Wiederanlauf
Erkennung Alarme und Nutzersymptome feststellen
Eingrenzung Ursachen und Abhängigkeiten prüfen
Entscheidung Notbetrieb verantwortlich freigeben
Wiederanlauf Kritische Dienste geordnet reparieren
Validierung Testbestellung und Datenstand kontrollieren





Kreuzworträtsel

Redundanz Wie heißt die mehrfache Auslegung kritischer Komponenten?
Failover Wie heißt das Umschalten auf einen Ersatzdienst?
Backup Wie heißt eine Sicherungskopie?
Restore Wie heißt die Wiederherstellung aus einer Sicherung?
Monitoring Wie heißt die fortlaufende Überwachung von Diensten?
Datenbank Wo speichert der fiktive Shop seine Bestellungen?





LearningApps

Hinweis: Die LearningApps-Suche und die eingebetteten YouTube-Videos sind externe optionale Medien; sie können beim Aufruf Anfragen an Drittanbieter erzeugen. Gib dort keine echten Betriebs- oder Personendaten ein. Die zwei Python-Labore benötigen weder diese Dienste noch Internet.


Lückentext

Vervollständige den Text.
Wenn eine einzelne Komponente den gesamten Dienst stoppen kann, ist sie ein

.
Die Namensauflösung übernimmt im Modell der Dienst

.
Die Shop-Anwendung braucht außerdem die

.
Die maximale angestrebte Wiederherstellungsdauer heißt

.
Der maximal akzeptierte Zeitraum potenziellen Datenverlusts heißt

.
In der Lernfirma beträgt das RTO

Minuten.
Im Datenbankszenario dauert die Reparatur modellhaft

Minuten.
Der angenommene Datenstand ist dort

Minuten alt.
Ein gespiegeltes Plattensystem heißt beispielsweise

.
Eine Sicherungskopie nennt man

.
Das Wiederherstellen einer Sicherung ist ein

.
Nach dem Wiederanlauf ist die fachliche

erforderlich.



Offene Aufgaben


Leicht – Basis

  1. Servicekette: Zeichne die vier Dienste aus dem Ausbildungsfall und ihre Abhängigkeiten auf eine Karte.
  2. Fehleranalyse: Markiere die betroffenen Dienste bei einem reinen DNS-Ausfall und erkläre den Zusammenhang.
  3. Verfügbarkeit: Berechne das Ausfallbudget bei 99,9 Prozent für 30 Tage und kennzeichne es grafisch.
  4. Datensicherung: Erstelle eine Skizze zum Unterschied zwischen RAID 1 und einer unabhängigen Sicherung.


Standard – Anwendung

  1. Simulation: Starte die drei Fälle in ausfalllabor.py und protokolliere die zwei Zielprüfungen.
  2. Wiederherstellung: Teste alle drei Kopien in restorelabor.py und begründe die Freigabe oder Ablehnung.
  3. Notfallplan: Schreibe ein einseitiges Runbook für den fiktiven Datenbankausfall mit Rollen und Kontrollpunkten.
  4. Fehlerprävention: Entwirf einen sicheren Offline-Testplan für einen zweiten DNS-Dienst und begründe die erwartete Wirkung.


Schwer – Transfer

  1. Business Impact Analysis: Vergleiche zwei fiktive Geschäftsprozesse mit unterschiedlichen RTO- und RPO-Anforderungen und priorisiere sie begründet.
  2. Cloud Computing: Entwirf eine alternative Architektur mit einer zweiten Region; finde trotzdem eine gemeinsame Fehlerquelle.
  3. Risikoanalyse: Ergänze die Simulationsannahmen um Diagnose, Freigabe und abschließende Prüfung; bewerte die RTO neu.
  4. Lessons Learned: Drehe ein zweiminütiges Lernvideo oder führe ein fiktives Teaminterview über einen fehlgeschlagenen Restore-Test – ohne echte Betriebsdaten.




Text bearbeiten Bild einfügen Video einbetten Interaktive Aufgaben erstellen



Feedback und Musterlösungen

Niveau / Test Erwartete Rückmeldung mit Begründung
Basis DNS-Ausfall macht den Shop unbenutzbar, obwohl die Datenbank intakt bleibt: Die Namensauflösung ist Teil der Zugriffskette. 99,9 % von 43.200 Minuten bedeutet 43,2 Minuten erlaubten Gesamtausfall.
Anwendung A Fall 1: 10/0 Minuten – beide Ziele erfüllt. Fall 2: 40/20 – RPO nicht erfüllt, weil 20 größer als 15 ist. Fall 3: 80/10 – RTO nicht erfüllt, weil 80 größer als 60 ist.
Anwendung B Kopie 1 freigeben; Kopie 2 wegen 25 Minuten Datenalter ablehnen; Kopie 3 wegen abweichendem Soll-Datenstand ablehnen. Ein frisches Backup kann trotzdem unbrauchbar sein.
Transfer Eine zweite Region hilft nur, wenn die Abhängigkeiten tatsächlich unabhängig sind. Gemeinsames DNS, gemeinsame Berechtigungen oder identische fehlerhafte Konfigurationen können beide Standorte treffen.
Erweiterter RTO-Test Werden Diagnose und Validierung addiert, steigt die tatsächliche Wiederanlaufzeit. Deshalb beweist die Reparaturzeit allein nicht, dass die fachliche RTO eingehalten wird.

Feedback zu den Quizfragen: (1) RTO beurteilt die Unterbrechung; (2) RPO den wiederherstellbaren Datenstand; (3) der Shop braucht beide Dienste; (4) ein SPOF hat keine unabhängige Ausweichmöglichkeit; (5) Spiegelung übernimmt auch logische Fehler; (6) 20 > 15; (7) 15 + 10 + 40 + 15 = 80; (8) Integrität ist unabhängig vom Alter; (9) ohne Funktionstest keine fachliche Freigabe; (10) der Endnutzer erlebt die ganze Servicekette.


Lernkontrolle

  1. Abhängigkeit: Zwei Server sind redundant, nutzen aber dieselbe DNS-Instanz. Erkläre, weshalb der Shop trotzdem ausfallen kann, und skizziere eine Verbesserung.
  2. Wiederanlaufzeit: Die Reparatur benötigt 40 Minuten, Diagnose und Funktionstest weitere 25 Minuten. Beurteile ein RTO von 60 Minuten und begründe Maßnahmen.
  3. Datenverlust: Vergleiche einen intakten, 25 Minuten alten Datenstand mit einer fünf Minuten alten beschädigten Kopie. Welche kann unter RPO 15 Minuten freigegeben werden, und warum?
  4. Notbetrieb: Formuliere einen sinnvollen manuellen Ersatzprozess für die fiktive Bestellannahme und beschreibe, wie später Dubletten vermieden werden.
  5. Cloud-Architektur: Zeige an einem eigenen Abhängigkeitsbild, warum zusätzliche Standorte nicht automatisch vor gemeinsamem Konfigurationsfehler schützen.
  6. Kommunikation: Verfasse für die fiktive Geschäftsleitung eine Lageinformation mit Ursache, Auswirkungen, Zielabweichung und nächster Prüfung.

Bewertung: Gute Lösungen stellen den Geschäftsprozess in den Mittelpunkt, trennen RTO und RPO, nennen Abhängigkeiten, berücksichtigen die Testgrenzen und begründen eine überprüfbare Entscheidung.


Lernnachweis

  1. Ein beschriftetes Abhängigkeitsdiagramm des fiktiven Shops einschließlich SPOF.
  2. Ein ausgefülltes Laborprotokoll für alle drei Ausfallszenarien mit RTO- und RPO-Abgleich.
  3. Ein Restore-Protokoll mit begründeter Annahme oder Ablehnung aller Testkopien.
  4. Ein kurzes Wiederanlauf-Runbook mit Verantwortlichkeiten, Prüfschritten und Kommunikation.
  5. Eine Transferreflexion, welche Annahmen des Offline-Modells in der Praxis zusätzlich getestet werden müssten.
  6. Eine Selbstbewertung anhand der Kriterien fachliche Richtigkeit, sichere Testdurchführung, Messbarkeit und nachvollziehbare Begründung.


OERs zum Thema

Fachlich geprüfte Grundlagen:

  1. BSI-Standard 200-4 – Business Continuity Management: Geschäftsauswirkungsanalyse, Notbetrieb, Wiederanlauf und Übungen.
  2. NIST SP 800-34 Rev. 1: Definitionen und Planung von RTO und RPO.
  3. Google Cloud – Leitfaden zur Disaster-Recovery-Planung: Zusammenhänge zwischen Geschäftszielen, Wiederherstellung und Kosten.
  4. AWS Well-Architected – Sicherung von Daten: Schutz, Automatisierung und Restore-Prüfungen.
  5. Google SRE – Availability Table: Zeitbasierte Ausfallbudgets.

Medienrechte: Alle acht eingebundenen Abbildungen stammen aus den einzeln verlinkten Wikimedia-Commons-Dateiseiten; die jeweiligen Urheber und Lizenzen stehen unmittelbar am Bild. Die Abbildungen wurden im Kurs nicht verändert. Die YouTube-Videos sind externe, eingebettete Fremdmedien und nicht als frei nachnutzbare Kursvideos lizenziert. Lernaufgaben und Python-Beispiele wurden eigens für diesen fiktiven Fall erstellt. Quellen- und Medienstand: 10. Oktober 2026.


Verknüpfte Lernbereiche


aiMOOC-Projekte



Schulfach+




aiMOOCs



aiMOOC Projekte









MOOCwiki · Deutsch

Nach dem Lernen ist vor dem Lernen

Entdecke direkt den nächsten Lernkurs. Weitere Inhalte erscheinen, wenn Du weiter nach unten scrollst.

Zur MOOCwiki-Hauptseite

Mediathek

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...