Backup-Governance in der Praxis: Verantwortlichkeiten, Dokumentation und Audit-Checkliste

Backup-Governance ist der Teil von Backup-Management, der in der Praxis am häufigsten fehlt: klare Verantwortlichkeiten, nachvollziehbare Dokumentation und wiederholbare Kontrollen. Viele Teams haben zwar Sicherungsjobs, Storage und ein Tool – aber keine belastbare Antwort auf die Fragen „Wer entscheidet was?“, „Wie wird geprüft?“ und „Woran erkennen wir im Audit, dass Wiederherstellung wirklich funktioniert?“. Genau dort setzt dieser Beitrag an: mit einem praxistauglichen Rollenmodell, einer schlanken, aber vollständigen Dokumentationsstruktur und einer Audit-Checkliste, die Sie im Betrieb nutzen können – nicht nur im Prüfungsfall.

Der Fokus liegt bewusst auf Alltagsthemen für Administratoren, System Engineers, Operatoren und technische IT-Dienstleister: Ursachen typischer Backup-Probleme, Voraussetzungen für verlässliche Restores, Risiken bei Änderungen und Migrationen, Prüfschritte, Umsetzung und Rückfallstrategie. Für die Kategorie MariaDB greifen wir außerdem Datenbank-spezifische Punkte auf, weil „Backup erfolgreich“ dort ohne Konsistenz- und Restore-Validierung wenig aussagt.

Warum Backup-Governance mehr ist als ein Konzept

Ohne Governance entsteht ein gefährlicher Zustand: Backups laufen, Reports sind grün, aber die Organisation ist nicht in der Lage, im Incident schnell und korrekt zu entscheiden. Das Scheitern passiert dann selten am Tool, sondern an Lücken in Zuständigkeit und Beweiskette:

• Unklare Prioritäten: Welche Systeme werden zuerst wiederhergestellt, wenn Storage, Netzwerk oder Identitätssysteme betroffen sind?
• Fehlende Nachvollziehbarkeit: Welche Konfiguration galt zu welchem Zeitpunkt (Retention, Verschlüsselung, Exclusions, Credentials)?
• Keine belastbaren Restore-Übungen: „Wir könnten restore’n“ wird nicht durch Testläufe mit Erfolgskriterien gedeckt.
• Audit-Risiko: Ohne Dokumentation und Nachweise (Logs, Testprotokolle, Change-Historie) sind Anforderungen an Verfügbarkeit, Datenschutz oder Aufbewahrung kaum prüfbar.

Governance bedeutet hier nicht Bürokratie, sondern operationalisierte Verlässlichkeit: Entscheidungen sind zugeordnet, Prozesse sind dokumentiert, Kontrollen sind wiederholbar und die Ergebnisse werden nachweisbar abgelegt.

Backup-Governance: Rollen, Verantwortlichkeiten und Entscheidungspunkte

In der Praxis funktioniert Backup-Governance am besten mit wenigen, klar abgegrenzten Rollen. Wichtig: Rollen sind Aufgabenpakete – sie müssen nicht mit Stellen oder Personen identisch sein. Entscheidend ist, dass jede Aufgabe genau einmal eindeutig zugeordnet ist.

Rollenmodell (kompakt, praxistauglich)

• Service Owner (System-/Applikationsverantwortung): definiert Schutzbedarf, RTO/RPO (Zielwerte für Wiederanlaufzeit und maximalen Datenverlust), Datenklassifizierung und Abhängigkeiten (z. B. Identity, DNS, Storage, Key-Management).
• Backup Owner (Betriebsverantwortung Sicherung): verantwortet Policies (Retention, Verschlüsselung, Immutability), Job-Design, Monitoring/Alerting, Kapazitätsplanung, Restore-Prozesse und Nachweise.
• Storage/Plattform Owner: verantwortet Performance, Snapshot-/Replikationsmechanismen, Medien, WORM/Immutable-Funktionen (Write Once Read Many, unveränderbare Ablage) und Zugriffsmodelle.
• Security/Compliance (kontrollierend, nicht „macht es“): definiert Mindestanforderungen (z. B. MFA, getrennte Admin-Konten, Protokollierung), prüft Stichproben, bewertet Abweichungen.
• Operator/On-Call: führt Runbooks aus, reagiert auf Alarme, sammelt Incident-Daten, eskaliert anhand definierter Schwellen.

RACI-Matrix als Minimum: wer macht, wer entscheidet, wer muss informiert werden?

Eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) verhindert Grauzonen. Typische Entscheidungspunkte, die Sie explizit zuordnen sollten:

