Nicht eine einzelne Technik kann Daten umfassend sichern – nur die richtige Kombination mehrerer Technolgien verspricht Vollschutz.

Niemand ist perfekt – und am allerwenigsten Hardware, die in der Anschaffung möglichst billig sein muss. Daher sterben in deutschen Unternehmen täglich Dutzende von Servern, Clients, und sicher geben zudem mehrere Hundert Festplatten den Geist auf. Während der reine Hardwareschaden ein paar Euro beträgt, könnte der damit verbundene Datenverlust in die Tausende gehen. Um das zu vermeiden, legen die Administratoren Sicherheitskopien an – und an dieser Stelle wird die Sache richtig kompliziert. Mehrere Hundert Unternehmen offerieren Tausende verschiedener Lösungen, mit denen sich der Verlust von Daten ganz oder zumindest teilweise vermeiden läßt. Dahinter stecken entweder reine Soft- und Hardwarelösungen oder gleich Kombinationspakete aus beidem. Ferner tummeln sich Unmengen an Dienstleistern auf dem Markt, welche Sicherheitslösungen vor Ort einrichten, warten oder gleich die kompletten Backupdienste im Auftrag betreiben.

Hinter allen diesen Lösungen stecken aber vergleichsweise wenige unterschiedlichen Technologien zur Datenerhaltung. Diese jedoch unterschieden sich recht stark voneinander und eignen sich jeweils auch nur für einen Teil eines kompletten Sicherungskonzepts. Für den Rundumschutz bedarf es der geeigneten Kombination der verschiedenen Sicherheitsfunktionen. Den richtigen Mix kann nur der Systemverwalter selbst ermitteln, denn er kennt die Daten und Prozesse im Unternehmen und muss daher auch das Regelwerk für Sicherungsprozesse festlegen.

Dieser Artikel beschreibt die Funktionsweise der verschiedenen Sicherungstechnologien, für welchen Einsatz sie sich eignen, und was sie nicht können.

Was wann wohin sichern

Eine umfassende Datensicherung erfolgt typischerweise in drei Stufen. Zuerst geht es darum, die »lebenden« Daten, mit welchen die LAN-Anwender aktuell arbeiten, so verfügbar wie möglich zu halten. Diese Stufe schützt damit nur und ausschließlich vor Plattenschäden, hilft aber nicht bei Benutzerfehlern und kann keine Langzeit-Datensicherung bieten. Die zweite Stufe soll vor Benutzer- und Anwendungsfehlern schützen. So traurig das klingen mag: Laut Statistik sind genau diese Software- und Anwenderfehler die häufigste Ursache für Datenverluste, und nicht etwa die Hardwarefehler. Hier helfen in kurzen Intervallen erstellte Sicherungen über Technologien wie Volume-Snapshots. Die Sicherungsstufe drei kümmert sich dann um die Langzeit-Sicherung und -archivierung wichtiger Daten. Bei großen Unternehmen müssen sich Administratoren darüber hinaus noch Gedanken zum Katastrophenschutz machen. Ein Gebäudebrand, welcher alle Hardware samt Sicherungen und Bändern vernichtet, macht alle einfachen Ansätze zunichte. Nur gespiegelte Daten in einem anderen Gebäude können dann noch helfen. Dank neuer funktionsreicher Datenspeicher in Speichernetzwerken kooperieren die drei Stufen immer enger miteinander, wenn man die Features geschickt kombiniert.

Sicherheit durch Redundanz

Nahezu alle Sicherungstechnologien arbeiten offline. Kommt es zu einem Ausfall, bleibt der entsprechende Server oder die zugehörige Applikation erst einmal stehen oder stürzt ab. Der Verwalter setzt das System anschließend mit den Daten der jüngsten Sicherung wieder in Gang. Dabei bleiben aber alle Daten zwischen der jüngsten Sicherung und dem Zeitpunkt des Absturzes verloren. Hier helfen zwar kurze Sicherungsintervalle weiter, jedoch entstehen dabei zu viele Sicherungsdaten, und auch ein geringer Datenverlust kann fatale Folgen haben, wenn wichtige Informationen verloren gingen.

