Einführung in die Datensicherung, Teil 1 Backup auf Tape, Disk und andere Medien

Autor / Redakteur: Marcus Schneider / Nico Litzel

In der Praxis steht Datensicherung (Data Protection) für Datenverfügbarkeit: ohne Verfügbarkeit keine Business Continuity. Hierfür müssen Unternehmen alle notwendigen Maßnahmen treffen, um im Schadensfall schnell reagieren zu können. Denn Daten sind ebenso wertvoll wie verwundbar. Sie werden versehentlich manipuliert und gelöscht oder von Viren zerstört. Zudem misslingen oft Patches oder es entstehen administrative Fehler.

Firmen zum Thema

( Archiv: Vogel Business Media )

Auch unzureichende Softwaretests können zum Problem werden, da sie ein unvorhersehbares Systemverhalten zur Folge haben. In allen Fällen benötigen Anwender eine fehlerfreie Datenversion, auf deren Basis die Wiederherstellung (Restoration) und der Wiederanlauf (Recovery) möglich sind. Datensicherung umfasst den gesamten Prozess zur Bereitstellung und Wiederherstellung eines solchen unkompromittierten Datenstands.

Recovery: mehr als nur Zurückspielen von Backups

Datensicherung kreist eher um Wiederanlauf (Recovery) als um Sicherungskopien (Backups). Der gesamte Wiederherstellungsprozess umfasst fünf Schritte.

Schritt 1: Erkennen

Grundsätzlich muss das Problem korrekt identifiziert werden – bei gelöschten Files oder Verzeichnissen tritt es ganz offen zu Tage. Virenbefall hingegen ist oft schwieriger zu erkennen. Hier ist zuerst festzustellen, wann welche Daten befallen wurden. Und in welchem Umfang.

Schritt 2: Diagnose

Nun gilt es, den optimalen Wiederherstellungspunkt festzustellen: Wann waren die Daten zuletzt konsistent und fehlerfrei? Ebenso ist zu entscheiden, ob das Wiederherstellen einzelner Files genügt oder ein vollständiges Backup notwendig ist. Dies hängt von internen Backup-Strategien und Richtlinien ab.

Schritt 3: Wiederherstellung (Restore, Restoration)

Restoration meint das Überspeichern infizierter Daten mit „gesunden“ Sicherungskopien. Dieser Restore kopiert zuvor gesicherte Daten lediglich physisch auf das Produktivsystem und ist nicht mit dem Recovery-Prozess gleichzusetzen. Der vollwertige Wiederanlauf, also Recovery, erfordert unter Umständen auch den kompletten Applikationsneustart, das Zurückspiegeln von Logdateien aus einer Datenbank oder einem Filesystem-Journal. Dies hilft, Datenverluste so gering wie möglich zu halten.

Schritt 4 und 5: Test und Verifizierung

Zum Schluss folgen Test und Verifizierung. Erst wenn feststeht, dass die Daten erfolgreich wieder hergestellt und der Wiederanlauf gesichert sind, lässt sich der gesamte Recovery-Prozess erfolgreich schließen.

Weiter mit: RPO- und RTO-Intervall?

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

Konsistente Backups von Anwendungen

Am einfachsten gelingt das Backup einer Applikation, wenn diese zuvor geschlossen und dann erst das Backup gestartet wird. Leider führt dies zu unakzeptablen Ausfallzeiten.

Eine weitere Möglichkeit sind spezielle Backup-Anwendungen, mit denen sich konsistente Datenbestände erstellen lassen, während die zu sichernde Applikation ungestört weiterläuft.

Der dritte Weg sind Snapshots, also sehr schnelle und effiziente Momentaufnahmen von Datenbeständen. Sie werden zum Zeitpunkt konsistenter Daten erzeugt, um damit bei laufender Anwendung ein Backup zu erstellen und die Originaldaten zu ersetzen. Dieses Verfahren nutzt man heute für sehr anspruchsvolle Anwendungen.

Data Protection Strategie mit Kompromissen

Zurzeit sind zahlreiche Backup- und Recovery-Technologien auf dem Markt, die alle ihren Preis kosten. Entscheiden sollte man sich nur anhand genau definierter Anforderungen. Nicht alle Daten sind gleich, nicht jeder Applikationsservice ist für das Unternehmen gleich wichtig. Zu unterscheiden ist auch zwischen Fileservices, E-Mailsystemen, Datenbanken und wie rasch sie nach einem Störfall wieder verfügbar sein müssen. Wie viel Datenverlust ist vertretbar? Wie hoch will man investieren?

Neben RPO-Intervall und RTO-Zeitspanne ist auch die Sicherheit der Backup-Kopien wichtig für Data Protection. Wie sicher sind diese Kopien? Überstehen Sie einen Systemausfall?

Mehrere Kopien räumlich getrennt aufbewahren

Abhängig von der Datenrelevanz empfehlen sich von jedem Backup mehrere Kopien auf unterschiedlichen Medien, die räumlich getrennt aufbewahrt werden. Je mehr Kopien in räumlicher Trennung lagern, desto sicherer sind die Daten, allerdings zu höheren Kosten.

Wie hoch diese Sicherheit sein soll, muss jede Firma für sich allein entscheiden. Einige Unternehmen oder Behörden speichern ihre Daten auf Tapes und lagern sie tief in Bergwerken etwa in den Schweizer Alpen. Andere hingegen brauchen derartig hohe Sicherheitsstufen nicht.

Entscheidend für derartige Investitionen ist daher, wie viel Datenverlust ein Unternehmen verkraftet. Wann wird die Nichtverfügbarkeit unternehmenskritischer Dienste oder Anwendungen teurer als die Sicherheitsstrategie? Wie lange geht es auch ohne Datenzugriff?

Das Einrichten einer Datensicherungs-Infrastruktur ist demnach wie der Abschluss einer Versicherung – Kosten für Ernstfall und Absicherung sind gegeneinander abzuwägen.

Im zweiten und letzten Teil, der am kommenden Mittwoch erscheint, wird unter anderem der Aufbau einer Backup-Infrastruktur näher behandelt.

(ID:2052191)