Server Cloud und zuverlässiger IT-Betrieb – Verfügbarkeit und Ausfallszenarien planen
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.
| 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.
| 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
Offene Aufgaben
Leicht – Basis
- Servicekette: Zeichne die vier Dienste aus dem Ausbildungsfall und ihre Abhängigkeiten auf eine Karte.
- Fehleranalyse: Markiere die betroffenen Dienste bei einem reinen DNS-Ausfall und erkläre den Zusammenhang.
- Verfügbarkeit: Berechne das Ausfallbudget bei 99,9 Prozent für 30 Tage und kennzeichne es grafisch.
- Datensicherung: Erstelle eine Skizze zum Unterschied zwischen RAID 1 und einer unabhängigen Sicherung.
Standard – Anwendung
- Simulation: Starte die drei Fälle in
ausfalllabor.pyund protokolliere die zwei Zielprüfungen. - Wiederherstellung: Teste alle drei Kopien in
restorelabor.pyund begründe die Freigabe oder Ablehnung. - Notfallplan: Schreibe ein einseitiges Runbook für den fiktiven Datenbankausfall mit Rollen und Kontrollpunkten.
- Fehlerprävention: Entwirf einen sicheren Offline-Testplan für einen zweiten DNS-Dienst und begründe die erwartete Wirkung.
Schwer – Transfer
- Business Impact Analysis: Vergleiche zwei fiktive Geschäftsprozesse mit unterschiedlichen RTO- und RPO-Anforderungen und priorisiere sie begründet.
- Cloud Computing: Entwirf eine alternative Architektur mit einer zweiten Region; finde trotzdem eine gemeinsame Fehlerquelle.
- Risikoanalyse: Ergänze die Simulationsannahmen um Diagnose, Freigabe und abschließende Prüfung; bewerte die RTO neu.
- Lessons Learned: Drehe ein zweiminütiges Lernvideo oder führe ein fiktives Teaminterview über einen fehlgeschlagenen Restore-Test – ohne echte Betriebsdaten.


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
- Abhängigkeit: Zwei Server sind redundant, nutzen aber dieselbe DNS-Instanz. Erkläre, weshalb der Shop trotzdem ausfallen kann, und skizziere eine Verbesserung.
- Wiederanlaufzeit: Die Reparatur benötigt 40 Minuten, Diagnose und Funktionstest weitere 25 Minuten. Beurteile ein RTO von 60 Minuten und begründe Maßnahmen.
- 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?
- Notbetrieb: Formuliere einen sinnvollen manuellen Ersatzprozess für die fiktive Bestellannahme und beschreibe, wie später Dubletten vermieden werden.
- Cloud-Architektur: Zeige an einem eigenen Abhängigkeitsbild, warum zusätzliche Standorte nicht automatisch vor gemeinsamem Konfigurationsfehler schützen.
- 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
- Ein beschriftetes Abhängigkeitsdiagramm des fiktiven Shops einschließlich SPOF.
- Ein ausgefülltes Laborprotokoll für alle drei Ausfallszenarien mit RTO- und RPO-Abgleich.
- Ein Restore-Protokoll mit begründeter Annahme oder Ablehnung aller Testkopien.
- Ein kurzes Wiederanlauf-Runbook mit Verantwortlichkeiten, Prüfschritten und Kommunikation.
- Eine Transferreflexion, welche Annahmen des Offline-Modells in der Praxis zusätzlich getestet werden müssten.
- Eine Selbstbewertung anhand der Kriterien fachliche Richtigkeit, sichere Testdurchführung, Messbarkeit und nachvollziehbare Begründung.
OERs zum Thema
Fachlich geprüfte Grundlagen:
- BSI-Standard 200-4 – Business Continuity Management: Geschäftsauswirkungsanalyse, Notbetrieb, Wiederanlauf und Übungen.
- NIST SP 800-34 Rev. 1: Definitionen und Planung von RTO und RPO.
- Google Cloud – Leitfaden zur Disaster-Recovery-Planung: Zusammenhänge zwischen Geschäftszielen, Wiederherstellung und Kosten.
- AWS Well-Architected – Sicherung von Daten: Schutz, Automatisierung und Restore-Prüfungen.
- 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-HauptseiteMediathek
Mediathek wird aus dem Wiki geladen ...
Keine passenden Inhalte gefunden. Bitte ändere Suche oder Filter.
NEWSLernweltNOAH fragen