Gänzlich vor Datenverlust kann daher nur eine aktive Sicherung schützen. Dazu gibt es die bekannten Redundanztechnologien wie Raid 1 oder Raid 5. Das Prinzip ist immer gleich: Raid sichert die Daten gleich bei der Entstehung ab. Raid 1 das klassische Mirroring, nutzt dabei einfach zwei oder gar drei Platten gleicher Kapazität und schreibt die Daten in zwei- bis dreifacher Ausfertigung. Raid 5 verteilt die Daten auf mehrere Platten und errechnet dabei Redundanzinformationen, so dass in einem Array ein einzelnes Laufwerk ausfallen darf, ohne dass Informationen verloren gehen. Raid 1 bietet nach wie vor den besten Schutz, speziell dann, wenn nicht nur den Datenträger, sondern auch den Controller und die Verkabelung zwei Mal vorliegen. Allerdings nutzt der angebundene Server immer nur 50 Prozent der physisch verfügbaren Kapazität, und das macht Raid 1 neben der sichersten leider auch zur teuersten aller Technologien.

Eine Reihe unternehmenskritischer Systeme kommt aber nicht um diesen Schutz herum. Raid 1 setzen Unternehmen häufig auf den Systemlaufwerken ihrer Server ein. Das garantiert nicht nur den verlust- sondern auch den unterbrechungsfreien Betrieb.

Effizienter geht Raid 5 zu Werk. Innerhalb eines Verbundes mehrerer Platten geht nur die Kapazität eines einzelnen Laufwerks für Redundanzinformationen verloren. Je größer also das Array, desto effizienter nutzt es die Gesamtkapazität aus. Zu groß darf der Verwalter die Arrays aber nicht bauen. Fällt im Array mehr als eine Platte aus, sind die Daten futsch. In der Praxis setzen Unternehmen Raid-5-Arrays mit drei bis sieben Platten ein. In der Regel steht diesen Arrays eine Reservelaufwerk zur Seite, das bei einem Ausfall sofort den Platz des defekten Geräts übernimmt. Das allerdings erfordert den gefürchteten Array-Rebuild. Je nach Größe werkelt das Array dabei mehrere Stunden, um die verlorenen Daten aus den übrig gebliebenen zu errechnen und auf den Reserve-Datenträger zu schreiben. Während dieser Zeit arbeitet ein Raid-5-Array sehr langsam und sorgt für viel Aktivität auf allen Laufwerken. Das macht das System sehr anfällig für einen weiteren Laufwerksausfall, der wiederum das Ende aller Daten bedeutet.

An dieser Stelle muss Network Computing wieder einmal darauf hinweisen, welche Arrays ein Rebulit-Prozess ganz besonders gefährdet: In den günstigen ATA-Arrays arbeiten Desktop-Platten, welche die Hersteller durch die Bank nicht für den ununterbrochenen Rund-um-die-Uhr-Betrieb zertifizieren. Dabei spielt es absolut keine Rolle, ob es sich um Parallel- oder Serial-ATA-Laufwerke handelt. Ein Rebuilt mit voluminösen 200- bis 400-GByte-Disks kann länger als 48 Stunden dauern. In dieser Zeit arbeiten alle Array-Laufwerke außerhalb der Herstellerspezifikation, und es darf sich niemand wundern, wenn sich währenddessen ein weiteres Laufwerk verabschiedet und damit das komplette Array vernichtet. In den Real-World Labs haben wir dieses Szenario bereits mehrfach durchgespielt – mit Erfolg, sprich dem Verlust aller Testdaten.

Daher schwenken nun immer mehr Storage-Hersteller auf Raid-Technologien um, die auch den Ausfall mehrere Laufwerke verkraften. Dabei kochen derzeit alle Hersteller noch eigene Süppchen: Hier gibt es »Raid n«, dort »Raid 6« und wieder anderswo »Raid DP«. Als Folge davon stellt aktuell noch kein Hersteller Controller her, die hardwaregestütztes Raid für multiple Plattenausfälle beherrschen. Alle derzeit angebotenen Lösungen setzen passive Controllerchips ein und lassen die CPUs des Storage-Arrays die Redundanzberechnung ausführen.

