0Pricing
SQL Academy · Lektion

Ihre Wiederherstellungen testen

Ein Backup, das Sie nicht wiederherstellen können, ist nutzlos.

Ihre Wiederherstellungen testen ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 3 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.

Ein Backup, das Sie nicht wiederherstellen können, ist wertlos

Viele Teams investieren Zeit in die Einrichtung automatisierter Backups, überprüfen aber nie, ob sich diese Backups tatsächlich zur Wiederherstellung von Daten verwenden lassen. Ein Backup, das bei der Wiederherstellung fehlschlägt, ist überhaupt kein Backup.

In dieser Lektion geht es um die konsequente Durchführung von Wiederherstellungstests: Sie lernen, wie Sie überprüfen, ob Ihre Backups funktionieren, bevor ein echter Notfall Sie dazu zwingt, es auf die harte Tour herauszufinden.

Was umfasst ein Wiederherstellungstest?

Bei einem Wiederherstellungstest wird eine Backup-Datei in eine Datenbank geladen — typischerweise in eine separate Testinstanz. Anschließend werden Abfragen an diese Datenbank gesendet, um zu bestätigen, dass die Daten vollständig und konsistent sind.

Die Schritte sind: 1) Beschaffen Sie die Backup-Datei. 2) Stellen Sie sie in einer Sandbox-Umgebung wieder her. 3) Führen Sie Prüfungsabfragen aus. 4) Vergleichen Sie die Ergebnisse mit der Produktionsumgebung.

Eine Basisaufnahme zum Vergleich erstellen

Bevor Sie eine Wiederherstellung überprüfen können, benötigen Sie eine Basis — eine bekannte Menge von Zeilenzahlen und Prüfsummen aus der Produktionsumgebung, mit der Sie die wiederhergestellte Kopie vergleichen können.

Führen Sie dies in Ihrer Produktionsdatenbank aus und protokollieren Sie die Ergebnisse:

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Zeilenzahlen nach der Wiederherstellung überprüfen

Sobald das Backup in einer Testdatenbank wiederhergestellt wurde, führen Sie dieselbe Abfrage aus und vergleichen Sie die Zahlen. Stimmen die Anzahlen überein, ist die grundlegende Struktur der Wiederherstellung intakt.

Eine Abweichung zeigt Ihnen sofort, dass während der Sicherung oder Wiederherstellung Daten verloren gegangen sind — noch bevor Sie die Produktionsumgebung überhaupt berühren.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Die neuesten Daten überprüfen

Zeilenzahlen bestätigen die Menge, nicht jedoch die Aktualität. Überprüfen Sie, ob die wiederhergestellte Datenbank aktuelle Datensätze enthält — das Backup sollte die Daten bis zu dem Zeitpunkt widerspiegeln, zu dem es erstellt wurde.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

Die referenzielle Integrität überprüfen

Auch wenn die Zeilenzahlen übereinstimmen, kann eine Wiederherstellung verwaiste Zeilen hinterlassen — untergeordnete Datensätze, deren übergeordneter Datensatz nicht mehr existiert. Dies geschieht häufig, wenn Fremdschlüssel während der Sicherung oder Wiederherstellung nicht erzwungen werden.

Verwenden Sie einen LEFT JOIN, um verwaiste Bestellpositionen zu erkennen:

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

Beschädigungen mit einer Prüfsumme erkennen

Erstellen Sie für kritische Tabellen eine Prüfsumme der Daten, um Beschädigungen auf Bit-Ebene zu erkennen. In PostgreSQL können Sie MD5 mit einer Umwandlung der gesamten Zeile kombinieren.

Unterscheidet sich die Prüfsumme aus der Produktionsumgebung von der der wiederhergestellten Kopie, wurden die Daten irgendwann verändert oder beschädigt.

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

Eine Tabelle zur Wiederherstellungsprüfung erstellen