• Freigabe/Änderung von Retention und Aufbewahrungsorten (lokal, Offsite, Cloud, Band).
• Definition der Restore-Priorität (Tiering: Tier-0/1/2-Systeme).
• Ausnahmen (z. B. „kein tägliches Full“, „keine Offsite-Kopie“): wer genehmigt und wie wird das Risiko dokumentiert?
• Credential- und Key-Management (Backup-Admin, Storage-Admin, Verschlüsselungskeys, Break-Glass-Zugänge).

Stolperfalle: In vielen Umgebungen entscheidet „der, der es gerade macht“. Das wirkt schnell, erzeugt aber Audit- und Incident-Risiko, weil Änderungen nicht mehr rückverfolgbar sind.

Dokumentation, die im Betrieb hilft (und nicht nur im Audit)

Backup-Dokumentation scheitert selten an fehlenden Tools, sondern an falschem Umfang. Zu viel Dokumentation wird nicht gepflegt, zu wenig ist wertlos. Ein gutes Ziel ist: jede kritische Entscheidung ist nachvollziehbar und jeder Restore ist als Prozess dokumentiert.

1) Systemschutzblatt pro Service (1–2 Seiten, aber vollständig)

Für jedes relevante System oder jede prozessnahe Softwarelösung erstellen Sie ein Schutzblatt. Das ist kein Handbuch, sondern ein Betriebssteckbrief:

• Business-Kontext: Zweck, Datenarten (personenbezogen, geschäftskritisch), Ansprechpartner.
• RTO/RPO: Zielwerte, begründet durch Prozessanforderungen.
• Abhängigkeiten: DNS, AD/LDAP, NTP, Storage, Key-Management, Netzwerksegmente.
• Backup-Methodik: Agent-basiert, Snapshot-basiert, DB-nativ, Datei-basiert; inkl. Konsistenzmechanismus.
• Restore-Varianten: Datei-Restore, VM-Restore, Bare-Metal, DB-Restore, Point-in-Time.
• Testfrequenz: welche Restore-Übungen, wie oft, Erfolgskriterien.

Warum das funktioniert: In Incidents sind RTO/RPO-Diskussionen zu spät. Das Schutzblatt bringt die Entscheidung nach vorne und macht Abhängigkeiten sichtbar, die Restore-Zeiten dominieren (z. B. fehlender Zugriff auf Schlüsselmaterial oder gesperrte Admin-Konten).

2) Backup-Policy als lebendes Dokument (Versionierung, Change-Historie)

Die Policy ist die „Betriebsverfassung“ Ihrer Backups. Sie sollte versioniert sein (z. B. in Git oder im Change-Management-System) und mindestens abdecken:

• Retention-Logik: z. B. GFS (Grandfather-Father-Son: täglich/wöchentlich/monatlich), Sonderregeln für Monats-/Jahresstände.
• Schutz gegen Manipulation: Immutable/WORM, getrennte Rollen, separate Admin-Konten, MFA.
• Verschlüsselung: in Transit (Transport) und at Rest (Speicher), Key-Ownership und Rotation.
• Offsite-Regel: zweite Kopie, getrennte Sicherheitsdomäne, definierter Restore-Pfad ohne Produktiv-Identität.
• Monitoring & Eskalation: Schwellen, Zeitfenster, On-Call-Übergaben.

Stolperfalle: Policies existieren, aber niemand kann zeigen, wann sie geändert wurden oder ob Systeme abweichen. Governance verlangt nicht Perfektion, sondern Transparenz: Abweichungen müssen sichtbar und bewertet sein.

3) Runbooks: Restore ist ein Prozess, kein Klick

Ein Runbook ist eine schrittweise Anleitung für wiederholbare Tätigkeiten, inklusive Voraussetzungen, Prüfungen und Rückfallpfad. Für Backups sind mindestens zwei Runbooks sinnvoll:

• „Standard-Restore“ (häufig): Dateien, einzelne DBs/Schemas, VM-Objekte, Konfigurationsstände.
• „Disaster-Restore“ (selten, aber kritisch): komplette Umgebung, Identität, Netzwerk-Grundfunktionen, Key-Management, Recovery-Cluster.

Wichtig: Ein gutes Runbook enthält nicht nur Schritte, sondern auch Validierung (Woran sehe ich, dass es funktioniert?) und Abbruchkriterien (Wann stoppe ich und eskaliere?).

Typische Stolperfallen aus dem Betrieb (und wie Sie sie entschärfen)

„Backup erfolgreich“ heißt nicht „Restore möglich“

Viele Tools melden Job-Erfolg, wenn Daten weggeschrieben wurden. Das sagt aber nichts über Lesbarkeit, Vollständigkeit oder Anwendungs-Konsistenz aus. Ursachen:

