Backup, Upgrade und Betriebsnachweise

Herausforderung

Ohne Restore-Test und Upgrade-Runbook ist „Produktion“ nur eine lange laufende PoC. Stale Ingestion und fehlgeschlagene Connectoren bleiben unsichtbar, bis Consumer es merken. Auth (Teil 6) und Deploy-Härte (Teile 4–5) helfen wenig, wenn niemand beweisen kann, dass der Katalog nach einem Disk-Ausfall oder Major-Upgrade wiedersteht.

Typische Symptome:

• Backups laufen „irgendwo“, Restore wurde nie geübt.
• Upgrade wird kurzfristig direkt auf Produktion gemacht.
• Connector-Failures landen nur in Logs, die niemand liest.
• On-Call ist „das Platform-Team“ ohne Namen und ohne Connector-verantwortliche Person.

Ansatz

Betriebsreife an Nachweisen festmachen — unabhängig von On-Prem oder Cloud:

Backup → Restore-Test
Upgrade-Runbook → Staging-Probe
Monitoring → Alert → On-Call
Freshness-SLO → Connector-Owner

Was genau sichern?

Mindestens:

1. Metadata Store (Entitäten, Users/Teams-Bezug, Policies — je nach Setup).
2. Search-Index oder reproduzierbarer Reindex-Pfad nach Restore.
3. Konfiguration von Server, Ingestion und Secret-Referenzen (nicht Klartext-Secrets in Backup-Tickets).
4. Bei Self-hosted: Volumes/Snapshots und Object-Storage-Ziele; bei SaaS: Vendor-RPO/RTO und euer Export-Pfad.

Dokumentiert RPO/RTO als Ziel — auch wenn die erste Version grob ist. Ohne Zahl gibt es keinen Streitwert bei Incidents.

Empfohlenes Vorgehen

1. Backup-Job aktivieren und Aufbewahrung (Tage/Wochen) festlegen.
2. Restore auf Staging üben: Datum, Dauer, beteiligte Personen, bekannte Lücken (z. B. Reindex-Zeit).
3. Upgrade-Runbook schreiben: Versionsmatrix, Breaking Changes, Staging-Probe, Rollback, Kommunikationsplan.
4. Ingestion-Monitoring: Failure-Alert und Stale-Alert (letzte erfolgreiche Laufzeit vs SLO).
5. On-Call-Matrix: Platform für Betrieb; Connector-Owner für Source-Rechte und Scope.
6. Kapazität: Search-Heap, Disk, parallele Jobs — Schwellen und Escalation.
7. Nach jedem Major-Upgrade: Smoke (Login, Search, ein Connector) und kurzer Postmortem nur bei Abweichung.

Freshness und Verantwortung

Ein grüner Server mit roten oder stillen Jobs ist kein Katalogprodukt. Freshness-SLOs (z. B. „Warehouse-Metadata ≤ 24h alt“) brauchen einen Owner. Platform owned die Runner-Plattform; Domänen owned den Connector-Scope und die Source-Credentials — dieselbe Trennung wie in Teil 4 und in openmetadata-connectors.

Häufige Anti-Patterns

• Backup ohne Restore-Test.
• Upgrade nur auf Produktion, „weil Staging fehlt“.
• Nur Failure-Alerts, keine Stale-Alerts.
• Ein On-Call für alles ohne Connector-verantwortliche Person.
• Secrets im Backup-Ticket oder im Runbook-Wiki im Klartext.

Troubleshooting-Hinweise

• Restore dauert zu lang: parallele Restore-Pfade, Reindex vs Snapshot des Search-Clusters prüfen.
• Nach Upgrade UI ok, Connectoren tot: Ingestion-Version/Compat und Secret-Refs prüfen.
• Alert-Sturm: Thresholds und Deduplizierung; Stale vs Failure trennen.
• SaaS: Dienstleister-Statusseite und eure Export-/Support-Pfad parallel zum eigenen Runbook halten.

Hilfe beim Umsetzen

Plant einen halben Tag Staging: Restore üben → Dauer notieren → einen Ingestion-Smoke mit OpenMetadata-Ingestions-Generator-Job → Login/Search prüfen. Upgrade-Runbook als Checkliste mit Rollback-Zeile.

Alerts: getrennte Regeln für Failure und Stale. On-Call-Namen (Menschen) neben Connector-Owner — nicht nur Team-Alias.

Checkliste vor „wir sind prod-ready“

• Restore-Test datiert und erfolgreich?
• Upgrade-Runbook und Staging-Probe vorhanden?
• Failure- und Stale-Alerts aktiv und getestet?
• On-Call-Namen (nicht nur Team-Alias) bekannt?
• RPO/RTO und Backup-Aufbewahrung schriftlich?
• Teil 6 (SSO/Secrets) und Deploy-Pfad (Teil 1) abgeschlossen?

Artefakt

Production Readiness Pack: Restore-Protokoll, Upgrade-Runbook, Alert-Liste, On-Call-Matrix, RPO/RTO-Eintrag im Deploy-Record.

Tools

• OpenMetadata Deployment — Backup-/Upgrade-Hinweise der gewählten Betrieb.
• OpenMetadata-Ingestions-Generator — standardisierte Ingestion-Jobs für Freshness-Smoke nach Restore/Upgrade.
• Alertmanager/Pager + Staging (intern) — Stale/Failure und Restore-Proben.

Ressourcen

• OpenMetadata Deployment
• Interne Change-/Incident-Prozesse eurer Organisation