Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.05.2001 - 

Speichernetze/Sicherungsstrategien mit dem Restore beginnen

Das Pferd von hinten aufzäumen

Ein Sicherungskonzept als alleinige Leitlinie der Backup- und Recovery-Strategie stößt schnell an seine Grenzen. Denn eine Beschleunigung des Backups kann sich leistungsmindernd in einem umständlichen Recovery-Prozess niederschlagen. Deshalb sollte schrittweise vorgegangen werden: die betriebsspezifische Situation analysieren und die Anforderungen definieren und erst dann das passende Sicherungskonzept entwerfen. Von Robert Thurnhofer*

Grundsätzlich sehen sich Sicherungslösungen, unabhängig von ihrer Art und Ausprägung, von Haus aus mit Vorurteilen konfrontiert. Sie "tragen nicht direkt zum Unternehmenserfolg bei", "schützen vor Ereignissen, die vielleicht nie eintreten" und "sind technisch so komplex, dass kostspielige Betreuung und Kontrolle erforderlich werden", lauten die mehr oder minder offen vorgetragenen Vorwürfe aus dem Management. Und jedes dieser "Argumente" besitzt in der Tat einen wahren Kern. Ebenso wahr ist aber, dass im Zusammenhang mit den Sicherungslösungen immer die Qualität sowie die Verfügbarkeit der Daten gemeint sind, und diese zählen bekanntlich zum Kapital eines Unternehmens in der E-Business-Welt. Dass ein sorgfältiges Backup einen wirksamen Schutz gegen Datenverluste und die Unbill des Online-Betriebs darstellt, gehört ebenfalls zu den weithin akzeptierten Tatsachen.

Die unumgängliche Konsequenz hieraus wird allerdings häufig nicht erkannt. Denn eine zu einseitige Konzentration auf die Backup-Durchführung, den vermeintlich ersten und wichtigsten Schritt eines Sicherungs- und Wiederherstellungskonzepts, führt in der Regel dazu, dass der eigentlich entscheidende Punkt, das Recovern, vernachlässigt wird. Auffällig wird dies, wenn in Unternehmen ohne Diskussionsbereitschaft ein maximales Zeitfenster für die Datensicherung festgelegt wird und aufgrund dessen bestimmte Backup-Verfahren zum Einsatz kommen, die eine zeitintensivere Wiederherstellung bewirken und damit im Schadensfall das Ursprungsziel ad absurdum führen. Mehr noch: Durch die einseitige Fokussierung auf das Backup findet eine intensive Beschäftigung mit den tatsächlichen Erfordernissen erst gar nicht statt. Und da sich das Thema Backup und Recovery mit einer Versicherung vergleichen lässt, wird man die tatsächliche Stärke oder Schwäche eines eingeführten Verfahrens in letzter Konsequenz erst dann erkennen, wenn es das erste Mal zum Tragen kommt.

Ein Grund für diese Situation ist, dass die Komplexität des Backup- und Recovery-Themas von Anwendern und Herstellern der Anwendungspakete schlichtweg unterschätzt wird. Man sollte sich aber immer wieder daran erinnern, dass sich nur das wiederherstellen lässt, was tatsächlich gesichert wurde. Dieser Satz klingt zugegebenermaßen trivial, bringt aber die grundsätzliche Problematik auf den Punkt. Wer beispielsweise gezippte Dateien per Backup sichert, wird auch ausschließlich komplette Zip-Dateien wiederherstellen können; wer (logische) Fehler oder Viren-verseuchte Dateien oder Blöcke sichert, wird ebenso konsequent Fehler oder Viren-verseuchte Dateien restaurieren.

Datenbank und gelöschte Dateien"Gelöschte Dateien" können ebenso zur Wurzel eines Übels werden. Hier wird nämlich im Falle eines Backups, das auf einem inkrementellen oder differenzialen Verfahren basiert, mitunter der Plattenspeicher des Produktivsystems bei der Wiederherstellung überladen.Wer Zweifel hegt, sollte sich nur vergegenwärtigen, dass im Recovery-Fall bis zum letzten vollständigen Backup sämtliche Dateien, auch gelöschte, von den Bändern geschrieben werden. Da Löschungen in der Regel nicht protokolliert und ebenso wenig automatisch nachvollzogen werden, kann sich ein Overflow einstellen, wenn der Speicherplatz zwischenzeitlich von anderen, jetzt ebenfalls wiederhergestellten Dateien belegt gewesen war. Ein manuelles Nachlöschen wäre folglich erforderlich.

Noch offensichtlicher wird das grundsätzliche Problem bei den Anforderungen einer Datenbank. Der "ideale" Backup, eine vollständige Sicherung, ist bei einer Online-Datenbank nicht permanent machbar. Deshalb muss bei einem Crash zunächst eine beschädigte Datenbank mitunter von Laien wieder online geschaltet und mit Hilfe eines Backups sowie DB-eigenen Tools in einen konsistenten Zustand gebracht werden. Der architektonische Aufbau des Datenbank-Management-Systems legt dabei Art und Abfolge der Recovery-Schritte fest. Bedauerlicherweise gehört dies zu den wenig fokussierten Bereichen der Hersteller, die ihre Systeme lieber mit dem Hinweis auf Funktionen und Features und nicht durch die Beschreibung der Recovery-Möglichkeiten an den Mann bringen. Zudem legt man bei Datenbanken wie dem Microsoft SQL-Server schon mit dem Design - möglicherweise unbewusst - fest, welche Backup- und Recovery-Möglichkeiten später überhaupt zur Verfügung stehen können.

