Zwei Kriterien sind ausschlaggebend dafür, welche Technik für welche Umgebung die richtige ist: Wie viel Ausfallzeit ein Unternehmen verkraften kann und wie hoch der Datenverlust maximal sein darf. Nach diesen Gesichtspunkten sollte die passende Softwarelösung ausgewählt werden, denn die verschiedenen Lösungen am Markt bieten ein unterschiedliches Maß an Ausfallsicherheit und Datenschutz.

Eine Basisanwendung für Disaster Recovery ist das Backup, denn für die Wiederherstellung von Daten und System genügen im Grunde schon Sicherungskopien des Datenbestandes. Traditionelle Datensicherung ist relativ einfach in der Anwendung und verlangt angesichts des hohen Fassungsvermögens der neuesten Bandformate nur wenig Investitionen in Hardware. Mit einer Backup-Lösung, die gängige Plattformen und Applikationen unterstützt und über umfassende Agenten und Optionen für verschiedenste Storage-Management-Anwendungen wie Hierarchisches Speicher-Management (HSM) oder Snapshot-Techniken verfügt, kann ein Unternehmen heute alle Geschäftsdaten effizient sichern.

Recovery kostet Zeit

Ein Nachteil herkömmlichen Backups ist allerdings, dass die manuelle Wiederherstellung gerade von großen Datenmengen sehr lange dauern kann. Wurden nach einem Crash die fehlerhaften Hardwarekomponenten repariert oder ersetzt und die Volumes neu partitioniert, müssen das komplette Betriebssystem, sämtliche Treiber, Updates und Anwenderprofile sowie die Backup-Software installiert werden. Erst dann kann das Restore der Daten über die Backup-Medien beginnen. Während dieses gesamten Prozesses ist das System nicht verfügbar, und macht der Administrator einen Fehler, muss er alle Schritte wiederholen. Abhilfe schaffen Techniken, die das Recovery automatisieren und beschleunigen.

Intelligente Backup-Erweiterungen

Intelligent Disaster Recovery (IDR) ermöglicht das Wiederherstellen von Systemen, ohne dass zuerst das Betriebssystem komplett neu installiert werden muss. Dazu werden spezielle IDR-Medien mit einer "Recovery Engine" sowie essenziellen Systemdateien erstellt, über die in Verbindung mit der Restore-Funktion der Backup-Software der Wiederherstellungsprozess nach einem Systemausfall eingeleitet werden kann.

Dazu wird über die IDR-Medien zunächst ein Reboot ausgeführt und die vorherige Festplattenpartitionierung und -formatierung wiederhergestellt. Darauf folgt die Installation des Betriebssystems über die Installations-CDs und das automatische Zurückspeichern der Daten von den Backup-Bändern. Die Backup-Software muss dabei dank der Recovery Engine auf den IDR-Medien nicht installiert sein. Je nach IDR-Lösung kann der Zustand des Systems zum Zeitpunkt der letzten vollen, differenziellen oder inkrementellen Sicherung wiederhergestellt werden.

Diese Automatisierung spart viel Zeit und Nerven und setzt keine genauen Kenntnisse der Systemkonfiguration voraus. Ist der Administrator zum Zeitpunkt des Ausfalls nicht anwesend, kann das Recovery dadurch auch von anderen Mitarbeitern vorgenommen werden. Kompliziert wird es allerdings in Umgebungen mit verschiedenen Betriebssystemen und mehreren Servern, denn hier müsste theoretisch für jede Maschine ein eigener Satz IDR-Medien erstellt werden.

Mehrstufiges Recovery für alle Clients