Raid-Systeme arbeiten, je nach Konfiguration, langsamer als Einzellaufwerke, denn jeder Schreib- und Lesevorgang erfordert die teils aufwändige Paritätsberechnung. Nur Arrays mit Hardwarecontroller, vier oder mehr Laufwerken und einem dicken Schreib-Cache überholen vergleichbare Einzellaufwerke. Raid 6 und vergleichbare Technologien fordern bei Schreiboperationen zwei oder mehr Paritätsberechnungen, was das Ganze gegenüber Raid 5 zunehmend verlangsamt. Und wenn diese Prozedur nicht in einem spezialisierten Asic, sondern per Software erfolgt, muss das Storage-System auf jeden Fall über eine leistungsfähige CPU verfügen.

Distanz-Raid

Raid kann einzelne Laufwerksausfälle eines Arrays ausbügeln. Wenn aber der Controller oder das komplette Array ausfällt, hilft alles lokale Herumspiegeln nichts. Platten lassen sich auch auf größere Distanzen spiegeln, allerdings setzen hier die Bandbreiten der Fernverbindungen klare Grenzen. Plattenspiegelungen unter Raid 1 erfolgen immer synchron. Der eigentliche Schreibvorgang endet erst dann, wenn beide Kopien erfolgreich auf der jeweiligen Platte liegen. Spiegelt man Laufwerke synchron über eine kilometerlange Verbindung, sinkt die Schreibperformance des Raid-1-Verbandes ins Bodenlose. Die Signallaufzeiten plus Latenzen aktiver Bridges oder Storage-Router verzögern die Zugriffe auf das weit entfernte Laufwerk. Für Fernspiegelung setzt man daher auf asynchrone Replikationsmechanismen. Der aktive Zugriff erfolgt stets auf das nahe und damit schnelle Laufwerk. Die Replikationssoftware im Server oder dem Storage-Subsystem puffert auf Blockebene die Änderungen am Laufwerk und übermittelt diese an das entfernte Speichersystem. Das erlaubt ferner, dass Original und Spiegel nicht zwangsweise auf identischer Hardware liegen. Ein physisches FC-Laufwerk oder besser ein Raid-1-Verband kann als Primärlaufwerk dienen, während der asynchrone Mirror lediglich auf einem logischen Laufwerk innerhalb eines ATA-Arrays lagert. Alle Hersteller professioneller SAN-Speicher liefern zumindest als Option asynchrones Mirroring. Dabei dürfen verschiedenste Verbindungstechnologien wie FC, FCIP, iFCP, rohes IP oder iSCSI zum Einsatz kommen. Darüber hinaus implementieren verschiedene Hersteller proprietäre Protokolle. Zudem gibt es eine Reihe reiner Softwarelösungen für Windows-, Unix oder Linux-Server, welche Daten asynchron über eine LAN-Verbindung spiegeln. Asynchrone Mirrors sichern die Daten auf Grund der Zeitverzögerung nicht absolut zuverlässig, aber wesentlich besser geht es über Weiterverbindungen auch nicht.

Zwar sind Spiegel auf Blockebene so nahe am Original, wie es die Verbindungsgeschwindigkeit zulässt, doch laufen dabei auch Unmengen unnützer Daten über die Weitverbindung. Der eigentliche Spiegelungsvorgang kann auf Blockebene nicht zwischen nutzlosen temporären Daten und wichtigen Informationen unterscheiden. Alternativ lassen sich Daten auf Dateisystem- oder Applikationseben replizieren. Dafür stehen verschiedene Softwaretools zur Verfügung. Hier kann der Administrator dann genau selektieren, was übertragen wird und was nicht. In diesem Fall läuft die Replikation auf Wunsch in beide Richtungen. So werden Änderungen am entfernten Dateisystem auch auf das lokale Laufwerk übernommen. Replikationsmechanismen finden sich in Applikationen, die ihre eigenen Datenspeicher verwalten, wie Datenbanken, Groupware-, ERP- oder Mailsystemen. Dank der selektiven Replikation reicht oft eine Verbindung mit geringer Bandbreite aus.

Replikationsmechanismen und asynchrone Spiegel schützen den Kerndatenbestand oder die Informationen spezieller Applikationen vor Datenverlusten durch totale Systemausfälle auf einer Seite der Fernverbindung. Aber auch dieser Sicherungsmechanismus deckt keine Applikations- oder Anwenderfehler ab. Löscht jemand versehentlich wichtige Informationen, dauert es in der Regel nur wenige Sekunden oder Minuten, bis diese Daten auch auf der fernen Seite des Links verschwinden.

Von Datenschatten und Generationen

