Als wäre nichts passiert

10. September 2007, 16:53 Uhr |

Continuous-Data-Protection – Von 12 bis 24 Stunden alten Backups Daten wiederherzustellen hilft, bringt ein Unternehmen aber nicht vollständig zurück in den Sattel. Continuous-Data-Protection ist eine deutlich bessere Möglichkeit zum Schutz wertvoller und zeitkritischer Daten.

Die Technik zur Datensicherung hat von 9-Spur-Bändern einen langen Weg zurückgelegt, aber viel zu viele Unternehmensrichtlinien haben nicht Schritt gehalten mit den Echtzeit-Online-Applikationen, von denen heute so viel abhängt.

Eine Datenbank, die stündlich mehrere Hundert Kundentransaktionen speichert, benötigt mehr als ein routinemäßiges nächtliches Backup. Die Lösung ist Continuous-Data-Protection. CDP-Angebote sind kein Ersatz für konventionelle Backups, aber sie können den Kopf des Administrators retten, wenn ein High-Traffic-System plötzlich den Bach runtergeht.

Unternehmen akzeptieren dieses Konzept erst allmählich. Laut Leserumfrage der Network Computing setzen 40 Prozent der Beantworter CDP bereits ein oder werden es innerhalb der kommenden zwölf Monate tun. Aber 41 Prozent sagten auch, dass sie zurzeit keinen Einsatz planten, und 19 Prozent sprachen von einer Frist zur Implementierung von 24 Monaten.

An welcher Stelle passt CDP in die IT-Strategie? Ein vollständiger Datenschutz-Plan muss drei Grundaufgaben abdecken. Erstens den Schutz der Daten auf dem Host und der Applikationen, die sie erzeugen und verwalten. Dies geschieht typischerweise durch Kopien. Werden die Daten korrumpiert, vielleicht durch einen Wurm oder ein Virus auf dem Datenbankserver, dann muss der Zugriff auf die geschützte Kopie möglich sein, um die Applikation wiederherzustellen. Diese geschützten Datenkopien oder Ansichten (Views) müssen ausreichend feinkörnig sein, damit sich die Daten einer Applikation zu einer nutzbaren Ansicht zurückfahren lassen, ohne dass dabei zu viele Daten verloren gehen. Einige Hersteller argumentieren, dass Schnappschuss-Technik diese Anforderung erfülle, aber Schnappschüsse haben Grenzen.

Zweitens sind Backup-Daten-Ansichten vom Speichergerät, auf dem die primäre Datenkopie gespeichert ist, zu entfernen. Das verhindert, dass ein einzelner Disk-Array-Fehler sowohl die primären Daten als auch die Backups zerstört oder den Zugriff darauf unmöglich macht.

Drittens sind die Daten aus dem lokalen Standort zu entfernen – das sprichwörtliche Offsite-Backup. Distanz ist ein Schlüssel zu Disaster-Recovery. Tatsächlich war Offsite-Backup der Prozess, den die Beantworter der Leserumfrage am häufigsten nannten, als etwas, das sie gern in CDP integriert sähen.

Mit intelligenten SAN-Geräten oder Disk-Array-Features kombinierte Datenreplikations-Systeme, vielleicht durch Host-Software zur Verfügung gestellt, kopieren Daten vom Daten-Center, indem sie sie von primärem auf sekundärem Speicher duplizieren. Das geschieht im Wesentlichen in Echtzeit. Aber die Replikation entzieht die Daten nicht der Kontrolle der Benutzer und Applikationen. Was, wenn nun jemand meint, er habe lieber keine zwei Kopien eines sensiblen Dokuments auf dem Server? Und dann löscht er eine der Kopien. Diese Löschung entfernt nun so schnell wie ein Wimpernschlag die Daten sowohl vom primären als auch vom sekundären System.