Zuerst die BestandsaufnahmeDie genannten Beispiele belegen, dass schon verhältnismäßig einfache Dinge zu erheblichen Problemen führen können. Speicherverwalter sollten deshalb genügend Überzeugungskraft besitzen, um dem Anwender eine intensive Auseinandersetzung mit dem Zusammenspiel von Backup und Restore und seinen geschäftlichen Erfordernissen nahezulegen. Er muss sich zuvorderst im Klaren darüber sein, welchen Sicherungsbedarf seine Daten und ihre Änderungen tatsächlich mit welcher Frequenz verlangen. Dabei sollte die Wiederherstellung den primären Blickwinkel bestimmen. Wichtig in diesem Zusammenhang sind auch Überlegungen, welchen Zeitraums es im schlechtesten Fall bedarf, einen korrumpierten Datenbestand zu "entdecken". Wenn bestimmte betriebswirtschaftliche Anwendungen ausschließlich monatlich genutzt werden, kann beispielsweise der letzte korrekte Backup-Datenbestand älter als ein Monat sein.

Erst wenn diese Bestandsaufnahme durchgeführt ist, lässt sich eine ideale Backup- und Recovery-Strategie für ein Unternehmen formulieren. Diese wird sicher nicht eins zu eins umsetzbar sein. Sie wird zudem keinem Pauschalkonzept folgen, da in jedem Unternehmen unterschiedliche Ausgangslagen und Anforderungen gelten. Das Wissen über den Bedarf bietet allerdings eine Grundlage, etwaige Kompromisse in Bezug auf Backup und Recovery überhaupt einzugehen und deren Folgen abzuschätzen. Sind die Grenzen eines Recovery-Zeitfensters beispielsweise unumstößlich, muss eventuell eine Dezentralisierung des Backups eingeleitet werden, um in parallelen Schritten mit der zur Verfügung stehenden Zeit bei der Wiederherstellung auszukommen. Alternativ könnte die Entscheidung aber ebenso lauten, bei der Wiederherstellung bewusst das Risiko einer längeren Offline-Zeitspanne einzugehen.

All diese Überlegungen schlagen sich auch in der Formulierung der unternehmenseigenen Sicherungspolitik und -richtlinien nieder. Die einzelnen Anwender sollten so gut wie möglich informiert und die Sicherheitsfunktionen möglichst einfach gestaltet werden. Und erst wenn diese Fragen und Aufgaben geklärt sind, sollte man sich näher mit der Auswahl von Hardware und Software beschäftigen. Und dann, aber auch erst dann, dürfen auch wieder Funktionen und Features in die Diskussion einfließen.

*Robert Thurnhofer ist Divisional Manager Storage Technology Emea bei Computer Associates in München.

Elf Tipps ...... zum richtigen Backup und Recovery

1. Sämtliche Anforderungen und Rahmenbedingungen an das Recovery müssen im Vorfeld bekannt sein. Insbesondere die maximal akzeptable Downtime bei tatsächlich wichtigen (!) Daten muss festgeschrieben werden.

2. Die Anforderungen der Infrastrukturhersteller (etwa Betriebssysteme, Datenbanken oder Anwendungen) an das Recovery sind zu beachten. Insbesondere in welcher Reihenfolge und welchen Formaten System- oder Logdateien benötigt werden, muss dokumentiert sein.

3. Das realisierbare Vorgehen sollte von dem idealisierten Recovery-Szenario abgeleitet werden. Es folgt am besten der Formel: Backup-Strategie = Summe von Recovery-Anforderungen +/- Kompromisse an Backup & Restore. Etwaige Kompromisse in Bezug auf Datenverluste und Systemausfälle müssen bekannt und dokumentiert sein.

4. Die Frequenz eines vollständigen Backups muss hoch genug sein, dass die Auswirkungen eines "worst case" in einem noch tolerierbaren Zeitraum abgefangen wird.

5. Es gilt, ausreichend Backup-Versionen vorzuhalten, um auch bei später Entdeckung korrumpierter Daten die Wiederherstellung eines ordnungsgemäßen Status zu gewährleisten.

6. Etwaige Tuning- oder Ausfallschutz-Maßnahmen müssen auf ihre Effekte auf das Restore hin analysiert werden. Beispielsweise sind Daten bei Raid-5 schneller zu lesen als zu schreiben.

7. Nie, wirklich nie, sollte Raid-1 oder Spiegelung als Ersatz für einen Backup betrachtet werden.

8. Es ist noch kein (Recovery-) Meister vom Himmel gefallen: In loser Folge, aber regelmäßig muss die Backup- und Recovery-Strategie von den Beteiligten "durchgespielt" werden. Dies dient gleichzeitig zur Überprüfung, ob das Konzept noch mit den aktuellen Rahmenbedingungen im Einklang ist.

9. Jeder Sicherungsschritt (wer, was, wann, wie und wo) ist in einem Logbuch zu protokollieren. Verantwortliche müssen benannt sein.

10. Die Nachteile und Auswirkungen der eingesetzten Backup-Verfahren sind transparent zu machen. Insbesondere bei inkrementellem Backup ist die durch häufiger genutzte Bänder eventuell längere Recovery-Zeit zu beachten; gelöschte odermit Hilfe eines hierarchischenSpeicher-Managements migrierte Dateien befinden sich möglicherweise nach dem Restore wieder auf der Festplatte.

11. Ausgelagerte Backup-Medien müssen jederzeit zugänglich bleiben.