Um versehentlich gelöschte Daten nicht zu verlieren, generieren Applikationen, systemnahe Tools oder das Dateisystem selbst Schattenkopien. Diese Schatten enthalten frühere Versionen eines Dateisystems oder Datenspeichers und erlauben dem Verwalter bei Fehlern, Aktionen rückgängig zu machen. Hierarchische Dateisysteme, wie man sie in der Unix-Welt oft antrifft, übernehmen diesen Dienst automatisch. Der Administrator legt dabei für ein Dateisystem oder einen Teil davon eine Generationstiefe fest. Ändert ein Benutzer oder eine Anwendung eine Datei, behält das Dateisystem eine Kopie der ursprünglichen Version. Mit jeder Änderung legt das System eine weitere Kopie an. Die jeweils älteste Kopie geht verloren, sollte das Dateisystem die Generationstiefe erreichen. Der Systemverwalter kann im Dateisystem selektiv auf die verschiedenen Versionen zugreifen und eine neuere fehlerhafte durch eine frühere ersetzen.

Obwohl hierarchische Dateisysteme ereignisgesteuert Generationen erzeugen und damit sehr einfach zu verwalten sind, lassen sie sich nur für verhältnismäßig wenige praktische Anwendungen einsetzen. Moderne Applikationen arbeiten oft mit sehr großen Dateien, auf die laufend mehrere Tasks zugreifen. Daher ändern sich diese Dateien mehrmals in einer Sekunde und erreichen im Handumdrehen die Generationstiefe. Andere Programme wie allseits beliebte Office-Programme ändern das eigentliche Dokument auf dem Dateisystem nicht erst dann, wenn der Anwender auf »Speichern« klickt. Vielmehr fummeln diese Programme ebenfalls laufend an den Dateien herum und erzeugen somit viele Generationen pro Sekunde.

Daher etablieren sich zeitgesteuerte Abbilder oder so genannte Snapshots. Zum Zeitpunkt eines Snapshots merkt sich das Dateisystem den aktuellen Zustand. Neue Informationen schreibt das System dann natürlich direkt in das Dateisystem, sichert dazu aber getrennt die Änderungen zur vorherigen Version. Der eigentliche Snapshot benötigt im Moment seiner Entstehung keinen Speicherplatz und auch nur sehr wenig Zeit. Je mehr sich am Dateisystem ändert, desto größer werden die Änderungsdaten. Snapshots leben daher nie sonderlich lange, da sie sonst irgendwann mehr Platz als die operativen Daten belegen. Ein erneuter Snapshot friert hingegen den vorhergehenden ein. So kann der Administrator mit einer Zeitsteuerung stets eine gewisse Zahl an Schatten vorhalten und damit zumindest über einen Zeitraum Fehler korrigieren.

Intelligente Speichersysteme integrieren Snapshot-Funktionen direkt im Storage-Subsystem, so dass der angeschlossene Server davon eigentlich nichts mitbekommt. Aus den Live-Daten und den Änderungsinformationen kann ein Speichersystem dann ein komplettes virtuelles Laufwerk erzeugen, das dem Original zum Zeitpunkt des Snapshots entspricht. Der Administrator darf dieses Laufwerk dynamisch auf einem anderen Server einbinden und dort selektiv Daten extahieren oder das komplette Laufwerk auf ein anderes Medium wie Tape sichern.

Allerdings geht das alles nicht ganz so einfach, wie es manche Storage-Hersteller den Anwender glauben lassen. Der Snapshot enthält exakt die Daten, die bei seiner Entstehung auf dem Quell-Laufwerk lagen. Das berücksichtigt natürlich nicht diejenigen Informationen, die das Dateisystem oder eine Anwendung zu diesem Zeitpunkt in irgendwelchen Caches aufbewahrt. So kann ein Snapshot fehlerhafte und unvollständige Dateien enthalten – diese Dateien nämlich, welche zum Snap-Zeitpunkt zum Schreiben geöffnet waren. Also muss sich das Speichersystem auf jeden Fall mit dem zuständigen Betriebssystem und den Applikationen vor dem Snapshot absprechen. Der Ablauf sollte daher folgendermaßen aussehen: Die Applikationen leeren ihre Caches, schreiben alle offenen Daten auf Platte und stellen vorübergehend alle Schreiboperationen auf ihren Datenspeicher ein. Dann entleert das Dateisystem seinen Cache und gibt dem Speichersystem Bescheid, dass es jetzt den Snapshot generieren darf. Abschließend meldet das Speichersystem sich beim System und der Applikation zurück und gibt die Caches wieder frei. Hersteller von Speichersystemen müssen zum reinen SAN-Array die nötigen Tools und Agenten mitliefern, welche die Kommunikation zwischen Storage, Applikation und Betriebssystem abwickeln. Skripte auf dem Speichersystem oder dem Host stoßen dann zu vorgegebenen Zeiten alle nötigen Aktionen an. Windows-Server kennen leider kein »Sync«-Kommando, das bei Unix/Linux-Servern sofort die Caches des Dateisystems leert und auf Platte schreibt. In der Windows-Welt müssen daher externe Tools diesen Dienst erledigen.