Die konventionelle Methode, Daten unter Beibehaltung feiner Wiederherstellungspunkte aus der Reichweite von Benutzern, Malware oder anderen Schadensquellen zu bekommen, ist bislang die Anfertigung periodischer Schnappschüsse. Mit einem Host- oder üblicherem Disk-Array-Setup erzeugt der Administrator unter Verwendung von Split-Mirror- oder Kopieren-beim-Schreiben-Techniken mehrere Wiederherstellungspunkte. Als Datenschutzmechanismus haben Schnappschüsse allerdings signifikante Einschränkungen. Es sind zusätzliche Volumes auf demselben Host, der die Datenbank ausführt, die eigentlich geschützt werden soll. Deshalb sind Schnappschüsse verletzbar durch die Softwareprobleme und Malware, die die Daten schon anfänglich korrumpiert haben. Oder sie sind im selben Disk-Array-Subsystem, womit ein Fehler dieses Disk-System gleich beides, Daten und Schnappschüsse, zerstört.

Ein weiteres Problem mit auf Disk-Arrays basierenden Schnappschüssen ist, dass sie sich außer zum Zurücksetzen des primären Volumes auf den Stand des Schnappschusszeitpunkts generell lediglich als zusätzliches Volume mounten lassen, meist read-only. Dies mag für einen erfahrenen Datenbankadministrator ausreichen, der eine Datenbank mit einem Schnappschuss wiederherstellt, der erzeugt wurde, bevor ein gelangweilter Programmierer sie über den Jordan schickte. Dann hangelt sich der Datenbankadministrator natürlich noch vorsichtig durch alle Logdateien vorwärts, um die Daten zwischen den Schnappschüssen einzufangen. Und das IT-Lexikon definiert den Begriff »vorsichtig« mit »Ungemach, das Sie bis mindestens 4 Uhr früh auf den Beinen hält«.

Versucht der Administrator aber, eine Excel-Datei wiederherzustellen, die der Boss genau jetzt braucht, der Boss sich aber leider nicht daran erinnern kann, wann er die Datei zuletzt gesehen hat, dann könnte der Administrator enorm viel Zeit damit verbringen, Schnappschüsse zu mounten, bis die richtige Datei endlich gefunden ist. Die meisten Systeme speichern außerdem nur einige wenige Schnappschüsse. Wer während eines 12-Stunden-Arbeitstages stündliche Schnappschüsse anfertigen möchte, der wird mit einem typischen Cache von 64 Schnappschüssen gerade mal die Daten der zurückliegenden Woche wiederherstellen können.

Sie sind nicht gleich
Beim Entwurf eines Datenschutzplans ist zu berücksichtigen, dass nicht alle Daten gleich sind. Ältere Daten sollte der Administrator natürlich archivieren. Für frische Daten sollte er weniger an Dinge wie »mission-critical« oder »geschätzter Wert der Daten« denken, sondern vielmehr an die Reproduzierbarkeit. Microsoft-Word-Dokumente können das Produkt einer Anwaltskanzlei sein. Natürlich sind sie kritisch, aber sie sind auch reproduzierbar. Wäre der Dateiserver dieser Kanzlei zurückzusetzen auf einen eine oder sogar zwei Stunden alten Schnappschuss, dann würden die Benutzer zwar murren, aber sie wären in der Lage, alle ihre Dokumente neu zu schreiben.

Ist andererseits aber ein E-Mail-Server eine Stunde zurückzusetzen, dann wird niemand wissen, welche Nachrichten innerhalb dieser Stunde eingegangen waren. Eine Datenbank hinter einer E-Commerce-Site darf ebenfalls keine Stunde verlieren.

Um diese Punkte anzugehen, offerieren die Großen wie Microsoft, Symantec und IBM sowie ebenso viele Startups Produkte, die Continuous-Data-Protection bieten. Das einzige, was die meisten dieser Produkte zurzeit gemeinsam haben, ist aber lediglich die Verwendung der Abkürzung CDP.

