Kontinuität · Backup / DR

Backup und Disaster Recovery: RPO, RTO und Restore-Tests

Backup ohne definiertes RPO/RTO und Restore-Tests ist nur Plattenkosten. Disaster Recovery ohne Verfahren und Kommunikationsfenster ist ein Papierplan. Im gemanagten Modell müssen beide Schichten Teil des SLA sein — kein Zusatz „wenn Zeit ist“.

RPO und RTO — klar formuliert

• RPO (Recovery Point Objective) — wie viel Datenverlust akzeptabel ist (zum Beispiel 15 Minuten, 4 Stunden),
• RTO (Recovery Time Objective) — wie schnell die Umgebung wieder in Betrieb sein muss.

Niedrigere Werte bedeuten teurere Architektur: häufigere Snapshots, Replikation, Warm-/Hot-Standby, separater Standort. Nicht jede Anwendung braucht Near-Zero-RPO. RPO/RTO gelten bei BaseCloud nur, wenn sie nach Bewertung vertraglich vereinbart sind. Wir nennen kein Datum der „letzten Wiederherstellung“ als Produktversprechen.

Häufige Fehler in der Praxis

• Backup auf demselben Array / in derselben AZ wie die Produktion,
• kein Restore-Test (oder ein Test „alle zwei Jahre“),
• unklar, wer Restore genehmigt und wer mit Kunden kommuniziert,
• Retention zu kurz für Buchhaltung oder Branchenvorgaben.

Was gemanagtes DR bei BaseCloud umfasst

In den Paketen Professional und Enterprise sind Backup- und Wiederherstellungsverfahren Teil des Betriebs: Zeitpläne, Job-Monitoring, Retention und Beteiligung an DR-Tests. Der RPO/RTO-Umfang wird nach Bewertung konkretisiert — wir versprechen kein „Zero Downtime“ ohne Architektur, die das tatsächlich ermöglicht.

Checkliste vor Unterzeichnung des SLA

• Liste kritischer Systeme und ihrer fachlichen Owner,
• RPO/RTO-Ziele je System (nicht eine Zahl für das ganze Unternehmen),
• Häufigkeit und Form der Restore-Tests,
• Eskalationsweg und Bericht nach dem Vorfall.

Pakete ansehen · DORA und Betriebskontinuität · Weitere Artikel