Als zeitgesteuerte Abbilder lassen sich Snapshots eigentlich nicht mehr verändern. Damit haben Unix-Systeme auch kein Problem, denn sie können jedes Dateisystem in einem Read-Only-Modus einbinden. Windows ist dazu mit seinem NTFS-Dateisystem leider nicht fähig. Daher muss beim Einsatz von Windows-Servern das Speichersystem in der Lage sein, einen schreibbaren Snapshot zu generieren. Die nachträglichen Änderungen sollten aber nicht direkt auf den Snapshot gehen, da dieser im Urzustand verbleibt. Vielmehr stellt ein Speichersystem hierzu einen getrennten Cache zur Verfügung, den es löscht, wenn der Windows-Server den Snapshot wieder freigibt.

Windows selbst verfügt ab der Serverversion 2003 über einen einfachen eingebauten Snapshot-Service. Damit das System sich selbst überlisten kann, stellt es die Snapshot-Informationen aber nicht als komplettes Laufwerk dar. Vielmehr sichert das Microsoft-System Snapshot-Informationen nur innerhalb einer Dateifreigabe. Über das SMB-Protokoll können Clients oder andere Server dann auf frühere Versionen eines Shares zugreifen, da Windows durchaus dazu in der Lage ist, mit schreibgeschützten SMB/CIFS-Freigaben zu arbeiten. Diese Implementation erlaubt dabei den Benutzern selbst und ohne Hilfe des Administrators, auf frühere Versionen ihrer Dateien zuzugreifen – wenn diese Anwender genau wissen, was sie tun, ist das eine gute Sache.

Tools von Drittanbietern verwenden den internen Snapshot-Service von Windows-2003-Servern und erstellen damit komplette Plattenabbilder für Disaster-Recovery-Dienste.

Snapshots schützen vor Datenverlusten durch Benutzer- oder Anwendungsfehler, haben aber nur eine begrenze Lebensdauer. Allein dienen sie daher nicht für die Langzeit-Datensicherung. Immer häufiger treten Snapshots aber als Quelle für weiterführende Backup-Operationen auf.

Langzeitschutz in mehreren Stufen

Nach wie vor schützt ein Großteil der Unternehmen die Datenbestände nur durch simple Tape-Backups. Dabei folgen sie einem einfachen Rotationsschema: Am Wochenende gehen alle aktuellen Daten aufs Band. Jeden Abend nach Büroschluss holt sich das Backup-Programm die täglichen Änderungen und fügt sie dem jeweiligen Bandsatz hinzu. Das Ganze findet mit zwei bis fünf Bandsätzen statt, fertig. Diese klassische Bandrotation genügt heutigen Ansprüchen und Gesetzesvorschriften nicht mehr. Zum einen berücksichtigt dieses Verfahren Datenänderungen während des Tages nicht. Es trennt temporäre Daten nicht von relevanten, die nach geltenden Gesetzen dauerhaft und unveränderbar über einen mehrjährigen Zeitraum gesichert werden müssen. Immer wieder transferiert diese Prozedur Daten auf Band, die sich über einen längen Zeitraum überhaupt nicht verändert haben und zieht damit Backup-Abläufe unnötig in die Länge.

