Einführung in die Datensicherung, Teil 1

Backup auf Tape, Disk und andere Medien

Seite: 2/3

Firmen zum Thema

RPO- und RTO-Intervall?

Werden Daten korrumpiert, existiert in der Regel ein Backup mit „gesunden“ Daten. Dieses letzte fehlerfreie Image bildet immer den Datenstand zum Zeitpunkt der letzten Sicherung ab. Findet diese, wie üblich, nachts statt und tritt der Schadensfall am folgenden Mittag ein, verlieren Anwender die Arbeit eines halben Tages. Da also der Wiederanlaufpunkt (Recovery Point Objective, RPO) in der vergangenen Nacht liegt, sind alle seither am Datenbestand vorgenommenen Änderungen verloren.

Ob der Datenverlust eines halben Tages akzeptabel ist, hängt von der Wichtigkeit der Daten ab – manchmal wäre der Verlust von nur zehn Minuten die bessere Alternative. Normalerweise ist solch ein RPO-Intervall von wenigen Minuten aber übertrieben aggressiv.

Im Gegensatz zum RPO-Intervall bemisst die Wiederanlaufzeit (Recovery Time Objective, RTO) die notwendige Dauer bis zur vollständigen Verfügbarkeit der Applikationen. Die RTO-Zeitspanne umfasst nicht nur die Dauer der Backup-Aufspielung (Restore), sondern den gesamten Recovery-Prozess.

Obwohl etwa der Einsatz von Disks (statt Tapes) oder Snapshots die Backup-Aufspielung beschleunigt, bleibt der Restore nur einer von fünf Schritten im gesamten Recovery Process. Eine RTO-Zeitspanne von Null ist daher utopisch.

Minimierter RTO und RPO

Wie stark RTO-Zeitspanne und RPO-Intervall zu verkürzen und der Datenverlust zu minimieren ist, hängt davon ab, wie unternehmenskritisch die wiederherzustellenden Dienste, Anwendungen und Daten sind.

Für die RTO-Zeitspanne gilt: Je aktueller das letzte nicht korrupte Backup (also je kürzer das RPO-Intervall), desto schneller gelingt das Log-basierte Recovery. Nur selten liegt der eigentliche Recovery-Punkt aber direkt vor dem Schadereignis, da sich nicht jeder Zeitpunkt zur Recovery eignet. Applikationsdaten wie etwa die Oracle Datenbank für eine SAP-Anwendung erfordern unbedingte Konsistenz. Das Recovery etwa von einem Punkt mitten in einer Transaktion kann große Probleme verursachen.

Daher ist in Backup-Anwendungen zuerst die Datenkonsistenz vor jedem Backup sicherzustellen. Das reduziert natürlich die Anzahl möglicher Recovery-Punkte. Faustregel: Je höher die Backup-Frequenz, desto höher theoretisch die Chancen auf brauchbare, da möglichst kurze, RPO-Intervalle. Kehrseite der Medaille ist, dass häufige Backups die Kosten der Datensicherungsstrategie erhöhen. Zum Glück aber sind häufige Backups weder notwendig noch nützlich, da sich ohnehin nur wenige Zeitpunkte hierfür eignen.

Gründe für Datenkorruption entstehen nur selten überraschend und lassen sich vermeiden. So empfiehlt sich etwa ein Backup vor jeder Installation eines Patch. Sollte das Patch oder Upgrade versagen, existiert ein intakter Recovery-Zeitpunkt. Diese relevanten Punkte frühzeitig zu finden, ist enorm hilfreich – mehrere pro Tag sind durchaus möglich und sinnvoll.

Weiter mit: Konsistente Backups von Anwendungen

(ID:2052191)