Eine Lösung für solche Umgebungen bietet "Netbackup" von Veritas mit der "Bare-Metal-Restore"-(BMR)-Technik: Auch mit ihr kann ein Recovery ausgeführt werden, ohne dass zuerst das Betriebssystem installiert werden muss. BMR basiert jedoch auf einer mehrstufigen Architektur mit einem Haupt-Server, einem File-Server und einem Boot-Server und liefert bei Bedarf für jeden in die Sicherungsstrategie eingebundenen Client ein individuelles Boot-Image für dessen Recovery. Im Gegensatz zu IDR-Medien enthält dieses Boot-Image das komplette Client-Betriebssystem inklusive aller Partitionierungsinformationen und Konfigurationsdateien für den speziellen Rechner. Alle Prozesse inklusive sämtlicher weiterer Reboots nach dem ersten Booten und dem abschließenden Bereinigen der lokalen Festplatte laufen komplett automatisch ab.

Wichtig für ein schnelles Disaster Recovery ist auch der richtige Aufbewahrungsort für die Medien: Werden die Kopien vor Ort gelagert, sind sie im Notfall schnell zur Hand, es steigt aber auch die Gefahr, dass sie etwa bei einem Brand zerstört werden. Deshalb sollten in der Primär-Site oder an einem alternativen Standort Kopien der Backup-Bänder hergestellt und extern gelagert werden, so dass sie auch bei einem Ausfall eines kompletten Standorts geschützt sind. Vereinfacht wird das Anfertigen von Duplikaten an einem zweiten Standort durch eine "Vaulting"-Funktion der Backup-Software. Vaulting automatisiert die gesamte Verwaltung dieser extern gelagerten Bänder vom Auswurf der Duplikate in den Ein- und Ausgabeschacht des Tape-Systems über die Erstellung von Pick/Pull-Protokollen bis hin zur Überwachung von Aufbewahrungsfristen und macht damit einen eigenen Administrator für den zweiten Standort überflüssig.

Daten replizieren und synchronisieren

Mit Backup-Technologien können Unternehmen einen gravierenden Produktionsausfall aufgrund verlorener Daten zu einem gewissen Grad vermeiden und mit Techniken wie IDR oder BMR auch das Recovery beschleunigen. Dennoch dauert ein komplettes Recovery in großen Umgebungen oft einige Stunden oder sogar Tage, und es lässt sich lediglich der Zustand des Servers zum Zeitpunkt des letzten Backups wiederherstellen. Anwender, deren Systeme rund um die Uhr verfügbar sein müssen und die keinerlei Datenverlust in Kauf nehmen können, sollten deshalb zusätzlich Replikationstechniken einsetzen.

Unter Datenreplikation versteht man das Kopieren von Daten von einem Quell-Server auf einen Ziel-Server sowie das kontinuierliche Synchronisieren der Kopien bei Änderungen an der Datenquelle. Derzeit sind zwei Arten von Datenreplikation - synchron und asynchron - gebräuchlich. Bei der synchronen Replikation müssen die Daten auf dem Zielort gespeichert werden, bevor der Schreibvorgang auf dem Host-System abgeschlossen ist. Das garantiert maximale Datenintegrität auf dem Ziel-System, da dieses so immer exakt den gleichen Datenbestand enthält wie die Quelle. Jedoch kann diese Replikationsart Performance-Einbußen auf dem Quell-System mit sich bringen, vor allem bei langsamen Netzwerkverbindungen. Abhilfe schaffen hier Lösungen, die bei Verbindungsproblemen dynamisch von synchronem auf asynchronen Modus wechseln. Nach Behebung der Engpässe kann dann wieder zur synchronen Replikation übergegangen werden.

Bei asynchroner Replikation wartet der Quell-Server vor dem Beginn des Kopiervorganges nicht auf eine Bestätigung durch das Ziel-System. Die Daten können aneinander gereiht und in Form von Batches während des Netzbetriebs übertragen werden. Einige Softwarelösungen für asynchrone Replikation benutzen Journaling-Funktionen, mit denen die Daten am Ziel in genau derselben Reihenfolge gespeichert werden, in der sie auf dem Herkunfts-Server liegen.

Replikation und Cluster

