RTO und RPO mit Launchpad planen

Was RTO und RPO praktisch bedeuten

RTO steht für Recovery Time Objective. Gemeint ist die Zielzeit, bis ein System oder Prozess nach einem Ausfall wieder arbeitsfähig sein soll. Für einen Betrieb ist das keine Theorie: Wie lange darf Zeiterfassung, Angebotsbearbeitung oder Aufgabenübersicht ausfallen, bevor echter Schaden entsteht?

RPO steht für Recovery Point Objective. Gemeint ist der Datenstand, zu dem nach einem Ausfall zurückgekehrt werden muss. Wenn das letzte gute Backup zwei Stunden alt ist, sind andere Entscheidungen nötig als bei einem Backup vom Vortag.

Warum kleine Betriebe dafür einfache Systeme brauchen

Viele KMU haben keine eigene Notfallabteilung. Genau deshalb müssen Backup und Wiederanlauf so aufgebaut sein, dass sie im Stressfall von normalen Verantwortlichen verstanden werden.

Launchpad ist local-first gedacht: Die zentralen Arbeitsdaten liegen nicht als unklare Blackbox in einem fremden Portal, sondern sollen gesichert, kopiert und auf einem Ersatzsystem wieder nutzbar gemacht werden können.

Wie automatische Backups das RPO verbessern

Das RPO wird besser, wenn Sicherungen regelmäßig, nachvollziehbar und an einem geschützten Ort abgelegt werden. Entscheidend ist nicht nur, dass Backups existieren, sondern dass klar ist, welcher Stand zuletzt erfolgreich gesichert wurde.

Für Launchpad heißt das Zielbild: Arbeitsstände werden automatisch gesichert, ältere Stände bleiben auffindbar, und der Wiederanlauf startet vom letzten vertrauenswürdigen Backup. Je häufiger und sauberer gesichert wird, desto kleiner ist der mögliche Datenverlust.

Wie Launchpad das RTO verkürzen kann

Das RTO sinkt, wenn der Wiederanlauf nicht erst im Notfall erfunden wird. Ein vorbereitetes Ersatzgerät, dokumentierte Installationsschritte, gesicherte Konfiguration und ein getesteter Restore können aus einem Totalausfall ein planbares Wiederanlaufprojekt machen.

Im Idealfall wird ein zentrales System neu aufgesetzt, Launchpad installiert, das geprüfte Backup eingespielt und der Betrieb arbeitet nach wenigen Stunden wieder weiter. Diese Zeit ist kein automatisches Versprechen, sondern ein realistisches Ziel, wenn Hardware, Zugangsdaten und Backup-Prozess vorbereitet sind.

Warum E-Mail den Notbetrieb stützt

Ein wichtiger Unterschied zu vielen reinen Webportalen ist der E-Mail-Weg. Wenn Launchpad gerade nicht aktiv ist, können wichtige Meldungen trotzdem im Postfach entstehen und später verarbeitet werden.

Zeiterfassung ist ein gutes Beispiel: Wenn Mitarbeitende weiterhin per E-Mail arbeiten können, bleibt der Nachweis erhalten. Nach dem Restore kann Launchpad diese Kommunikation wieder aufnehmen, statt dass der Betrieb komplett im Dunkeln steht.

Warum ein zweiter Rechner mehr ist als Komfort

Für besonders kritische Abläufe kann ein isolierter zweiter Rechner als Recovery-System vorbereitet werden. Wichtig ist dabei die Trennung: Ein Ersatzsystem soll nicht denselben Schaden sofort mit übernehmen.

Wenn mehrere Computer mit passenden Sicherungen und klaren Rollen bereitstehen, kann ein Betrieb schneller umschalten. Einer fällt aus, ein anderer übernimmt. Das ist kein Ersatz für Security, aber ein starker Baustein für Business Continuity.

Was trotzdem getestet werden muss

Backups sind erst dann belastbar, wenn eine Wiederherstellung getestet wurde. Ein guter Recovery-Prozess prüft regelmäßig: Ist das Backup lesbar, ist es vollständig, sind Zugangsdaten vorhanden, ist die Dokumentation aktuell und weiß jemand, wer im Notfall entscheidet?

Launchpad kann diesen Prozess einfacher machen, aber nicht die Verantwortung ersetzen. RTO und RPO sollten als konkrete Betriebsziele dokumentiert werden: Welche Prozesse müssen sofort weiterlaufen, welche dürfen warten und welcher Datenverlust ist maximal akzeptabel?

Quellen und Weiterlesen

• BSI: Webkurs Notfallmanagement Glossar
• BSI IT-Grundschutz: CON.3 Datensicherungskonzept
• NIST Glossary: Recovery Time Objective
• NIST Glossary: Recovery Point Objective
• BSI: Lage der IT-Sicherheit