• defekte oder unvollständige Ketten (inkrementell/differenziell),
• fehlende Metadaten (ACLs, Extended Attributes, Eigentümer),
• nicht konsistente Snapshots (Applikation schreibt während Snapshot),
• verschlüsselte Backups ohne getesteten Key-Restore.

Gegenmaßnahme: Restore-Tests als Pflichtkontrolle, mit definierten Erfolgskriterien (z. B. Hash-Checks, Applikations-Health, DB-Integrität).

Credential- und Key-Management ist der häufigste „unsichtbare“ Single Point of Failure

Backups scheitern im Ernstfall oft daran, dass:

• Backup-Admin-Konten im Incident gesperrt sind (Ransomware-Reaktion),
• MFA/Conditional Access den Notfallzugang verhindert,
• Verschlüsselungskeys nicht verfügbar oder nicht dokumentiert sind,
• Secrets im gleichen Vault liegen, der selbst wiederhergestellt werden müsste.

Praxisregel: Für Recovery müssen Sie einen Break-Glass-Pfad (definierter Notfallzugang) dokumentieren, technisch absichern (z. B. separate Tokens, Offline-Notfallmaterial) und regelmäßig testen.

Retention, Aufbewahrung und Kosten laufen auseinander

Retention ist nicht nur „wie lange“, sondern auch „wo“ und „in welcher Form“. Ohne Governance entstehen typische Effekte: zu kurze Aufbewahrung (Audit-Risiko) oder ungeplante Kosten (zu lange Aufbewahrung auf teurem Storage). Entscheidend ist eine Regelung für:

• kurzfristige Wiederherstellung (schnell, nahe am Produktivsystem),
• mittelfristige Stände (Offsite, günstiger, aber restorebar),
• Langzeit (Archiv), mit klarer Trennung von Backup vs. Archiv (Archiv ist oft unveränderbar und zweckgebunden).

MariaDB-spezifische Governance-Punkte: Konsistenz, Binlogs und Point-in-Time-Restore

Bei MariaDB ist Governance besonders wichtig, weil mehrere Mechanismen zusammenspielen: physische Backups (z. B. Percona XtraBackup), logische Exporte (z. B. mysqldump) und Binlogs (Binary Logs, Änderungsprotokolle auf Transaktionsebene). Ohne klare Regeln bekommen Sie zwar Daten weg, aber keinen reproduzierbaren Wiederherstellungszeitpunkt.

Minimum für MariaDB: Was muss dokumentiert sein?

• Backup-Typ: physisch (schneller Restore, nah an Storage-Struktur) vs. logisch (portabler, langsamer).
• Konsistenzmethode: Hot-Backup, Snapshot mit Freeze, oder kontrolliertes Stoppen; inkl. Risiken für Datenkorruption.
• Binlog-Strategie: Binlog-Retention, Offsite-Kopie, Zuordnung zu Full-Backups.
• PITR-Prozess: Point-in-Time-Restore (Wiederherstellung auf einen Zeitpunkt) inklusive „Stop-Time“ und Prüfschritten.
• Versionen und Kompatibilität: MariaDB-Version, Storage Engine (InnoDB etc.), Backup-Tool-Version; relevant bei Restore auf neue Plattform.

Prüfschritte, die sich im Alltag bewähren

Diese Checks sind einfach genug, um sie regelmäßig zu fahren, aber aussagekräftig:

• Backup-Artefakte vorhanden? Full-Backup + zugehörige Metadaten + Binlogs für PITR.
• Binlog-Lücke? Zeitfenster ohne Binlogs macht PITR unmöglich.
• Restore-Probe: Wiederherstellung in isolierter Testumgebung, dann Integritäts- und Plausibilitätschecks.

Beispiel: Prüfen, ob Binlogs aktiv sind und wie lange sie vorgehalten werden (vereinfachtes Beispiel, je nach Setup anpassen):

-- Binlog-Status und relevante Parameter prüfen
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW MASTER STATUS;

Warum das funktioniert: Ohne aktive Binlogs oder mit zu kurzer Aufbewahrung können Sie zwar einen Full-Stand zurückholen, aber nicht „bis kurz vor den Incident“ nachziehen. Wann es scheitert: Wenn Binlogs zwar aktiv sind, aber nicht konsistent Offsite gesichert werden oder durch Storage-/Replikationsfehler Lücken entstehen.

Troubleshooting: typische MariaDB-Fallen bei Restore-Tests

