ostrelle
Menü

OSTRELLE · LERNEN · MIT ÜBUNGEN

3. Sicherung und Wiederherstellung nachweisen

Du wählst den richtigen Datenbankoperator und definierst einen echten Restoreabschluss. Mit konkreten Schritten, eigener Übung, Musterlösung und Erfolgskontrolle.

Eine Testinstanz verantwortlich betreiben · Lektion 3 von 4 · Quellstand 3. November 2026

Das lernst du

Du wählst den richtigen Datenbankoperator und definierst einen echten Restoreabschluss.

SQLite, SQLite→PostgreSQL-Transfer und nativer PostgreSQL-Restore sind unterschiedliche Verfahren. database_transfer übernimmt eine gestoppte aktuelle SQLiteinstallation in eine frische PG-Datenbank. database_backup sichert PG und den definierten Runtimeumfang verschlüsselt. Keine dieser Aktionen ist automatisch eine Umschaltung deiner laufenden Website.

Der Restore prüft einen unabhängigen Cipherhashkatalog und stellt in ein neues Ziel wieder her. Die Quarantänemarke verhindert einen normalen Start, solange die vorgesehene Prüfung fehlt. Eine alte Sicherung kann zwischenzeitlich gelöschte Daten oder widerrufene Zugänge enthalten. Deshalb ist „Datei wieder da“ nicht gleich „Betrieb freigegeben“.

Schritt für Schritt

  1. Lies tools/database-ops/README.md vollständig. Bestimme Backend, Servermajor, Runtimeumfang, Trustkatalog, getrennte Rollen und Schlüsselort deiner synthetischen Testinstanz. Die nachfolgenden konkreten Aufrufe setzen PG16, vorhandene eigene Testrollen und ausschließlich synthetische Daten voraus. WPNEXT_OP_PG_HOST/PORT/DATABASE/MIGRATION_USER und RUNTIME_USER sowie deren geschützte Zugangswerte stammen aus deiner Betreiberkonfiguration.
  2. Baue database_transfer und database_backup aus demselben Stand wie den Server. Führe ihre Prüfung ausschließlich unter den dokumentierten Voraussetzungen aus.
  3. Beende alle Schreiber. Sichere die definierten Dateien und Daten verschlüsselt in ein neues privates Ziel. Bestätigungsschalter ersetzen das tatsächliche Stoppen nicht.
  4. Restauriere mit dem dokumentierten Operator in eine neue dedizierte Datenbank und ein neues Runtimeverzeichnis. Belasse die Quarantäne bis zur vorgesehenen Freigabeprüfung.
  5. Prüfe Inhalt, Medien, Sitezuordnung, Rechte, Versionen und abgeschaltete externe Zustellung. Vergleiche tatsächliche Daten statt bloßer Dateinamen.
  6. Notiere Sicherungszeitpunkt, Softwarecommit, Restoreziel, Ergebnis und ungelöste Widerrufs-/Löschfragen. Behalte das Original bis zur getrennten Umschaltentscheidung.
cargo build --locked -p wpnext-server \
  --example database_transfer --example database_backup
# Vorher: alle Schreiber deiner synthetischen PG-Testinstanz stoppen.
# Die folgenden Werte bezeichnen DEINE bestehenden Testressourcen:
: "${kurs_runtime:?Pfad zur gestoppten PG-Testruntime setzen}"
: "${instance_uuid:?Tatsaechliche Instanz-ID setzen}"
: "${age_public_recipient:?Eigenen oeffentlichen age-Empfaenger setzen}"
: "${private_identity_file:?Pfad zum getrennt geschuetzten age-Schluessel setzen}"
: "${new_database:?Frische dedizierte PG-Zieldatenbank benennen}"
# PG-Operatorzugang gemaess README aus geschuetzter Konfiguration laden;
# keine Kennwoerter als Argumente oder in dieser Datei speichern.
private_root=$(mktemp -d "${TMPDIR:-/tmp}/ostrelle-backupkurs.XXXXXX")
chmod 700 "$private_root"
cipher="$private_root/cipher"
catalogue="$private_root/catalogue"
alerts="$private_root/alerts"
mkdir -m700 "$alerts"
"${CARGO_TARGET_DIR:-target}/debug/examples/database_backup" backup \
  --source "$kurs_runtime" --backup-dir "$cipher" \
  --trust-dir "$catalogue" --alarm-file "$alerts/events.jsonl" \
  --mode postgres --server-major 16 --instance-id "$instance_uuid" \
  --recipient "$age_public_recipient" --confirm-offline
# Nimm die tatsaechliche run-ID aus der erfolgreichen Operatorausgabe.
: "${run_uuid:?Tatsaechliche Sicherungs-run-ID setzen}"
new_runtime="$private_root/restore"
"${CARGO_TARGET_DIR:-target}/debug/examples/database_backup" restore \
  --backup-dir "$cipher" --trust-dir "$catalogue" \
  --alarm-file "$alerts/events.jsonl" --run "$run_uuid" \
  --identity "$private_identity_file" --destination "$new_runtime" \
  --target-database "$new_database" --confirm-quarantine
# Quarantaene bleibt bestehen. Keine manuelle Guardentfernung.
# Servermajor 16 gilt fuer die im Kurs vorausgesetzte PG16-Testinstanz.

Deine Übung

Eine Archivdatei liegt bereit und lässt sich entschlüsseln. Welche zusätzlichen Beobachtungen brauchst du, um eine brauchbare Wiederherstellung zu melden?

Musterlösung und Erklärung

Du benötigst einen erfolgreichen Abgleich mit dem unabhängigen Cipherhashkatalog, eine erfolgreiche atomare Datenübernahme, verifizierte Tabellen-/Dateiprüfsummen und echte Anwendungsprüfungen am isolierten Ziel. Zur Prüfung gehören auch private Medien, Mitgliedschaften und der korrekte Mailzustand.

Bei einem zwischenzeitlichen Widerruf genügt das Datum nicht. Der vorgesehene maßgebliche neuere Vollstand muss separat bestätigt sein; unbekannte Fälle bleiben gesperrt. Entferne die Quarantänemarke nicht von Hand und behaupte keinen Erfolg allein aus Entschlüsselbarkeit.

So prüfst du dein Ergebnis

  • Der Sicherungsumfang und das tatsächlich verwendete Backend sind bekannt.
  • Ein neues Ziel wurde wirklich wiederhergestellt und geprüft.
  • Quarantäne und Widerrufsprüfung wurden nicht umgangen.

← Vorherige Lektion · Kursübersicht · Nächste Lektion →