Genau hier sollen Disk-to-Disk-Backups Abhilfe schaffen. Auf Grund der größeren Geschwindigkeit von Disk-Arrays laufen Backup-Aufträge einfach schneller ab. In einem weiteren Schritt sichern die Backup-Programme zu einem geeigneten Zeitpunkt oder über eine dezidierte Maschine die Disk-Sicherungen auf Band. Doch hier machen sich die Hersteller von Backup-Software die Sache oft zu einfach. Sie verwalten Disk-Backup-Targets als stumpfe virtuelle Tapes, die sie später eins zu eins auf Band herausschreiben. Dabei trennen die Applikationen wiederum nicht die Spreu, sprich temporäre und nur kurzfristig zu lagernde Daten nicht vom Weizen, also den Daten, die über einen längeren Zeitraum archiviert werden müssen. Backups auf Disk-Arrays bieten jedoch einen entscheidenden Vorteil: Neben der puren Geschwindigkeit können Sie unnütze Dateien aus dem Backup-Pool entfernen oder wichtige auf ein anderes Medium verschieben. Ein Tape-Laufwerk kann das ebenso wenig wie ein virtual-Tape-Server.

Sinnvoll sind daher nur Backup-Applikationen, die Disk-to-Disk-Backups anders verwalten als Disk-to-Tape-Sicherungen. Moderne Sicherungsprogramme legen mit jeder Sicherung einen exakten Katalog der Dateien an, die sich zum Zeitpunkt der Sicherung tatsächlich auf den Quellen befanden. Der Administrator kann daher mit den geeigneten Tools später die gelöschten Daten auch aus früheren Sicherungen entfernen. Damit wachsen Disk-Storage-Pools nicht ins Uferlose, sondern belegen eine überschaubare Kapazität. Zudem kann der Administrator aus diesen Backup-Pools die relevanten Daten herausfischen und diese dann explizit auf Tape auslagern.

In der Praxis sollte das bei den Unternehmen dann so aussehen. Eine Disk-to-Disk-Backup-Prozedur sichert in kurzen Intervallen die kompletten operativen Datenbestände in einen Disk-Pool – der dann auch aus ATA-Laufwerken bestehen darf. Über einen überschaubaren Zeitraum von mehreren Wochen oder Monaten behält dieser Backup-Pool alle Informationen. Danach entscheidet der Verwalter, welche alten Sicherungsdaten gelöscht und welche zur Langzeit-Archivierung auf Band oder einen anderen dauerhaften Datenträger verschoben gehören. Der Disk-Backup-Pool sichert somit die kurzfristigen Daten, Daten auf externen Datenträgern sorgen für die Langzeitarchivierung.

Immer wichtiger werden in diesem Zusammenhang so genannte Sicherungs-Policies. Dabei handelt es sich schlicht um ein an die Unternehmensdaten angepasstes Regelwerk, das die Spreu vom Weizen trennt.

Spreu von Weizen trennen

Wenn irgendein Speicherhersteller heute von »Lifecycle Management« spricht, geht es genau darum, nach definierten Regelwerken zu entscheiden, was gelöscht und was längerfristig archiviert gehört. Einen Out-of-the-Box-Automatismus gibt es dabei nicht. Es bestehen keine globalen, für alle Unternehmen gültigen Regelwerke. Wer LM nutzen möchte, muss sich selbst hinsetzen, das Datenaufkommen, die geltenden gesetzlichen Vorschriften und die Arbeitsprozesse des Unternehmens analysieren und exakt darauf abgestimmte Regelwerke für die Datensicherung erstellen. Dies lässt sich dann mit einer ausgeglichenen Kombination aus den hier vorgestellten Technologien umsetzen.

Doch bei allen tollen Sicherungstechnologien darf man eins nicht übersehen: Den Anwender, welcher die Daten erstellt. Und genau hier herrscht trotz aller moderner Methoden der größte Mangel. Nur wenige Anwendungen und Anwender qualifizieren und dokumentieren ihre Datenbestände bei der Erstellung ausreichend, so dass ein Regelwerk später über Leben oder Tod einzelner Files entscheiden kann. Das beste Beispiel bietet der Alltag. Wie oft finden Mitarbeiter in ihren chaotischen und vernetzten Dateisystemen Dokumente plötzlich nicht mehr, die sie nur wenige Tage zuvor erstellt hatten. War die Präsentation jetzt auf »C:zeug« auf dem Notebook, oder hatte ich das auf »F:Glump« auf dem Fileserver gesichert, und wie hieß diese Datei überhaupt?