• Fehlende Abhängigkeiten: Restore-Host hat andere libc/OpenSSL-Versionen, andere Dateisystem-Optionen oder andere I/O-Limits; der Restore dauert länger als geplant.
• Rechte/ACLs: Datenverzeichnis gehört nicht korrekt dem DB-User; Start scheitert oder es entstehen Folgeprobleme.
• Time-Skew: NTP-/Zeitdrift führt zu falscher „Stop-Time“ bei PITR und erschwert Audit-Nachweise.
• Zu wenig Platz: Restore benötigt kurzfristig mehr Kapazität (Entpacken, Prepare-Phase, temporäre Dateien).

Governance heißt hier: Diese Risiken stehen nicht nur in Köpfen, sondern in Runbooks – inklusive Abbruchkriterien und Alternativpfad (z. B. Restore auf größeres temporäres Volume, danach Migration).

Kontrollen und Nachweise: Was Sie regelmäßig prüfen sollten

Governance lebt von Kontrollen. Wichtig ist die Trennung zwischen:

• Präventivkontrollen (verhindern Fehler): Policy, Change-Management, Rollen, Härtung.
• Detektivkontrollen (finden Fehler): Monitoring, Reports, Stichproben, Restore-Tests.
• Korrekturkontrollen (beheben Fehler): Incident-Prozess, Problem-Management, Maßnahmen-Tracking.

Monitoring/Alerting: Alarme, die wirklich helfen

Ein funktionierendes Backup-Monitoring alarmiert nicht „alles“, sondern das, was die Wiederherstellbarkeit gefährdet:

• Job-Fehlschlag oder wiederholt „warn“ ohne Ticket.
• fehlende Offsite-Kopie innerhalb des vereinbarten Fensters.
• Immutable/WORM nicht aktiv oder Policy geändert.
• Kapazitäts- und Wachstumstrends (Zeit bis „voll“), getrennt nach Backup-Tier.
• Restore-Tests überfällig oder fehlgeschlagen.

Stolperfalle: Viele Teams überwachen nur Job-Exit-Codes. Governance verlangt „Restore-Readiness“-Signale, also Indikatoren, die direkt an Wiederherstellbarkeit gekoppelt sind.

Audit-Checkliste Backup-Governance (operativ nutzbar)

Die folgende Audit-Checkliste ist so formuliert, dass Sie sie intern als Self-Assessment nutzen können. Für jeden Punkt sollten Sie nicht nur „ja/nein“, sondern auch wo ist der Nachweis? dokumentieren (Link auf Ticket, Report, Repo, Log-Ablage).

A) Organisation & Verantwortlichkeiten

• Rollen sind definiert (Service Owner, Backup Owner, Security/Compliance, Operator) und aktuell.
• RACI-Matrix existiert und deckt Retention, Restore-Priorisierung, Ausnahmegenehmigungen ab.
• Eskalationswege sind dokumentiert (inkl. Zeitfenster, On-Call-Übergabe, Incident-Lead).
• Break-Glass-Zugänge für Recovery existieren, sind getrennt abgesichert und getestet.

B) Scope & Klassifizierung

• Inventar: Welche Systeme, Datenbanken, Fileshares, Plattformen sind im Backup-Scope?
• Datenklassifizierung je Service ist dokumentiert (z. B. personenbezogen, vertraulich, kritisch).
• RTO/RPO sind je Service festgelegt und in Restore-Runbooks umgesetzt (nicht nur „Wunschwerte“).

C) Technik & Security Controls

• Verschlüsselung in Transit und at Rest ist umgesetzt; Key-Ownership/Rotation ist dokumentiert.
• Immutable/WORM oder gleichwertige Schutzmechanismen sind aktiv, wo gefordert (Ransomware-Szenarien).
• Admin-Modelle sind getrennt (Backup-Admin ≠ Domain-Admin); MFA/Conditional Access ist mit Recovery kompatibel.
• Logs sind manipulationsgeschützt oder zentral gesichert (für Nachweise im Incident).

D) Retention, Aufbewahrung, Offsite

• Retention-Plan ist dokumentiert und technisch umgesetzt (inkl. Ausnahmen).
• Offsite-Kopie existiert in getrenntem Sicherheitskontext (andere Credentials/andere Domain/andere Storage-Policy).
• Restore-Pfad aus Offsite ist getestet (nicht nur „wir könnten“).
• Kapazitätsplanung ist vorhanden (Wachstum, Aufbewahrungsänderungen, Kosten-/Tiering-Entscheidungen).

E) Restore-Tests & Validierung