Eine Rose mit anderen Namen
Die CDP-Special-Interest-Group (SIG) der Storage-Networking- Industry-Association (Snia) bietet eine funktionierende Definition von CDP: »Eine Methode, die kontinuierlich Datenmodifikationen einfängt oder verfolgt und Änderungen unabhängig von den primären Daten speichert und Wiederherstellungspunkte für jeden Punkt in der Vergangenheit ermöglicht. CDP-Systeme können auf Blöcken, Dateien oder Applikationen basieren und bieten feine wiederherstellbare Objekte für unendlich variable Wiederherstellungspunkte.«

Einige Puristen klammern sich an diese Definition und sagen, dass ein Produkt, um CDP genannt werden zu dürfen, ein Zurücksetzen der Daten zu einer unendlichen Anzahl von Wiederherstellungspunkten ermöglichen müsse. Network Computing aber lässt Ausnahmen für den Begriff »unendlich« zu. In der Realität werden bei jedem Schreiben Änderungen aufgezeichnet, was dem Administrator ein Zurücksetzen zu einer »unbegrenzten« Anzahl dieser Änderungspunkte erlaubt. Produkte, die ein Schnappschuss-und-Export-Modell verwenden, oder andere Methoden, welche die Änderungen nicht in Echtzeit zum Backup-Repository senden, bezeichnet Network Computing als Pseudo-CDP. Pseudo-CDP-Produkte können das Management von Backups weniger kritischer, nicht reproduzierbarer Daten sehr vereinfachen, aber der Einsatz eines solchen Produkts kann im Katastrophenfall zum Verlust einiger Minuten Daten führen.

Ein wenig großzügiger sollten Produkte wie Symantecs Backup-Exec-Continuous- Production-Server betrachtet werden. Dieser repliziert Daten in Echtzeit in ein Backup-Repository, bietet aber keine unbegrenzten Wiederherstellungspunkte. Stattdessen fertigt er periodisch Schnappschüsse an. Das ist vielleicht nicht die richtige Lösung für ein beschäftigtes Transaktionsverarbeitungssystem, aber es ist den Herstellern durchaus zu gestatten, ihre Produkte »continuous« zu nennen.

Unbegrenzte Wiederherstellungspunkte zu haben sieht tatsächlich auf Papier besser aus als in der Praxis. Wer einen SQL-Server auf einen Zeitpunkt zurücksetzen möchte, bevor etwas die Daten verbog, der möchte nicht raten, wann dieser Zeitpunkt war. Nötig ist in diesem Fall ein SQL-Server-taugliches CDP-System, das eine Restore-Timeline mit System-Checkpunkten, benannten Transaktionen und anderen applikationsspezifischen Ereignissen erzeugt. Einfacher gesagt als getan.

Die Hersteller verfolgen unterschiedliche Wege zur Erzeugung von CDP-Produkten. Replikationsanbieter, darunter »Xosoft«, »FalconStor« und Kashya, haben ihre existierenden Techniken modifiziert und erlauben CDP durch Journalaufzeichnung der Änderungen. Sie bieten zeit- und/oder applikationsspezifische Kommentare in den Journalen und bilden eine Rollback-Engine. Xosoft ist so weit gegangen, Rollback zum Standardfeature ihres Wansync-Replikationsprodukts zu machen.

Neben Softwarelösungen offerieren verschiedene Hersteller inzwischen CDP-Appliances. Eine Applikation wie CDP in einer Appliance zu verpacken, beschleunigt die Implementation und lässt Host-Applikationen mehr Prozessorzyklen übrig. Weiter erlaubt es den Herstellern, ihr Geld in Funktionen, Features und Tests statt in die Portierung zu investieren, und ermöglicht den Benutzern ungewöhnlicher Applikationen oder Betriebssysteme, CDP zu nutzen. Mehr als die Hälfte der Beantworter der Leserumfrage bevorzugt Appliances.