Wenn es schon hier an der nötigen Ordnung fehlt, darf man nicht davon ausgehen, dass die Anwender ihre Dateien auch noch mit Hinweisen versehen wie: »Präsentation zum Thema A, gehört zum Projekt B für Kunden C, Auftrag D, weitere Daten in Verzeichnis F:projektekunde cprojekt B – aktueller Staus: Korrektur durch Gruppenleiter, mindestens aktuell bis 1.11.05, danach laut GDPDU für 10 Jahre in nicht mehr änderbarem Format archivieren«.

Würden heute alle Daten mit solch ausführlichen Informationen generiert, müsste man keine teuren LM-Services oder Geräte anschaffen und durch kostenspielige Supportverträge warten lassen.

Daher der dringende Hinweis, auch wenn das an dieser Stelle vielleicht schulmeisterhaft klingt: Wer Daten bereits bei der Entstehung ausreichend qualifiziert, kann später mächtig Geld, Zeit und Hardware für die Sicherung und Archivierung einsparen. Doch das fordert ein Umdenken bei Anwendern, Applikationsherstellern und Administratoren und lässt sich nicht einfach durch Zukauf teurerer Hardware, Software oder Services erschlagen. Gängige Document-Management-Systeme können hier gute Dienste leisten. Zum einen arbeiten viele davon sehr eng mit Storage-Systemen und Sicherungsprogrammen zusammen und vereinfachen die Regelwerke erheblich. Zum anderen zwingen die Systeme den datenerstellenden Anweder zur Dokumentation – sie akzeptieren schlicht und einfach keine neuen Datensätze, wenn der Benutzer sie nicht gleich bei der Erstellung angemessen qualifiziert.

Die Kombination macht´s

Die richtige Sicherungsstrategie bezieht alle hier aufgeführten Technologien in der richtigen Kombination ein: Betriebssysteme und Schlüsselapplikationen gehören auf eigene Raid-1-gespiegelte und nicht zu groß dimensionierte Datenträger. Die Sicherung dieser Laufwerke sollte eine Volume-Shadow-Techologie erledigen, die mehrere Generationen der Laufwerke in einem Disaster-Recovery-fähigen Format auf nahen Disk-Backup-Pools sichert. Dieser Backup-Pool gehört dann auch über Replikation in einen entfernten Datenspeicher gesichert. Dazu muss es ein Bare-Meta-Restore-Tool geben, das bei einem Totalausfall des zugehörigen Rechners eine start- und lauffähige Instanz des Systems auf einem Reserve-Rechner generiert. Eine Langzeitarchivierung dieser Daten ist nicht nötig. Die operativen Daten der jeweiligen Applikation lagern dann auf einem vom System getrennten voluminöseren Laufwerk, bevorzugt FC- oder SCSI-Arrays mit Raid-5-Spiegelung. Von diesen Laufwerken fertigt ein Snapshot-Tool, in Absprache mit der Applikation, in kurzen Intervallen Schattenkopien. Vom Original oder den jeweils jüngstem Schatten sollte eine Replikation zu einem entfernten Speichersystem erfolgen. Die jeweils älteste Schattenkopie lagert ein Sicherungsserver in einen Disk-to-Disk-Backup-Pool ein und löscht danach den Schatten. Dieser Backup-Pool hält die Sicherungsdaten über mehrere Wochen auf dem Disk-Pool vor. Hier dürfen dann auch ATA-Laufwerke zum Einsatz kommen. Aus diesem Sicherungspool entfernt das Policy-Regelwerk die löschbaren Daten und lagert die zu archivierenden Daten auf Tape, Worm, oder Worm-Tape aus, je nachdem, nach welchen gesetzlichen Vorschriften das Unternehmen seine Daten speichern muss.

Der gesamte Ablauf kann und wird in der Praxis mit unterschiedlichen Tools verschiedener Hersteller erfolgen. Vor allem für die Sicherung des Systems selbst wird man ganz andere Programme verwenden als für die Archivierung der eigentlichen Applikationsdaten. Auch die Replikationsprogramme für die Fernkopien müssen nichts mit dem Snapshot- oder Backup-Utility zu tun haben.

Der Schlüsselfaktor bleibt bei allen Technologien: Das Unternehmen muss seine Daten und Arbeitsabläufe ausführlich analysieren und dementsprechend entscheiden, wie die Sicherungsstrategie und die darin involvierten Hard- und Softwaretools auszusehen haben. [ ast ]