SQL Academy · Lektion

Notfallwiederherstellungsplanung

RPO, RTO und Runbooks

Lektion 4 von 413 Schritte

Notfallwiederherstellungsplanung ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist Disaster Recovery?

Disaster Recovery (DR) umfasst die Richtlinien, Werkzeuge und Verfahren, die darauf ausgelegt sind, die Wiederherstellung wichtiger technologischer Infrastrukturen und Systeme nach einer Naturkatastrophe oder einem von Menschen verursachten Notfall zu ermöglichen.

Im Kontext von Datenbanken stellt die DR-Planung sicher, dass Ihre Daten geschützt bleiben und Ihre Systeme nach Ereignissen wie Hardwareausfällen, versehentlichem Löschen von Daten, Ransomware-Angriffen oder Ausfällen von Rechenzentren innerhalb akzeptabler Zeitlimits wieder online gebracht werden können.

Recovery Point Objective (RPO)

RPO definiert den maximal akzeptablen Datenverlust, gemessen als Zeitspanne. Bei einem RPO von 1 Stunde müssen Sie Daten bis mindestens 1 Stunde vor dem Eintreten des Notfalls wiederherstellen können.

Ein kürzeres RPO erfordert häufigere Backups oder eine kontinuierliche Replikation. Sie können Ihren Backup-Verlauf abfragen, um zu überprüfen, ob Sie Ihr RPO-Ziel einhalten.

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

Recovery Time Objective (RTO)

RTO definiert die maximal akzeptable Dauer, während der Ihr System nach einem Notfall offline sein darf. Bei einem RTO von 4 Stunden muss Ihre Datenbank innerhalb von 4 Stunden nach einem Ausfall wieder vollständig betriebsbereit sein.

Das RTO beeinflusst Entscheidungen über Standby-Server, Failover-Automatisierung und Wiederherstellungsverfahren. Wenn Sie die Dauer von Wiederherstellungen im Zeitverlauf erfassen, können Sie abschätzen, ob Sie Ihr RTO einhalten können.

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO vs. RTO — Der entscheidende Unterschied

Diese beiden Kennzahlen werden oft verwechselt. So können Sie sie sich am einfachsten merken:

RPO = Wie viele Daten können Sie sich leisten zu verlieren? (rückblickend, gemessen als Zeitspanne vor dem Notfall)
RTO = Wie lange können Sie sich einen Ausfall leisten? (vorausschauend, gemessen als Zeitspanne nach dem Notfall)

Zusammen definieren sie Ihr Wiederherstellungsfenster und beeinflussen direkt Ihre Backup-Häufigkeit, Replikationsstrategie und Ihr Infrastruktur-Budget.

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

Backup-Typen

Es gibt drei grundlegende Backup-Strategien, die jeweils ein anderes Verhältnis zwischen Geschwindigkeit und Speicherbedarf bieten:

Vollständiges Backup: Eine vollständige Momentaufnahme der gesamten Datenbank. Am langsamsten zu erstellen, am schnellsten wiederherzustellen.
Differenzielles Backup: Enthält nur die Änderungen seit dem letzten vollständigen Backup. Mittlere Geschwindigkeit in beide Richtungen.
Inkrementelles Backup: Enthält nur die Änderungen seit dem letzten Backup eines beliebigen Typs. Am schnellsten zu erstellen, am langsamsten wiederherzustellen, da mehrere Dateien benötigt werden.

Die meisten DR-Strategien kombinieren wöchentliche vollständige Backups mit täglichen inkrementellen Backups, um RPO und Speicherkosten ausgewogen zu halten.

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

Point-in-Time-Recovery (PITR)

Mit Point-in-Time-Recovery können Sie eine Datenbank auf einen beliebigen bestimmten Zeitpunkt zurücksetzen, nicht nur auf den Zeitpunkt des letzten Backups. Dazu werden Transaktionsprotokolle — in PostgreSQL das WAL — auf einem Basis-Backup erneut angewendet.

PITR ist unverzichtbar, wenn Sie sich von einer versehentlichen Datenbeschädigung oder dem versehentlichen Löschen von Daten zu einem bekannten Zeitpunkt erholen müssen. Sie können die Datenbank auf einen Zeitpunkt unmittelbar vor dem schädlichen Ereignis zurücksetzen.

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

Standby-Datenbanken und Replikation

Eine Standby-Datenbank (Replik) ist eine kontinuierlich aktualisierte Kopie der primären Datenbank, die auf separater Hardware ausgeführt wird. Sie erfüllt zwei DR-Zwecke:

Hot Standby: Kann Leseabfragen annehmen und innerhalb von Sekunden ein Failover durchführen (nahezu null RTO).
Warm Standby: Bleibt synchron, stellt aber keinen Datenverkehr bereit; das Failover dauert Minuten.

Die Überwachung des Replikationsrückstands ist entscheidend — eine zurückliegende Replik bedeutet, dass Ihr tatsächliches RPO schlechter ist als erwartet.

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

