Backup ist seit jeher ein ebenso ungeliebtes wie unumgängliches Stiefkind der Netzwerkwelt. Der lästige und Zeit raubende Routinejob wird fast schon traditionell über eine ebenso eingeschliffene Standardlösung abgewickelt: Server-basierte Backup-Software sichert nachts, wenn tunlichst kein Anwender Dateien geöffnet hat, die auf dem Server lagernden Daten gemäß vorgeplanter Jobs auf Bänder in einem Autoloader. Gelegentlich tauscht der Administrator die im Bandwechsler befindlichen Tapes gegen neue und verstaut die alten an einem sicheren Ort.
Zwar lässt diese Methode schon unter dem Gesichtspunkt der Datensicherheit einiges zu wünschen übrig, wie wir später noch sehen werden, doch immerhin handelt es sich um einen pragmatischen Ansatz: Er funktioniert, und er verursacht nicht viel Aufwand, zumindest in homogenen, auf wenige Server zentrierten Netzen. In heutigen LANs, in denen unternehmenskritische Daten auf einer steigenden Zahl verteilter Server und Clients lagern, stößt ein solcher Ansatz jedoch bald an seine Grenzen.
Zu den Schlüsselfaktoren, die ein Umdenken in der Backup-Strategie erforderlich machen, zählt neben der zunehmenden Bedeutung der gespeicherten Informationen für die wirtschaftliche Leistungsfähigkeit des Unternehmens vor allem die geradezu explodierende Datenmenge: Eine jährliche Verdopplung stellt heute eher die Regel als die Ausnahme dar. Dies macht es immer schwieriger, Backups nach der traditionellen Offline-Methode in den zur Verfügung stehenden Zeitfenstern abzuwickeln. Hinzu kommen die Verwaltungsprobleme, die sich aus heterogenen Umgebungen und verteilten Unternehmensstrukturen mit zahlreichen Außenstellen ergeben.
Hier verspricht die Software-Industrie dem geplagten Administrator Abhilfe. Tatsächlich bringen professionelle Backup-Pakete meist alle Komponenten mit, die ein wasserdichtes Sicherungskonzept erfordert. Ihr Automatisierungsgrad ist zum Teil erstaunlich. Über vorgeplante Sicherungs- und Bandrotationsschemata und hilfreiche Wizards nehmen sie dem Netzwerkverwalter Routineaufgaben ab. Dies verführt den Administrator oft dazu, die Werkzeuge mit der Lösung selbst zu verwechseln - ein fataler Irrtum. Denn ohne bewusste, vorausschauende Planung und Kontrolle verpufft die Wirkung selbst der besten Tools. Effizientes und sicheres Backup beginnt nicht mit Tape und Streamer, sondern mit Papier und Bleistift.
Basiskonzepte
Zunächst einmal gilt es festzulegen, welche Daten überhaupt gesichert werden müssen und wie sie im Netzwerk verteilt sind. Dieser auf den ersten Blick trivial wirkende Schritt birgt mehr Tücken, als man zunächst vermuten würde, und bestimmt in hohem Maß die Kosten, die für die Backup-Lösung anfallen.
Stellen Sie zunächst einmal eine Liste aller Rechner auf, auf denen wichtige Daten lagern. Dazu gehören vorrangig alle Server, zunehmend finden sich aber auch auf Clients Informationen, die für das tägliche Geschäft unverzichtbar sind. Erfassen Sie für jeden Rechner den Typ (Server/Client), das Betriebsystem sowie die Menge der gespeicherten Daten. Notieren Sie sich bei Datenbank- und Applikations-Servern zudem die implementierten Datenbanken und Anwendungen. Die so erstellte Liste dient als Grundlage für die Entwicklung eines sicheren und vor allem kostengünstigen Backup-Konzepts.
Zunächst einmal lässt sich aus der Aufstellung der Gesamtumfang der zu sichernden Daten ersehen. Dabei sollten Sie allerdings berücksichtigen, dass alle einschlägigen Untersuchungen den jährlichen Zuwachs der Datenmenge in einem Unternehmen auf 100 bis 150 Prozent einschätzen. Soll Ihre Backup-Lösung also auch in zwei Jahren noch funktionieren, müssen Sie den errechneten, ohnehin erklecklichen Datenumfang wenigstens verdoppeln.
Schon die Information über die erforderliche Datenmenge lässt zwei für das Sicherungskonzept wesentliche Schlussfolgerungen zu: Ob das Backup komplett offline erfolgen kann oder teilweise online laufen muss und ob eher ein zentrales oder ein dezentrales Sicherungskonzept angebracht ist.
Strategien
Die wünschenswerteste, weil technisch unkomplizierteste Sicherungsform ist das Offline-Backup während Zeiten, zu denen der Zugriff von Benutzern auf die zu sichernden Rechner unterbunden werden kann. Das vermeidet zum einen Zugriffsschwierigkeiten durch noch geöffnete Dateien, zudem steht die gesamte Bandbreite des Netzes für den durch das Backup entstehenden Verkehr zur Verfügung. Allerdings setzt Offline-Backup ein genügend breites Zeitfenster ohne die Notwendigkeit zur Netzwerkaktivität der User voraus.
Um zu beurteilen, ob in Ihrem konkreten Fall ein Offline-Backup möglich ist,
errechnen Sie das nötige Zeitfenster. Teilen Sie einfach die zu sichernde Datenmenge durch den typischen Durchsatz ihrer Streamer-Hardware. Bei einem DAT/DDS-Autoloader mit einer Schreibrate von rund 6 GByte/h und einer zu sichernden Datenmenge von 100 GByte etwa umfasst das notwendige Zeitfenster gut 16 Stunden. Das scheint auf den ersten Blick ein Offline-Backup auszuschließen. Allerdings lässt sich an der Backup-Zeit feilen - zum einen durch den Einsatz leistungsfähigerer Hardware, zum andern durch ein dezentrales Sicherungskonzept.
Ersetzen Sie etwa den DAT/DDS-Autoloader durch ein leistungsfähigeres DLT-8000-System mit einer Durchsatzrate von 20 GByte/h, schrumpft die notwendige Zeitspanne auf problemlose fünf Stunden. Auch Tape-Libraries mit mehreren Bandlaufwerken und geeigneter Backup-Software minimieren die Sicherungsdauer. Eine Alternative besteht im Aufsetzen mehrerer mit Streamern ausgestatteter Backup-Server, so dass sich das Datenvolumen aufteilen lässt. Auch in geographisch verteilten Umgebungen mit einer Zentrale und Außenstellen ist oft der dezentrale Einsatz mehrerer Backup-Systeme nicht zu umgehen.
Backup-Clients
Nachdem Sie nun Ihre Backup-Anforderungen erfasst und sich für ein Sicherungskonzept entschieden haben, gilt es, einen Anforderungskatalog für die geeignete Backup-Applikation zu formulieren.
Nehmen Sie dazu wieder die eingangs erstellte Backup-Liste zur Hand. Für alle dort aufgeführten Betriebssysteme muss die gesuchte Lösung Client-Agenten mitbringen, die - am besten im Push-Verfahren - die zu sichernden Daten an den Backup-Server weiterreichen. Vorteilhaft wirkt sich dabei die Möglichkeit zur Datenkompression bereits auf dem Client aus: Die dadurch erreichte Reduktion der Dateigrößen beschleunigt das Backup und entlastet gleichzeitig das Netz.
Fassen Sie anschließend diejenigen Rechner auf Ihrer Liste genauer ins Auge, die als Datenbank- oder Applikations-Server arbeiten. Mit hoher Wahrscheinlichkeit lassen sich nicht alle davon während der Backup-Zeit von Zugriffen isolieren. Rechner, auf denen Groupware- oder Kommunikationsanwendungen laufen, Mailbox-Systeme oder auch Webserver müssen rund um die Uhr an sämtlichen Wochentagen ihren Dienst versehen.
Für solche datenbankgestützten Systeme benötigen Sie spezielle Agenten, die eine Online-Sicherung der entsprechenden Dateigruppen in konsistentem Zustand erlauben. Nutzen Sie nicht auf Datenbanken basierende Anwendungen, die gleichwohl während der Sicherungszeit Dateien öffnen oder modifizieren, muss eine Open-File-Backup-Option verfügbar sein. Solche Lösungen fertigen während einer zugriffsfreien Zeit quasi einen Schnappschuss des geöffneten Files oder der Dateigruppe auf der Server-Platte an und sichern dann diese Momentaufnahme anstelle der Originale.
Bei Servern oder Multiuser-Systemen muss der Backup-Agent zudem in der Lage sein, Benutzerkonten und die zugehörigen Zugriffsberechtigungen sowie die Datenbank der definierten Netzwerkobjekte zu sichern. Dies betrifft beispielsweise bei Netware die NDS, auf der Windows-Seite etwa SAM und Registry. Die manuelle Wiederherstellung solcher Strukturen - falls überhaupt möglich - wäre ohne vorhandene Sicherung äußerst aufwendig.
Backup-Server
Auch der Backup-Server selbst hat eine ganze Reihe von Kriterien zu erfüllen. Dies beginnt schon bei der Architektur der Applikation. Sie besteht grundsätzlich aus drei Komponenten. Die eigentliche Backup-Engine läuft immer auf dem Rechner, an dem auch die Sicherungslaufwerke angeschlossen sind.
Eine Backup-Datenbank - sie kann auf einer gängigen relationalen Datenbank basieren oder proprietär implementiert sein - speichert die Backup-Jobs, die Daten der gesicherten Files, die Bezeichnungen der verwendeten Datenträger und andere zur Datensicherung relevante Informationen. Als Schnittstelle zur Verwaltung und Steuerung von Datenbank und Engine dient die Managementkonsole.
Die Backup-Datenbank mit ihren Informationen zu Abläufen und Datenträgern bildet das Herzstück der Datensicherung. Geht sie verloren, lassen sich konsistente Restores - wenn überhaupt - nur noch mit massiver manueller Nacharbeit durchführen. Daher sollte die Möglichkeit bestehen, die Datenbank auf andere Rechner - vorzugsweise Server mit demselben Betriebssystem - zu replizieren.
Fällt in einer solchen Konfiguration der vorgesehene Backup-Server aus, lässt sich das System mit der replizierten Datenbank durch einfaches Aufspielen der Backup-Engine schnell zum neuen Backup-Server befördern. In Umgebungen mit mehreren Backup-Servern sollte aus dem gleichen Grund jedes System eine komplette Kopie aller Sicherungsdaten vorhalten - fällt einer der Server aus, kann ein anderer seine Jobs mit übernehmen. Umfasst Ihr Backup-Konzept jedoch über WAN-Verbindungen angeschlossene, entfernte Backup-Server, so verursacht eine solche Lösung zu viel Verkehr im Netz. In diesem Fall ist trotz der Einbuße an Sicherheit eine Lösung mit jeweils lokalen Backup-Datenbanken vorzuziehen.
Gleich ob zentrales oder dezentrales Backup, in jedem Fall muss die Managementkonsole die Steuerung mehrerer Backup-Server von zentraler Stelle aus erlauben. Dabei sollte das jeweilige Betriebssystem der Sicherungsrechner keine Rolle spielen. Selbst wenn Sie dieses Feature im Moment in Ihrem momentan homogenen LAN noch nicht benötigen - gemischte Netzwerkumgebungen mit Windows- und Linux/Unix-Rechnern befinden sich auf dem Vormarsch.
Bandrotation
Um Ihnen die händische Erstellung von Backup-Plänen zu ersparen, offeriert eine leistungsfähige Managementkonsole die Möglichkeit zur Nutzung vorgeplanter Bandrotationsschemata.
Hinter den auf den ersten Blick verwirrenden Bezeichnungen, die an dieser Stelle auftauchen - inkrementelle Sicherung, differenzielles Backup, Großvater-Vater-Sohn et cetera - verbergen sich bei genauerem Hinsehen recht einfach nachzuvollziehende Überlegungen.
Alle Backup-Strategien bauen auf drei grundlegenden Verfahren zur Datensicherung auf. Dabei handelt es sich um die Vollsicherung sowie das differenzielle und inkrementelle Backup. Die beiden letzteren Methoden nutzen zur Reduzierung der zu sichernden Datenmenge - und damit zur Beschleunigung des Backups - die Tatsache aus, dass das Betriebssystem neu erstellte oder veränderte Dateien mit einem Archivbit kennzeichnet.
Das vollständige Backup überträgt unabhängig vom Zustand des Archivbits sämtliche Daten von der Festplatte des zu sichernden Systems auf Band. Dabei setzt die Backup-Software das Archivbit zurück und markiert die Dateien auf diese Weise als gesichert.
Differenziell und inkrementell
Das differenzielle Backup sichert alle Dateien, die seit dem letzten Voll-Backup erstellt oder modifiziert wurden. Dazu sucht es alle Files mit gesetztem Archivbit und schreibt sie auf Band. Ältere Varianten der Datei werden dabei von der neuen Version überschrieben.
Das Archivbit bleibt gesetzt, so dass die Dateien beim nächsten differenziellen Backup erneut mitgesichert werden. Dies erzeugt zwar eine gewisse Datenredundanz, hat jedoch den Vorteil, dass die Wiederherstellung verlorener Dateien lediglich die Tapes mit der letzten Vollsicherung sowie dem letzten differenziellen Backup erfordert.
Das inkrementelle Backup, manchmal auch als Zuwachssicherung bezeichnet, sichert alle Dateien, die seit dem letzten Backup-Lauf, gleich ob vollständig oder nicht, erstellt oder verändert wurden. Dazu schreibt es wie das differenzielle Backup alle Files mit gesetztem Archivbit auf Band, setzt anschließend aber das Archivbit zurück.
Zwar bleiben alle Dateivarianten erhalten, und die zu sichernde Datenmenge reduziert sich gegenüber dem differenziellen Backup nochmals. Allerdings erfordert die Wiederherstellung der Daten das Einspielen des letzten Voll-Backups plus aller seitdem erfolgten Zuwachssicherungen. Das bedeutet gegenüber dem Restore per differenziellem Backup in der Regel einen deutlich gesteigerten Arbeits- und Zeitaufwand.
Durch die Kombination von Vollsicherungen mit dazwischen liegenden differenziellen oder inkrementellen Sicherungen lässt sich schon mit wenigen Bändern der Datenzustand eines beträchtlichen Zeitraums abdecken. Dazu erstellen Sie einen Satz von Bändern, die Sie im Wechsel nach einem vorgeplanten Rotationsverfahren zur Sicherung benutzen.
Generationen
Das verbreitetste Rotationsschema ist die dreistufige Großvater-Vater-Sohn-Methode. Ausgehend von einem erstmaligen Voll-Backup führen Sie dabei an jedem Wochentag eine inkrementelle Sicherung durch. Dazu benötigen Sie vier Bänder (Mo, Di, Mi, Do: die Söhne).
Weitere drei Tapes (Woche-1 bis Woche-3: die Väter) verwenden sie hintereinander jeden Freitag zu einer erneuten Vollsicherung. Am letzten Freitag jedes Monats ersetzen Sie die Sicherung eines Wochenbands durch das Voll-Backup auf ein Monatsband (Jan, Feb, Mrz, ... : die Großväter).
Mit diesen nur 19 Bändern erfassen Sie die Daten eines ganzen Jahres und können diese jederzeit - allerdings nur in gewissen Abstufungen - wiederherstellen. Die Daten der letzten fünf Arbeitstage lassen sich tagesgenau rekonstruieren, die des letzten Monats nur zum jeweiligen Stand des Freitags. Files aus weiter zurückliegenden Monaten schließlich liegen nur noch in der Version vom Monatsende vor - aber immerhin ...
Neben der Nutzung der vorgeplanten Bandrotationsschemata erlaubt eine gute Managementkonsole auch die Definition eigener, auf spezielle Anforderungen zugeschnittener Backup-Jobs. Dabei sollte Ihnen das System die Wahl zwischen der differenziellen und inkrementellen Arbeitsweise lassen; nicht immer ist die Platz und Zeit raubendere Zuwachssicherung erforderlich.
Umfassende Alarmierungsmöglichkeiten - nicht nur per LAN und Ausdruck, sondern auch remote per E-Mail, Fax oder SMS - sorgen dafür, dass der Administrator ortsunabhängig sofort von Fehlern bei der Ausführung von Backup-Jobs informiert wird.
Interleaving-Strategien
Auch der Backup-Engine selbst gilt es genauer auf die Finger zu sehen. So hängt die Performance des Backups bei einer zentralen Sicherung nicht zuletzt von der Möglichkeit zur Parallelisierung der Datenströme aus mehreren Quellen - also von mehreren Rechnern - ab. Hier lassen sich zwei grundlegende Ansätze unterscheiden: File Interleaving und Block Interleaving.
Beim File Interleaving wartet die Software zunächst, bis eine Datei komplett im Cache eingetroffen ist. Dann schreibt sie das File am Stück auf das Band. Anschließend kommt die nächste Datei an die Reihe. Dieses Verfahren nutzt zwar die Kapazität des Mediums effizient aus, wirkt aber beim parallelen Sichern aus mehreren Datenquellen als Bremse: In diesem Fall müssen schon im Cache befindliche, eigentlich zum Schreiben bereitliegende Daten aus anderen Files warten.
Eine Optimierung macht das von Festplatten bekannte Block Interleaving möglich: Logisch zusammengehörige Daten müssen nicht unbedingt auch physikalisch zusammenhängend gespeichert werden, sondern lassen sich dazu auch in kleinere, getrennte Häppchen aufteilen. Jede Datei bekommt einen Puffer in der gewünschten Blockgröße (meist 32 KByte) zugeteilt. Ist der Block gefüllt, wird er auf Band geschrieben.
Blockgrößen
Das blockweise Schreiben führt jedoch zu einem unangenehmen Nebeneffekt: Das Sichern von Files, deren Gesamt- oder Restlänge unter der Blockgröße liegt, führt zur Speicherplatzverschwendung. Beim Backup vieler kleiner Dateien kann dies drastische Ausmaße annehmen.
Auf Grund dieser Tatsache implementieren einige Hersteller kleinere Blockgrößen bis hinunter zu 32 Byte. Mit diesen kleineren Blöcken lässt sich nicht nur die Bandkapazität effizienter nutzen, sondern auch die Zeit vom Eintreffen der Daten bis zum Schreiben weiter reduzieren: Sie lassen sich aus Datenpaketen in netzwerktypischer Größe schneller füllen als 32-KByte-Portionen.
Vom Standpunkt der Datensicherheit aus betrachtet, erweisen sich sehr kleine Blöcke allerdings als weniger empfehlenswert. Bei physikalischen Beschädigungen des Bandes, etwa durch Knitterung oder Stauchung, geht bei File Interleaving oder der Verwendung großer Blöcke im Regelfall nur eine Datei verloren. Bei Block Interleaving mit sehr kleinen Einheiten liegen mit hoher Wahrscheinlichkeit Daten aus mehreren Files im betroffenen Bandabschnitt.
Backup-Varianten
Im Netzwerkeinsatz unverzichtbar ist die Unterstützung für Bandwechselsysteme, Neudeutsch: Changer, die das manuelle Einlegen des korrekten Bandes vor dem Backup ersparen. Wenn die Applikation neben Tape Libraries auch Jukeboxen unterstützt, besteht die Möglichkeit zum Hierarchical Storage Management (HSM), also dem schrittweisen Auslagern selten genutzter Dateien auf sekundäre Speichersysteme.
RAID-Implementationen auf Tape- oder Optical-Basis steigern Geschwindigkeit und Datensicherheit beim Backup. Neben Striping (RAID 0) und Striping mit Parity über mehrere Bandlaufwerke (RAID 5) lässt sich dabei meist auch Bandspiegelung (RAID 1) nutzen. Neben der Unterstützung für mehrere Bandlaufwerke (RAIT - Redundant Array of Independent Tapes) ist auch eine Verteilung über mehrere Libraries (RAIL) möglich.
Wie auch Tape RAID setzt das Zeit sparende synthetische Backup die Nutzung eines Bandwechslers mit mehreren Laufwerken voraus. Aus dem letzten - echten oder nachvollzogenen - Backup und den seitdem erfolgten Änderungen wird dabei ein künstliches Voll-Backup erstellt. Da bei dieser Technik lediglich Backup-Server und Bandwechsler über ein schnelles SCSI-Interface Daten austauschen, erfolgt die synthetische Vollsicherung sehr schnell und ohne Netzwerkbelastung.
Disaster Recovery
Beim Dreigespann Image Backup / Disaster Recovery / Remote Recovery handelt es sich um eng verwandte Techniken. Als Basis fungiert bei allen drei das Image- Backup, das die gesamte Struktur einer Festplatte inklusive der Partitionen und Zugriffsrechte auf Band abbildet. Als eigene Partition in das Dateisystem eines Servers gemountet, erspart das Tape mit dem Image dem Administrator lästige Arbeit: Zerstört ein Benutzer auf seiner Festplatte eine Datei, kann er sie vom Band selbst wiederherstellen - die Zugriffsrechte hat er ja. Der Administrator bleibt von der Routinearbeit verschont.
Disaster Recovery geht einen Schritt weiter: Es erlaubt das Klonen von Inhalten und das Wiederherstellen der Funktion eines ausgefallenen oder zerstörten Rechners auf gleicher oder zumindest ähnlicher Hardware. Dazu erzeugt es neben dem Image einen bootfähigen Diskettensatz oder eine CD mit einer rudimentären Version des Betriebssystems sowie einer Restore Engine.
Durch das Hochfahren eines Rechners mittels dieser Disketten oder der CD und das anschließend automatisch erfolgende Aufspielen des Images lässt sich ein Duplikat des gesicherten Systems erzeugen. Bei Platten-Crashs oder Totalausfällen von Servern entfällt also der langwierige Zyklus OS-Installation - Einrichtung der Backup-Software - Restore: Die Wiederherstellung erfolgt so schnell, wie die Daten vom Band gelesen werden können.
Darüber hinaus bleiben durch die Image-Technik alle Benutzerkonten, Zugriffsrechte und Konfigurationsoptionen erhalten. Remote Recovery dehnt dieses Verfahren auch auf Backup-Clients ohne eigene Bandlaufwerke aus. Die notwendigen Boot-Daten lagern zentral - ebenfalls als Images - auf dem Server, die Nutzdaten werden über das LAN eingespielt.
Nach dem Backup
Haben Sie Ihre Backup-Anforderungen spezifiziert und anhand des erstellten Anforderungskatalogs eine geeignete Applikation sowie passende Hardware ausgewählt und beschafft, dann steht der Zeit und Arbeit sparenden Datensicherung nichts mehr im Wege.
Tatsächlich verwöhnen aktuelle Datensicherungsapplikationen den Benutzer durch einen hohen Grad an Automatisierung, der auch weniger versierten Anwendern das Aufsetzen gut funktionierender Backup-Lösungen erlaubt. Sich nach dem Backup aber auf der sicheren Seite zu wähnen, wäre ein fataler Irrtum. Die Sicherung der Daten stellt eine Seite der Medaille dar. Der zweite, mindestens genau so wichtige Aspekt wird gerne vernachlässigt: die Datenwiederherstellung.
Die Vorarbeit dazu beginnt schon mit dem sachgemäßen Handling der Bänder. Tapes haben eine genau bemessene Nutzungsdauer, die von 25 bis 100 Durchläufen bei DAT/DDS bis zu mehreren 10.000 Zyklen bei AIT, DLT oder LTO reicht. Nach Erreichen dieser Grenze können die Bänder zwar noch jahrelang ohne Datenverlust gelagert, jedoch nicht ohne Gefahren für die Datensicherung weiter benutzt werden.
Eine gute Backup-Anwendung überwacht daher die Anzahl der Bandnutzungen und warnt den Anwender bei Überschreitung der zulässigen Verwendungsdauer. Steht diese Möglichkeit nicht zur Verfügung, muss die Lebensdauer der Bänder, etwa mit Hilfe einer Liste, manuell überwacht werden.
Tapes richtig lagern
Die Lagerung von Tapes erfolgt im Idealfall aufrecht stehend in der Originalverpackung an einem dunklen, trockenen Ort bei Zimmertemperatur. Dies reduziert die Gefahr des Verschmutzens, Verklebens und Korrodierens.
Als optimaler Aufbewahrungsort für die Bänder, aber auch andere Datenträger, empfiehlt sich ein als Datenschutzschrank zertifizierter Safe. Zu den Zulassungstests solcher Behältnisse gehören mehrstündige Erhitzung auf über 1000 Grad und ein anschließender Absturz über Geschosshöhe, ohne dass Temperatur und Feuchtigkeit im Inneren eng definierte Werte übersteigen dürfen.
Die Anschaffung solcher - zugegeben nicht billiger - Datensafes wird häufig auf Grund der Milchmädchenrechnung abgelehnt, dass, wenn die Firma abbrenne, auch kein Backup mehr etwas nutze. Die Wahrscheinlichkeit eines Firmen-GAUs liegt jedoch bei nur einem Prozent, meist werden nur einzelne Geräte oder Räume durch Feuer oder Wasser unbrauchbar. In 99 von 100 Fällen ließen sich die lebenswichtigen Daten also durch ein Disaster Recovery oder simples Restore wiederherstellen - wären die Sicherungsbänder nicht durch Brandgase, Wasser oder Löschmittel zerstört worden.
Zusätzlich zur sachgemäßen Lagerung im eigenen Haus empfiehlt es sich, regelmäßig Kopien der Sicherungsbänder an einen anderen Ort - etwa in den Safe der Hausbank - auszulagern.
Test in der Praxis
Einem geflügelten Wort zufolge überlebt selbst der beste Plan nie den Kontakt mit der Praxis. Deshalb sollten Sie in regelmäßigen Abständen - speziell nach dem Aufsetzen neuer Server oder Netzwerkapplikationen - die Wirksamkeit Ihrer Backup-Lösung in der Praxis überprüfen.
Testen Sie in einer ersten Stufe das Restore einzelner Dateien. Dabei sollte die Wiederherstellung der Files, falls irgend möglich, weder von dem Backup-Server aus erfolgen, auf dem die Sicherung geschrieben wurde, noch von dem ursprünglich eingesetzten Tape-Device. Auf diese Weise stellen Sie zum einen die Funktionalität der Backup-Applikation sowie zum anderen die Kompatibilität und saubere Einstellung der eingesetzten Bandlaufwerke sicher.
Simulieren Sie in einem zweiten Schritt einen Totalausfall der zum Backup eingesetzten Hardware - führen Sie also ein komplettes Disaster Recovery durch. Als Zeitpunkt für eine solche Katastrophenübung eignen sich speziell lange Wochenenden oder Betriebsferien: Zeiten also, in denen der Produktivbetrieb nicht behindert wird.
Typische Fehlerquellen
Mit an Sicherheit grenzender Wahrscheinlichkeit werden Sie dabei einige unliebsame Überraschungen erleben. Typische Beispiele dafür:
Ihre DV-Mitarbeiter oder wichtige Ansprechpartner sind nicht erreichbar - beispielsweise der Kollege mit dem Schlüssel für den Datenschutzschrank.
Die als Ersatz vorgesehene Hardware kann nicht kurzfristig beschafft werden - oder ist zwar im Haus vorhanden, weist aber Funktionsstörungen auf.
Bänder oder Boot-Medien lassen sich auf den zum Disaster Recovery vorgesehenen Laufwerken nicht lesen.
Durch die nicht völlig identische Hardware weisen einzelne Applikationen nach dem Disaster Recovery unvorhersehbare Funktionsstörungen auf.
Überprüfen Sie solche Fehlerquellen systematisch und schaffen Sie entsprechend Abhilfe. Zum Teil genügen dazu interne Organisationsmaßnahmen - etwa die Erstellung einer Alarmierungsliste und eines Notfallplans.
Andere Fehlerquellen erfordern die Absprache mit externen Zulieferern: So sollten Sie etwa mit Ihrem bevorzugten Hardware-Lieferanten absprechen, wie schnell er gegebenenfalls Ersatzgeräte bereitstellen kann.
Fazit
Damit haben Sie das Menschenmögliche getan, um Ihre unternehmenswichtigen Daten mit einem umfassenden Backup-Konzept gegen katastrophale Verluste abzusichern.
Ach ja - ein Tipp noch zum Schluss: Ihr Backup-Konzept sollte auch ohne Ihre Anwesenheit funktionieren. Gemäß Murphys Law kommt der nächste Server-Crash spätestens dann, wenn Sie mit Frau und Kindern in der Abflughalle auf Ihre Maschine nach Korsika warten ... (jlu)