Um den Verlauf Ihrer Wiederherstellungstests zu verfolgen, erstellen Sie eine eigene Tabelle für das Prüfungsprotokoll. Erfassen Sie jeden Testlauf mit dem Backup-Datum, den wiederhergestellten Zeilenzahlen und dem Ergebnis der Prüfung.

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

Ein Prüfergebnis einfügen

Fügen Sie nach jedem Wiederherstellungstest eine Zeile in das Prüfungsprotokoll ein. Dadurch entsteht ein Prüfpfad, der belegt, dass die Backups getestet wurden, und im Zeitverlauf eine Folge von erfolgreichen und fehlgeschlagenen Tests zeigt.

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

Den Prüfungsverlauf abfragen

Überprüfen Sie das Prüfungsprotokoll regelmäßig, um Rückschritte zu erkennen. Wenn ein Backup, das letzte Woche erfolgreich war, diese Woche fehlschlägt, deutet dies auf ein Problem in Ihrer Backup-Pipeline hin, das sofort untersucht werden muss.

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

Die Point-in-Time-Recovery überprüfen

Moderne Datenbanken unterstützen Point-in-Time-Recovery (PITR). Damit können Sie eine Datenbank mithilfe eines Basis-Backups und von WAL-Archiven (Write-Ahead-Log-Archiven) auf jeden beliebigen Zeitpunkt zurücksetzen.

Um zu überprüfen, ob PITR funktioniert, stellen Sie die Datenbank auf einen bekannten Zeitstempel wieder her und prüfen Sie, dass ein nach diesem Zeitstempel erstellter Datensatz NICHT in der wiederhergestellten Datenbank erscheint:

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

Kurztest

Welche der folgenden Abfragen eignet sich am besten, um nach der Wiederherstellung eines Backups verwaiste untergeordnete Datensätze zu erkennen?

Zusammenfassung der Lektion: Wiederherstellungen testen

In dieser Lektion haben Sie gelernt, warum Wiederherstellungstests ein verpflichtender Bestandteil jeder Backup-Strategie sind und wie Sie sie mit SQL umsetzen:

  • Basisaufnahmen — Erfassen Sie vor dem Testen die Zeilenzahlen der Produktionsumgebung.
  • Vergleich der Zeilenzahlen — Führen Sie dieselbe Abfrage in der wiederhergestellten Datenbank aus und vergleichen Sie die Ergebnisse.
  • Prüfung der Aktualität — Bestätigen Sie, dass die neuesten Datensätze mit dem erwarteten Sicherungszeitraum übereinstimmen.
  • Referenzielle Integrität — Verwenden Sie LEFT JOIN, um verwaiste untergeordnete Zeilen zu finden.
  • Prüfung der Prüfsumme — Erkennen Sie Beschädigungen auf Bit-Ebene mithilfe von MD5-Aggregationen.
  • Tabelle für Prüfungsprotokolle — Verfolgen Sie jeden Testlauf für einen prüfbaren Verlauf.
  • PITR-Überprüfung — Bestätigen Sie, dass die Point-in-Time-Recovery am richtigen Zeitpunkt endet.

Ein Backup ist nur so gut wie der letzte erfolgreiche Wiederherstellungstest. Planen Sie diese Prüfungen regelmäßig und behandeln Sie jeden Fehler als kritischen Vorfall.

Häufig gestellte Fragen

Ist die Lektion „Ihre Wiederherstellungen testen“ kostenlos?

Ja — der vollständige Text von „Ihre Wiederherstellungen testen“ 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 „Ihre Wiederherstellungen testen“?

Ein Backup, das Sie nicht wiederherstellen können, ist nutzlos. 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 3 von 4.

Wie lange dauert die Lektion „Ihre Wiederherstellungen testen“?

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

  1. Logische vs. physische Backups
  2. Wiederherstellung zu einem bestimmten Zeitpunkt
  3. Ihre Wiederherstellungen testen
  4. Notfallwiederherstellungsplanung
← Zurück zu SQL Academy