Backup & Recovery: RPO, RTO und Restore-Design vor der Produktwahl klären
Backups sind erst dann belastbar, wenn ein kritischer Service innerhalb eines definierten RTO mit geprüftem RPO, geschützter Kopie und dokumentierter Recovery-Reihenfolge wiederhergestellt werden kann.
Restore-Ziel vor Sicherungsfrequenz
RPO und RTO sollten pro Service mit Abhängigkeiten, Reihenfolge und Verantwortlichen definiert werden. Erst daraus ergeben sich Sicherungsintervalle, Kopien und technische Recovery-Verfahren.
Isolation ist mehr als Retention
Eine geschützte Kopie muss auch gegen kompromittierte Produktions- oder Standard-Admin-Konten robust sein. Rollen, Löschschutz, Break-Glass und getrennte Fehlerdomänen gehören deshalb zum Architekturtest.
Anwendungskonsistenz und SaaS explizit prüfen
VM-Snapshots allein beantworten nicht, ob Datenbanken, M365/SaaS oder transaktionale Anwendungen fachlich konsistent wieder anlaufen. Diese Workloads benötigen eigene Abnahmefälle.
Offsite braucht reale Bandbreite und Reihenfolge
Ein Standortausfall zeigt, ob Datenpfad, Egress, Priorisierung und Wiederanlaufreihenfolge zum RTO passen. Theoretische Leitungskapazität ersetzt keinen gemessenen Recovery-Test.
Kosten entstehen aus Retention und Recovery-Design
Lizenzmetrik, Storage-Tiers, Offsite-Transfer, Egress und lange Aufbewahrung sollten mit realen Datenmengen kalkuliert werden. Exit und Datenexport gehören vor Vertragsabschluss in dieselbe Betrachtung.