Replikationstechniken eignen sich ideal für WAN-Verbindungen (WAN = Wide Area Network) und ermöglichen so das Anfertigen eines Spiegels an einem oder mehreren weit entfernten Standorten, mit dem die Produktivität nach dem Ausfall einzelner Systeme oder einer ganzen Site binnen kürzester Zeit wiederhergestellt werden kann. Datenreplikation hat darüber hinaus den Vorteil, dass sie nicht nur als Teil eines Disaster-Recovery-Plans fungieren kann, sondern die Nutzung des Standby-Systems für weitere Anwendungen wie Backup, Datenanalyse oder für Tests ermöglicht und damit den Return on Investment für die Disaster-Recovery-Lösung verbessert.

Wer maximalen Datenschutz braucht, sollte Replikation mit Clustering kombinieren: Konfigurationen in lokalen Umgebungen mit einer Applikation auf zwei Cluster-Knoten und dem Datenbestand auf einem Shared System gewährleisten nahtloses Failover und Datenintegrität. Fällt allerdings das Shared System aus, müssen die Daten auch hier mühsam von Backup-Bändern zurückgespielt werden. Werden die Daten dagegen repliziert, kann bei Ausfall eines Knotens jeder andere Cluster-Knoten die Applikation problemlos wieder starten. WAN-Cluster, bei denen das Failover zwischen geografisch sehr weit voneinander entfernten Sites mit replizierten Daten stattfinden kann, ermöglichen sofortiges Disaster Recovery nach dem Ausfall eines ganzen Standortes und bieten damit eine maximale Verfügbarkeit der Daten.

Nicht jedes Unternehmen braucht diesen hohen, aber auch teuren Schutz seiner Daten. Welche Technik zum Einsatz kommt, sollte deshalb genau abgewogen werden. Ein Buchungssystem zum Beispiel kann sich keinen Datenverlust erlauben und erfordert daher eine sehr hohe Aktualität der wiederhergestellten Daten. Es muss aber nicht unbedingt sofort nach einem Ausfall wieder in Betrieb gehen, wenn etwa außerhalb der Öffnungszeiten nicht auf die Daten zugegriffen wird. In diesem Fall können Replikation und Snapshot-Techniken die richtigen Lösungen sein. Andere Unternehmen kommen mit herkömmlichen Tape Backups aus: So ist beispielsweise ein Web-Server gegenüber Datenverlusten relativ tolerant, muss aber konstant verfügbar sein.

Auch innerhalb eines Unternehmens können natürlich unterschiedliche Anforderungen an die Aktualität der Daten und die tolerierbare Ausfallzeit bestehen. Die Berechnungen, die der Implementierung einer Disaster-Recovery-Lösung vorausgehen, sollten deshalb so genau wie nur möglich sein, denn auch eine kleine Lücke in der Planung kann im Katastrophenfall unvorhersehbare Folgen haben. Ideal sind Lösungen, die sich problemlos erweitern und mit anderen Disaster-Recovery-Technologien kombinieren lassen. So kann die Disaster-Recovery-Strategie schnell an neue Anforderungen an Datensicherheit und -verfübarkeit des Unternehmens oder einzelner Abteilungen angepasst werden. (kk)

*Frank Bunn ist Marketing Manager, Emea Product and Solutions, bei Veritas in München.

Angeklickt

Bei der Wahl der richtigen Recovery-Strategie sollten sich die IT-Verantwortlichen zwei Fragen stellen: Wie viel Ausfallzeit kann das Unternehmen verkraften, und wie hoch darf der Datenverlust maximal sein? Die Berechnungen, die vor der Entscheidung für eine bestimmte Disaster-Recovery-Lösung angestellt werden, sollten so präzise und so erweiterbar wie möglich sein um im Fall einer Katastrophe vor unliebsamen Lücken gefeit zu sein.

Abb.1: Synchrone Datenreplikation

Beim synchronen Replizieren ist der Kopiervorgang erst dann abgeschlossen, wenn der Ziel-Server quittiert hat. Der Nachteil: Performance-Einbußen beim Quell-Server. Quelle: Veritas

Abb.2: Asynchrone Datenreplikation

Der Quell-Server versendet laufend Daten, ohne auf eine Bestätigung des Zielsystems zu warten. Der Nachteil: Daten können in verkehrter Reihenfolge ankommen. Quelle: Veritas