Recovery Time Objective (RTO) bezeichnet die maximal akzeptable Zeitspanne bis zur Wiederherstellung der Funktionsf\u00e4higkeit einer Anwendung, eines Service, von Daten oder anderen digitalen Assets, auf die ein Unternehmen aufgrund eines Ausfalls oder Datenverlusts nicht zugreifen kann. Idealerweise liegt ein RTO nahe bei null. RTO und Recovery Point Objective (RPO) unterscheiden sich dadurch, dass es beim RTO um die Zeit geht: Wie lange<\/strong> dauert es, bis die Systeme wieder normal funktionieren? Beim RPO geht es eher darum, wie viele Daten<\/strong> verloren gehen k\u00f6nnen. Das RPO ist der maximal zul\u00e4ssige Datenverlust, den eine Anwendung tolerieren kann, bevor das Unternehmen Schaden erleidet.<\/p>\n Im Zeitalter der digitalen Transformation erwarten Unternehmen\u00a0\u2013 ebenso wie ihre Kunden und Partner\u00a0\u2013 immer verf\u00fcgbare IT-Services und einen IT-Betrieb rund um die Uhr. Zudem m\u00fcssen sie die stetig steigenden Sicherheits- und Compliance-Anforderungen erf\u00fcllen. Doch sich st\u00e4ndig weiterentwickelnde Cyber-Bedrohungen wie Ransomware<\/a>-Angriffe erschweren es Unternehmen, ihre aufgabenkritischen Anwendungen zu sch\u00fctzen und vorhersehbar mit minimaler Ausfallzeit wiederherzustellen<\/a>.<\/p>\n Unternehmen m\u00fcssen ihre Gesch\u00e4ftsbereiche auf den Ernstfall vorbereiten. Dazu geh\u00f6rt auch die Kenntnis dar\u00fcber, wie lange digitale Assets maximal ausfallen d\u00fcrfen, bevor sie dem Unternehmen Schaden zuf\u00fcgen (Recovery Time Objectives). Doch nicht alle Anwendungen sind gleich, wenn es um die RTO-Zeitspannen geht. IT- und Anwendungsteams sollten die RTOs der f\u00fcr das Unternehmen wichtigsten Assets gemeinsam priorisieren. Au\u00dferdem ist es unerl\u00e4sslich, die RTOs aller einzelnen Anwendungen, Services oder anderer Ressourcen im Auge zu behalten, damit das Unternehmen auch bei einem ungeplanten Ausfall in jedem Fall voll funktionsf\u00e4hig bleibt.<\/p>\n Das RPO gibt den maximal akzeptablen Datenverlust an, den eine Anwendung tolerieren kann, bevor ein Unternehmen Schaden erleidet. Das RTO definiert die Zeit, die eine Anwendung ausfallen kann, bevor negative Auswirkungen f\u00fcr den Betrieb auftreten.<\/p>\n Das Recovery Time Objective f\u00fcr Ihr Projekt ist die maximal zul\u00e4ssige Zeitspanne, in der das Projekt nicht erreichbar sein darf, ohne dem Unternehmen zu schaden.<\/p>\n RTO ist die maximal zul\u00e4ssige Zeitdauer<\/strong>, bevor ein Unternehmen die Funktion einer Anwendung, eines Service, von Daten oder eines anderen digitalen Assets wiederherstellen muss. Die RTO-Messung erfolgt in Sekunden, Minuten, Stunden oder Tagen. Es ist ein wichtiger Bestandteil der Datenwiederherstellungspl\u00e4ne eines Unternehmens. In der heutigen digitalen Welt, in der alles immer verf\u00fcgbar ist, muss das RTO sehr kurz sein. F\u00fcr das Transaktionssystem einer Kreditkartenagentur beispielsweise muss es so nahe wie m\u00f6glich bei null liegen, etwa bei zwei oder drei Sekunden. Das bedeutet, dass die IT-Abteilung im Falle eines Systemausfalls nur zwei oder drei Sekunden Zeit hat, um das System wieder online zu bringen.<\/p>\n Das RPO bezieht sich darauf, wie viele Daten<\/strong> bei einem Vorfall verloren gehen k\u00f6nnten. Es gibt den maximal zul\u00e4ssigen Datenverlust an, den eine Anwendung tolerieren kann, bevor das Unternehmen Schaden erleidet. Seine Messgr\u00f6\u00dfe ist ebenfalls die Zeit, und zwar in diesem Fall die Spanne zwischen der letzten Datensicherung und der St\u00f6rung. Eine Bank zum Beispiel ben\u00f6tigt Backups fast in Echtzeit, damit ihr immer die aktuellsten Daten zur Verf\u00fcgung stehen. Wenn bei einem Ausfall das letzte Backup 10\u00a0Sekunden zur\u00fcckliegt und das RPO f\u00fcr die Anwendung 15\u00a0Sekunden betr\u00e4gt, wurde das RPO eingehalten.<\/p>\n Das RPO ist ein entscheidendes Element bei der Datenwiederherstellung. Es beantwortet eine wichtige Frage: Wie lange dauert es, ein System (eine Anwendung, einen Service oder ein anderes digitales Asset) wiederherzustellen, wenn wir die Menge der bei einem Vorfall verloren gegangenen Daten ber\u00fccksichtigen?<\/p>\n Grunds\u00e4tzlich bietet das RPO einen realistischen Rahmen f\u00fcr die Planung einer erfolgreichen Daten-Recovery. Damit l\u00e4sst sich die H\u00e4ufigkeit von Backups planen, denn die dazwischenliegenden Zeitr\u00e4ume entsprechen der Datenmenge, die bei einem Ausfall verloren gehen k\u00f6nnten. Healthcare-Unternehmen und Finanzdienstleister k\u00f6nnen sich zum Beispiel grunds\u00e4tzlich keine Datenverluste leisten und messen daher das RPO in Millisekunden. Andere Unternehmen hingegen k\u00f6nnen stunden- oder sogar tagelang auf Daten verzichten, ohne dass sie negative Folgen f\u00fcr ihren Betrieb bef\u00fcrchten m\u00fcssten.<\/p>\n Die Messgr\u00f6\u00dfe f\u00fcr RTO und RPO ist die Zeit: Sekunden (oder Subsekunden), Minuten, Stunden oder sogar Tage. Allerdings messen sie zwei verschiedene Parameter. Das RTO ist die maximale Zeit, die ein System ausfallen kann, ohne dem Unternehmen zu schaden. Das RPO gibt an, wie viele Daten maximal verloren gehen d\u00fcrfen.<\/p>\n Beim Berechnen des RTO werden die Grenzwerte f\u00fcr die L\u00e4nge eines Ausfalls ermittelt, der vom Unternehmen noch toleriert werden kann. Um diese Zahl zu bestimmen, m\u00fcssen Sie folgende Fragen beantworten:<\/p>\n Aufgrund der Anforderungen im heutigen, immer verf\u00fcgbaren Wirtschaftsumfeld sind RPO und RTO wichtige Messgr\u00f6\u00dfen. Sie bieten unter anderem die folgenden Vorteile:<\/p>\n Nein. Das RPO muss nicht kleiner sein als das RTO. Beide Werte sind nicht direkt aneinander gekoppelt. Zwar sind beide f\u00fcr das Einrichten und Managen der Daten- und Notfallwiederherstellung wichtig, aber der eine Wert muss nicht kleiner (oder gr\u00f6\u00dfer) sein als der andere. IT-Teams k\u00f6nnen ein RTO von f\u00fcnf Stunden und ein RPO von 30 Sekunden oder ein RTO von f\u00fcnf Minuten und ein RPO von 24 Stunden festlegen.<\/p>\n RPO und RTO bieten einen realistischen Rahmen, um zu bestimmen, wie h\u00e4ufig das Unternehmen Daten sichern sollte. Tats\u00e4chlich entspricht die Zeit zwischen den Backups der Datenmenge, die das Unternehmen beim Ausfall einer bestimmten Anwendung verlieren kann. Die IT-Abteilung sollte in Zusammenarbeit mit den Gesch\u00e4ftsinhabern die RTOs und RPOs f\u00fcr jede Anwendung, jeden Service oder jedes andere digitale Asset berechnen und Backups planen, die auf diesen Parametern basieren. Beispielsweise messen Healthcare-Unternehmen und Finanzdienstleister ihre RPOs in der Regel in Millisekunden, da sie sich keine Datenverluste leisten k\u00f6nnen. Sie m\u00fcssten ihre Daten daher nahezu kontinuierlich sichern.<\/p>\n Da das heutige Gesch\u00e4ftsleben keinen Stillstand kennt, sind Unternehmen gezwungen, die Recovery Time Objectives ebenso wie die Recovery Point Objectives so weit wie m\u00f6glich gegen null zu reduzieren\u00a0\u2013 idealerweise in Zeitr\u00e4umen von Minuten oder Sekunden und nicht in Stunden oder Tagen.<\/p>\n Trotz umfangreicher Investitionen in \u00e4ltere Produkte f\u00fcr die Notfallwiederherstellung und den Schutz von Daten sind Ausfallzeiten in Unternehmen leider keine Seltenheit. Sie sind h\u00e4ufig mit erheblichen Verlusten in Form von entgangenen Ums\u00e4tzen und Ertr\u00e4gen, mit Strafen f\u00fcr die Nichteinhaltung von Vorschriften und Datenschutzbestimmungen sowie verringerter Produktivit\u00e4t verbunden.<\/p>\n Diese negativen Auswirkungen auf das Gesch\u00e4ft werden durch den Vertrauensverlust bei Kunden und Mitarbeitern noch versch\u00e4rft, wenn der Datenschutzplan nicht eingehalten wird. Bei dem Versuch, RTO und RPO zu reduzieren, setzen zu viele Unternehmen teure, komplexe und individuell konzipierte Produkte ein, die laufend gewartet werden m\u00fcssen, damit die Unternehmen wie gew\u00fcnscht immer verf\u00fcgbar sind.<\/p>\n Cohesity bietet die einzige konvergente Plattform, die die Komplexit\u00e4t herk\u00f6mmlicher Datensicherungsl\u00f6sungen beseitigt, indem sie die End-to-End-Datensicherungsinfrastruktur vereinheitlicht\u00a0\u2013 einschlie\u00dflich Zielspeicher, Datensicherung, Replikation, Notfallwiederherstellung und Cloud-Tiering.<\/p>\n","protected":false},"featured_media":51674,"template":"","class_list":["post-175322","glossary","type-glossary","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\nWarum ist das RTO wichtig?<\/span><\/h2>\n
Was ist der Unterschied zwischen RPO und RTO?<\/h2>\n
Wie sieht das RTO f\u00fcr Ihr Projekt aus?<\/h2>\n
Beispiele f\u00fcr RPO und RTO<\/h2>\n
Welche Rolle spielt RPO bei der Datenwiederherstellung?<\/h2>\n
Wie werden RTO und RPO gemessen?<\/h2>\n
Wie wird das RTO berechnet?<\/h2>\n
\n
Warum sind RPO und RTO wichtig?<\/h2>\n
\n
Sollte RPO kleiner als RTO sein?<\/h2>\n
Welche Rolle spielen RPO und RTO bei der Datensicherung?<\/h2>\n
Cohesity und RTO<\/h2>\n