Revivos CPS-1200-Appliance beispielsweise sieht für Server und Applikationen einfach wie ein weiteres Disk-Array aus. Die Appliance speichert nicht die Serverdaten, sondern nutzt die Fibre-Channel-Arrays, um ihre CDP-Daten zu speichern, während der Server direkt mit dem primären Speicher-Array kommuniziert. Der Administrator muss einfach nur seine Volume-Manager so einstellen, dass er die primären Platten der Applikation auf die von der Appliance präsentierten LUNs spiegelt.

Da es keine Agenten gibt, weiß die Revivo-Appliance nicht, wann die Applikation Checkpunkte oder signifikante Ereignisse erreicht. Benötigt der Administrator Zugriff auf ältere Versionen der von der Applikation genutzten Volumes, dann erzeugt er eine Sammlung virtueller Volumes für einen Zeitpunkt hinunter zum zweiten. Sobald die Ansicht erzeugt ist, kann er sie auf seinem Host mounten und die Daten überprüfen.

Erwartungen managen
Jede Änderung aller Daten für immer zu speichern klingt verlockend, aber es ist weder praktisch noch wünschenswert. Ein simples CDP-System wird sein Änderungsjournal als First-in/First-out-Stack (FIFO) ausführen und die ältesten Änderungen aus dem Journal löschen, sobald sie ein gewisses Alter erreichen oder Speicherplatz dazu zwingt. Wer ältere Daten wiederherstellen möchte, sollte konventionelle Backups haben.

Ausgetüfteltere Produkte, beispielsweise die von Symantec, »TimeSpring« und »Iron Mountain Digital LiveVault«, konsolidieren ihre Änderungsjournale. Dies reduziert die Anzahl der Wiederherstellungspunkte, wenn die Daten älter werden, und behält beispielsweise unbegrenzte Versionen für einen Tag, tägliche Versionen für zehn Tage und wöchentliche Versionen für einen Monat. Die Erfahrung lehrt, dass die häufigsten Wiederherstellungsanfragen für kürzlich modifizierte, gelöschte oder beschädigte Dateien gestellt werden. Konsolidierte Journale werden Administratoren also erlauben, diese Wünsche mit hoher Genauigkeit zu befriedigen, während sie Zugriff auf ältere Daten mit geringerer Genauigkeit haben.

Signifikant unterscheiden sich dateiorientierte Systeme wie Microsofts DPM und Symantecs Backup-Exec 10d von Block-/Volume-orientierten Produkten in den verfügbaren Restore-Methoden. Blocksysteme werden typischerweise ein virtuelles Volume erzeugen, von dem der Administrator mounten und Daten extrahieren kann. Angebote, die auf Dateien basieren, bieten häufig feinere Restore-Optionen, die Administratoren erlauben, nach Dateiversionen zu suchen, ohne mehrfach Volumes mounten zu müssen. Einige erlauben sogar den Endbenutzern, eigene Dateien zu betrachten, zu suchen und wiederherzustellen.

CDP kann eine großartige Lösung für viele Datensicherungsprobleme sein, aber es ist noch immer eine reifende Technik. Mit Ausnahme von Iron Mountain Digital Livevault stützen sich die Hersteller auf die Zugriffssteuerung der Dateiserver und Netzwerksicherheit, um Daten vor spionierenden Augen zu schützen, statt Verschlüsselung in ihre eigenen Produkte zu implementieren.

Es ist nicht empfehlenswert, konventionelle Backups mit CDP zu ersetzen. Administratoren sollten ihre alten Backup-Systeme für die Sicherung von System und Applikationen mit geringen Änderungsraten behalten.

Einige CDP-Systeme unterstützen Bare-Metal-Restores. Aber selbst wenn brandneue CDP-Systeme diesen schwierigen Job so gut wie konventionelle Backup-Produkte erledigten, würde die Verwendung von CDP für Systemlaufwerke das CDP-Daten-Repository dicht machen, denn sämtliche Änderungen temporärer Systemdateien und -logs würden verzeichnet werden.
dj@networkcomputing.de


Jetzt kostenfreie Newsletter bestellen!

Matchmaker+