Erklär RTO und RPO und wie sie ein Disaster-Recovery-Design bestimmen.

Recovery Time Objective ist, wie lange du zur Wiederherstellung des Service brauchen darfst. Recovery Point Objective ist, wie viele Daten du verlieren darfst. Sie bestimmen die Strategie: Backup and Restore ist am billigsten bei einer Wiederherstellzeit von Stunden, ein Pilot Light hält Kernteile am Laufen für schnellere Erholung, ein Warm Standby betreibt eine verkleinerte Kopie, und aktiv in mehreren Regionen ist nahezu sofort und am teuersten. Beide Zahlen kommen vom Business, nicht aus dem Engineering.

Recovery Time Objective ist, wie lange das Business ausfallen darf. Recovery Point Objective ist, wie viele jüngste Daten es verlieren darf. Beides sind Business-Entscheidungen, und mein Job ist, sie in ein Design und einen Preis zu übersetzen, damit jemand informiert entscheiden kann. Wenn sie vier Stunden Ausfall und eine Stunde Datenverlust sagen, ist das Backup and Restore mit häufigen Snapshots, und das ist billig. Wenn es dreißig Minuten und nahezu null Datenverlust sind, sind wir bei einem Warm Standby mit kontinuierlicher Replikation, und das kostet echtes Geld. Nahezu sofort ohne Verlust heißt aktiv in zwei Regionen und ein sehr anderes Anwendungsdesign, und das ist ein Gespräch darüber, ob eine Stunde Downtime tatsächlich mehr kostet als die Architektur. Die wichtige Nuance ist, dass die Zahlen pro Workload unterschiedlich sind, Checkout und das interne Reporting-Tool verdienen nicht dieselbe Investition. Und ich bestehe auf Tests, einem geplanten Restore in eine saubere Umgebung, den wir Ende zu Ende stoppen, denn als ich das zum ersten Mal gemacht habe, entpuppten sich die dokumentierten vier Stunden Wiederherstellung als elf, größtenteils verbracht mit der Suche nach Credentials.