Backups, Snapshots und Time-Travel-Löschung

Ausgangspunkt

Moderne Plattformen speichern Vergangenheit absichtlich. Time Travel im Warehouse, Lake-Snapshots, Datenbank-Clones, Point-in-Time-Recovery, Backups und Object Lock schützen vor Datenverlust. Genau diese Mechanismen können aber personenbezogene Zeilen oder gelöschte Altdaten länger halten als der operative Löschlauf.

Das Problem ist einfach: Ein Team löscht den Datensatz im Live-System und hängt einen Nachweis ans Ticket. Später wird ein Snapshot wiederhergestellt, ein Clone genutzt oder ein Time-Travel-Fenster abgefragt. Plötzlich ist der Datensatz wieder sichtbar. Die Löschung war technisch nicht falsch, aber sie hat nicht gehalten.

Typische Ausfälle:

• Time Travel erlaubt Abfragen auf gelöschte Schlüssel innerhalb des Aufbewahrungsfensters;
• ein Debug-Clone enthält dieselbe Person und wird zum neuen produktionsähnlichen Speicher;
• ein Restore nach einem Incident stellt auch Datensätze wieder her, die wegen Auskunfts- oder Löschrechten entfernt wurden;
• Backup-Retention ist länger als Privacy-Erwartung, ohne dokumentierte Ausnahme;
• Object Lock / WORM verhindert frühzeitiges Löschen, ohne dass der Umfang das ausweist;
• niemand besitzt die Pflicht, nach einem Restore erneut zu löschen.

Diese Serie baut auf Scope, Strategie und Plattform-Runbook auf (Teil 1–Teil 3). Retention-Logik bleibt im Pillar Data Lifecycle & Retention; Request-Fristen in DSDR Governance; Identifizierbarkeit in PII & Privacy Governance. Hier geht es um den Contract zwischen Recovery und Löschung.

Verwandte Nachbarn:

• Löschen über Warehouse, Lake und BI — Hot-Path-Runbook;
• Data Lifecycle & Retention — Aufbewahrungsfenster;
• Serie: Löschung, die hält.

Recovery-Risiko zeigt sich so:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

T0  Live purge complete, evidence attached
T1  Analyst time-travels "just to check" — customer visible
T2  Incident restore from snapshot — customer back in hot path
T3  No re-delete job queued — ticket still closed

Die Löschung hat nicht gehalten; der Restore hat sie rückgängig gemacht.

Eine zweite Signatur ist Fensterblindheit: Niemand kennt Time-Travel- und Backup-Tage pro System. Eine dritte ist Clone-Wildwuchs: kurzlebige Kopien ohne Löschverantwortung. Eine vierte ist Restore ohne Replay: Disaster Recovery stellt Daten wieder her, ohne die Liste der bereits gelöschten IDs erneut abzuarbeiten.

Entscheidung

Behandle Backup-, Snapshot- und Time-Travel-Verhalten als Teil der Löschung, nicht als Infrastrukturdetail außerhalb von Privacy.

Drei Prinzipien:

1. Jeder Recovery-Mechanismus braucht eine Lösch-Entscheidung. Zum Beispiel: läuft nach Frist aus, wird nach Restore erneut gelöscht, darf gar nicht restored werden oder ist wegen Legal Hold ausgenommen.
2. Restore bedeutet Re-Delete. Jeder Restore-Lauf, der betroffene IDs zurückbringt, startet denselben Löschlauf oder einen dokumentierten Teilpfad erneut.
3. Fenster sind kommunizierte Realität. Solange Time Travel oder Backup die Person oder das Asset halten, ist „vollständig entfernt“ falsch — außer die Policy erlaubt befristete technische Reste mit Nachweis.

Der Vertrag deckt mindestens ab: Systeme, Fensterlängen, Clone-Policy, Restore-Trigger, Re-Delete-Verantwortung, Nachweis nach Ablauf und Eskalation bei WORM/Object Lock.

Kommuniziere technische Reste ehrlich gegenüber Datenschutz und Fachbereich: „Im Live-Pfad entfernt; im Backup-Fenster noch wiederherstellbar bis Datum X; danach abgelaufen beziehungsweise nach Restore erneut zu löschen.“ Das ist belastbarer als ein absoluter Claim, den Time Travel am nächsten Tag widerlegt. Wo die Policy keine technischen Reste duldet, müssen Fenster verkürzt, Schlüssel separat geschreddert oder Restore-Pfade so gebaut werden, dass betroffene Zeilen ausgeschlossen oder sofort erneut entfernt werden. Das ist eine Architekturentscheidung, kein Ticket-Kommentar.

Checkliste

Baue den Vertrag für den Pilotfall:

• liste Backup-, Snapshot-, Clone- und Time-Travel-Mechanismen je Umfangssystem;
• erfasse Fensterlängen und unveränderliche Locks;
• markiere, ob betroffene Personen oder Assets im Fenster noch lesbar oder wiederherstellbar sind;
• definiere die Lösch-Entscheidung je Mechanismus;
• verdrahte Restore-Runbooks mit der Replay-Liste aus dem Auskunfts- und Löschrechte-Register;
• benenne Zuständigkeit für Re-Delete und Prüfung nach Restore;
• dokumentiere erlaubte und verbotene Time-Travel-Nutzung für Support;
• kopple Fenster an Retention- und Datenschutz-Kommunikation;
• teste einmal Restore -> Re-Delete in Nicht-Produktion mit synthetischen IDs;
• stoppe, wenn kein kritischer Recovery-Pfad ohne Entscheidung bleibt.

Arbeitsartefakt

Erstelle einen Backup & Restore Deletion Contract.

Pflichtfelder:

• System / Mechanismus (backup, snapshot, clone, time-travel, pitr, object-lock);
• Fensterlänge und Clock-Start-Ereignis;
• Lesbarkeit betroffener Personen oder Assets im Fenster (yes, no, conditional);
• Disposition und Richtlinie-Verweis;
• Restore-Trigger und Re-Delete-Job-ID / Runbook-Schritt;
• Zuständigkeit und SLA für Re-Delete;
• Nachweis bei Window-Expiry;
• Ausnahmen: Legal Hold, regulatorische Archive;
• letzter Drill-Test (Datum, Ergebnis);
• Link zu Umfang Matrix und Cross-Platform Runbook.

Ergebnisse: ehrliche Kommunikation über technische Reste, keine stillen Undeletes nach Restore, testbarer Recovery-zu-Deletion-Loop.

Tools

Cloud-/Warehouse-Backup-Konsolen und Retention-Settings. Time-Travel- und Snapshot-APIs. Restore-Orchestrierung mit Hook auf Deletion Jobs. DSDR-Register für Identifier-Replay. Ticket-Automation für Re-Delete nach Restore. Least Privilege für Clone- und Time-Travel-Zugriffe.

Ressourcen

Interne Quellen: DR-Runbooks, RPO/RTO-Dokumente, Plattform-Retention-Defaults, Object-Lock-Policies, Clone-Lifecycle-Docs, Incident-Reviews „data reappeared after restore“.

Nachbarn: Data Lifecycle & Retention, DSDR Governance, PII & Privacy Governance, Löschen über Warehouse, Lake und BI, Serie: Löschung, die hält.