Backups, Snapshots und Time-Travel-Löschung

Live-Löschung ohne Backup-Vertrag ist nur halbe Arbeit. Snapshots, Clones und Time Travel holen Identifier zurück — oft still, oft legitim für Disaster Recovery, aber tödlich für den Claim „gelöscht“.

zen Recovery. Dieselben Mechanismen bewahren personenbezogene Zeilen über den Löschungszeitpunkt hinaus. Teams feiern den Purge im Hot Path und vergessen den Cold Path.

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

In einem Satz: Behandeln Sie Backup-, Snapshot- und Time-Travel-Verhalten als Teil der Löschung, nicht als Infrastrukturdetail außerhalb von Privacy.

Problem

Moderne Plattformen speichern Vergangenheit absichtlich. Warehouse Time Travel, Lake Snapshots, Volume Snapshots, DB Clones, PITR-Backups und Object-Lock schützen Recovery. Dieselben Mechanismen bewahren personenbezogene Zeilen über den Löschungszeitpunkt hinaus. Teams feiern den Purge im Hot Path und vergessen den Cold Path.

Typische Ausfälle:

• Time Travel erlaubt SELECT auf gelöschte Keys innerhalb des Retention-Fensters;
• ein Clone für Debug enthält den Subject und wird zum neuen Produktion-ähnlichen Store;
• Restore nach Incident stellt auch gelöschte Auskunfts- und Löschrechte-Subjekte wieder her;
• 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 Re-Delete-Pflicht nach Restore.

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" — subject visible
T2  Incident restore from snapshot — subject back in hot path
T3  No re-delete job queued — ticket still closed

Löschung hat nicht gehalten; Recovery hat sie widerrufen.

Eine zweite Signatur ist Window Blindness: niemand kennt Time-Travel- und Backup-Tage pro System. Eine dritte ist Clone Sprawl: kurzlebige Clones ohne Löschungs-Owner. Eine vierte ist Restore Without Replay: Disaster Recovery ohne Identifier-Replay-Liste aus dem DSDR-Register.

Entscheidung

Behandeln Sie 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 Deletion Disposition. expire-with-window, re-delete-on-restore, block-restore-of-subject, legal-hold-override — explizit, nicht implizit.
2. Restore impliziert Re-Delete. Jeder Restore-Lauf, der in-scope Identifier zurückbringt, queued denselben Cross-Platform-Run (oder einen dokumentierten Teilpfad) erneut.
3. Fenster sind kommunizierte Realität. Solange Time Travel oder Backup den Subject halten, ist der öffentliche Claim „vollständig entfernt“ falsch — außer Policy erlaubt befristete technische Residuen mit Nachweis.

Der Contract deckt mindestens ab: Systeme, Fenstereängen, Clone-Policy, Restore-Trigger, Re-Delete-Owner, Evidence nach Ablauf, Eskalation bei WORM/Object Lock.

Kommunizieren Sie Residuen ehrlich gegenüber Privacy und Business: „Im Hot Path entfernt; im Backup-Fenster noch restorable bis Datum X; danach abgelaufen bzw. Re-Delete nach Restore verpflichtend.“ Das ist stärker als ein absoluter Claim, den Time Travel am nächsten Tag widerlegt. Wo Policy keine technischen Residuen duldet, müssen Fenster verkürzt, Keys separat geschreddert oder Restore-Pfade so gebaut werden, dass Subject-Rows ausgeschlossen oder sofort erneut entfernt werden — das ist Architekturentscheidung, kein Ticket-Kommentar.

Checkliste

Bauen Sie den Contract für den Pilotfall:

• listen Sie Backup-, Snapshot-, Clone- und Time-Travel-Mechanismen je Umfang-System;
• erfassen Sie Fenstereängen und unveränderliche Locks;
• markieren Sie, ob Subjects im Fenster noch lesbar/restorable sind;
• definieren Sie Disposition je Mechanismus;
• verdrahten Sie Restore-Runbooks mit Auskunfts- und Löschrechte-Identifier-Replay;
• benennen Sie verantwortliche Person für Re-Delete und Verify nach Restore;
• dokumentieren Sie erlaubte vs. verbotene Time-Travel-Nutzung für Support;
• koppeln Sie Fenster an Retention- und Privacy-Kommunikation;
• testen Sie einmal Restore→Re-Delete in Nicht-Produktion mit synthetischen IDs;
• stoppen Sie, wenn kein kritischer Recovery-Pfad ohne Disposition bleibt.

Artefakt

Erstellen Sie einen Backup & Restore Deletion Contract.

Pflichtfelder:

• System / Mechanismus (backup, snapshot, clone, time-travel, pitr, object-lock);
• Fensterlänge und Clock-Start-Ereignis;
• Lesbarkeit von Subjects im Fenster (yes, no, conditional);
• Disposition und Richtlinie-Verweis;
• Restore-Trigger und Re-Delete-Job-ID / Runbook-Step;
• Owner 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 Residuen-Kommunikation, keine stillen Undeletes nach Restore, testbarer Recovery↔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.