• Es gibt einen Testplan (Frequenz je Tier), der Restore-Varianten abdeckt (File, VM, DB, PITR).
• Erfolgskriterien sind definiert (z. B. Startfähigkeit, Integritätschecks, Stichproben, Performance-Baseline).
• Testprotokolle sind abgelegt und nachvollziehbar (Datum, Versionen, Ergebnis, Abweichungen, Maßnahmen).
• Fehlgeschlagene Tests führen zu Tickets und Korrekturmaßnahmen (nicht „ignoriert bis Audit“).

F) MariaDB-spezifisch (wenn im Scope)

• Backup-Typ und Konsistenzmethode sind dokumentiert (physisch/logisch, Hot/Snapshot/Stop).
• Binlog-Strategie ist definiert (Retention, Offsite, Lücken-Erkennung).
• PITR ist als Runbook vorhanden und mindestens stichprobenartig getestet.
• Restore-Umgebung kann Version/Kompatibilität abbilden (Abhängigkeiten, Dateisystem, Ressourcen).

Umsetzung in 30 Tagen: pragmatischer Fahrplan

Wenn Sie „bei null“ starten, hilft ein kurzer, realistischer Plan. Ziel ist nicht Vollständigkeit, sondern ein erster Governance-Kreislauf mit messbaren Nachweisen.

Woche 1: Scope, Rollen, kritische Services

• Inventar und Tiering (Tier 0–2) erstellen.
• Service Owner und Backup Owner je Tier-0/1-System festlegen.
• RTO/RPO grob definieren (erste Version), Abhängigkeiten sammeln.

Woche 2: Policy-MVP und Runbook-Entwurf

• Backup-Policy als Minimum (Retention, Offsite, Verschlüsselung, Immutability, Monitoring) schreiben und versionieren.
• Runbook „Standard-Restore“ und „Disaster-Restore“ als Entwurf erstellen.
• Break-Glass-Pfad definieren und Security reviewen lassen.

Woche 3: Kontrollen aktivieren und Nachweise sammeln

• Monitoring- und Eskalationslogik schärfen (Restore-Readiness-Signale).
• Erste Restore-Proben für Tier 0/1 durchführen und protokollieren.
• MariaDB: Binlog-Check und ein PITR-Test in isolierter Umgebung einplanen.

Woche 4: Audit-Checkliste als Betriebsroutine etablieren

• Self-Assessment gegen die Checkliste durchführen, Abweichungen priorisieren.
• Tickets/Maßnahmen anlegen, Verantwortliche zuweisen, Fristen setzen.
• Regeltermin: monatliche Governance-Runde (kurz), quartalsweise Restore-Übung (umfangreicher).

Rückfallstrategie: Was tun, wenn Governance „zu schwer“ wird?

In manchen Umgebungen sind Ressourcen knapp oder Zuständigkeiten politisch schwierig. Dann hilft eine Rückfallstrategie, die trotzdem die größten Risiken reduziert:

• Reduzieren auf Tier-0/1: Starten Sie nur mit den kritischsten 10–20% der Systeme, aber machen Sie es dort richtig (Runbooks, Tests, Nachweise).
• Dokumentation als Steckbrief: Kein Wiki-Roman, sondern Schutzblatt + Policy-MVP + zwei Runbooks.
• Restore-Test als „Gate“: Änderungen an Retention/Offsite/Keys erst freigeben, wenn ein Restore-Test im passenden Szenario erfolgreich war.
• Abweichungen erlauben, aber sichtbar machen: Ausnahmen sind erlaubt, wenn Risiko und Genehmigung dokumentiert sind.

Das ist keine perfekte Governance, aber eine, die im Incident bessere Entscheidungen ermöglicht und im Audit argumentierbar ist.

Fazit: Backup-Governance ist der kürzeste Weg zu verlässlicher Wiederherstellung

Backup-Governance wird häufig als „Zusatz“ gesehen. Im Betrieb ist sie das, was aus Backups ein steuerbares, prüfbares und im Ernstfall nutzbares Recovery-System macht. Wenn Rollen klar sind, Dokumentation schlank aber vollständig ist und Restore-Tests als Kontrolle etabliert werden, sinken die typischen Risiken deutlich: falsche Priorisierung, fehlende Keys, unentdeckte Binlog-Lücken, und „grüne Jobs“ ohne Wiederherstellbarkeit.

Wenn Sie nur einen Punkt aus diesem Beitrag mitnehmen: Planen Sie Restore-Validierung als wiederkehrende Betriebsroutine ein – inklusive Nachweisen. Alles andere (Retention, Offsite, Immutable, MariaDB-PITR) wird erst dadurch im Alltag belastbar.

Für dieses Thema sind auch Backup-Verantwortlichkeiten wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.