Runbooks: Wiederherstellungsverfahren dokumentieren

Ein Runbook ist eine dokumentierte Sammlung von Schritt-für-Schritt-Anweisungen, die eine zuständige Person während eines Disaster-Recovery-Ereignisses befolgt. Ohne Runbook machen selbst erfahrene Datenbankadministratoren unter Druck kostspielige Fehler.

Ein gutes DR-Runbook enthält: Kontaktpersonen, die betroffenen Systeme, die genau auszuführenden Befehle, die erwarteten Ausgaben bei jedem Schritt und Rollback-Verfahren für den Fall, dass die Wiederherstellung fehlschlägt. Wenn Sie Runbook-Metadaten in einer Datenbank speichern, können Sie Versionen nachverfolgen und die Nutzung prüfen.

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

Die Ausführung von Runbooks protokollieren

Jede Ausführung eines Runbooks — ob bei einem echten Notfall oder einer Übung — sollte protokolliert werden. Ausführungsprotokolle ermöglichen es Ihnen, die tatsächliche Dauer der Wiederherstellung zu messen (und damit Ihr RTO zu überprüfen), langsame oder fehleranfällige Schritte zu erkennen und die Einhaltung von Vorgaben gegenüber Prüfern nachzuweisen.

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

DR-Tests: Regelmäßige Übungen

Ein DR-Plan, der noch nie getestet wurde, ist kein Plan — sondern ein Wunsch. Regelmäßige Übungen sind unverzichtbar, um sicherzustellen, dass Ihr Team die Runbooks tatsächlich innerhalb des festgelegten RTO ausführen kann und dass sich die Backups wirklich wiederherstellen lassen.

Wenn Sie Übungen in Ihrer Datenbank planen und nachverfolgen, entsteht ein Prüfpfad. Außerdem erkennen Sie dadurch Runbooks, deren Tests überfällig sind.

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

Richtlinien zur Backup-Aufbewahrung

Aufbewahrungsrichtlinien legen fest, wie lange Backups aufbewahrt werden. Jedes Backup für immer aufzubewahren, verschwendet Speicherplatz; sie zu schnell zu löschen, verstößt gegen Ihre RPO- und Compliance-Anforderungen.

Eine gängige Richtlinie lautet: tägliche inkrementelle Backups 7 Tage lang, wöchentliche vollständige Backups 4 Wochen lang und monatliche vollständige Backups 12 Monate lang aufbewahren. Sie können die Aufbewahrung mithilfe von SQL-Abfragen für Ihr Backup-Protokoll durchsetzen und prüfen.

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

Kurztest

Testen Sie Ihr Verständnis der Definitionen von RPO und RTO.

Beantworte es in der interaktiven Lektion

Zusammenfassung: Disaster-Recovery-Planung

In dieser Lektion haben Sie die Grundlagen der Disaster-Recovery-Planung für Datenbanken kennengelernt:

RPO legt fest, wie viel Datenverlust in zeitlicher Hinsicht maximal tolerierbar ist. Ein kürzeres RPO erfordert häufigere Backups oder eine kontinuierliche Replikation.
RTO legt fest, wie schnell das System wiederhergestellt werden muss. Ein kürzeres RTO erfordert Hot Standbys und ein automatisiertes Failover.
Sicherungstypen – vollständig, differentiell und inkrementell – bieten jeweils unterschiedliche Abwägungen zwischen Speicherbedarf, Erstellungsgeschwindigkeit und Wiederherstellungsgeschwindigkeit.
PITR (Point-in-Time-Recovery) verwendet Transaktionsprotokolle, um den Zustand zu einem beliebigen genauen Zeitpunkt wiederherzustellen und so vor versehentlichen Änderungen zu schützen.
Runbooks dokumentieren jeden Schritt eines Wiederherstellungsverfahrens. Die Protokollierung der Ausführungen bestätigt, dass Ihr RTO in der Praxis erreichbar ist.
Regelmäßige DR-Übungen sind die einzige Möglichkeit zu bestätigen, dass Backups wiederhergestellt werden können und Ihr Team RPO- und RTO-Ziele auch unter realem Druck erreicht.
Aufbewahrungsrichtlinien stellen ein Gleichgewicht zwischen Speicherkosten sowie Compliance- und Wiederherstellungsanforderungen her.

Ein gut getesteter DR-Plan gehört zu den wertvollsten Investitionen, die ein Datenbankteam tätigen kann.

Kostenlos starten

Lerne SQL mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 46
Lektionen: 183

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Notfallwiederherstellungsplanung“ kostenlos?

Ja — der vollständige Text von „Notfallwiederherstellungsplanung“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Notfallwiederherstellungsplanung“?

RPO, RTO und Runbooks Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Academy zu starten?

Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Notfallwiederherstellungsplanung“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?

Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Logische vs. physische Backups
Wiederherstellung zu einem bestimmten Zeitpunkt
Ihre Wiederherstellungen testen
Notfallwiederherstellungsplanung

← Zurück zu SQL Academy