Herzlich Willkommen

Datenwachstum und virtuelle Maschinen haben ein Storage-Segment extrem belebt – das Backup und selbstredend auch die Umkehrung der Datensicherung, also die Wiederherstellung der Daten von Disk oder Tape.

Für Neulinge in der Terminologie von Backup & Recovery haben wir die diversen Teilprozesse möglichst präzise erläutert, die Profis werden sicherlich in den Beschreibungen viele Details finden, die ihnen neue Sichtweisen eröffnen.


Ich bin mir sicher, dass wir noch viele Begriffe in unserem Lexikon „Backup & Recovery virtueller und physischer Maschinen“ ergänzen müssen. Schreiben Sie an Rainer Graefen wenn Sie selber gerne einen Begriff erklären wollen oder wenn Sie einen vermissen.

Ihr Rainer Graefen
Chefredakteur Storage-Insider.de
 

Diese Begriffe von "Abhängigkeiten" bis "Backup-Server" sollten Sie kennen.



Abhängigkeiten: der Ausfall eines Dienstes, wie zum Beispiel Enterprise Resource Planning (ERP), führt zum Produktionsausfall. Auf der Recovery-Liste steht das ERP-System also ganz oben, der oder die Fileserver sind nachrangig, so die häufig verkürzte Sichtweise.
Die schnelle Wiederinbetriebnahme der zentralen Produktionssystems nützt allerdings wenig, wenn beim Disaster Recovery des ERP-Systems vergessen wurde, die Rechner mit dem Anmeldeprogramm und den Anmeldeprofilen ebenfalls zu restaurieren.
Sollte die ERP-Zugangsberechtigung gesondert auf einem Fileserver liegen, dann gehört zur Wiederaufnahme der Produktion auch ein Backup-Job, der die unternehmenskritischen Anwendungen für die Zugangsdaten ebenfalls wiederherstellt. Dieses Beispiel soll nur illustrieren, dass das Recovery eines gesamten Workflows durchdacht werden muss.


Agent: Er übernimmt die Kommunikation zwischen der Backup-Software und einem Anwendungsserver respektive einer Anwendungs-Software. Leider besitzt nicht jede Backup-Software Agenten für alle im Unternehmen eingesetzten Betriebssysteme und Anwendungen wie Datenbanken, Mail-Software, Sharepoint, PACs oder anderes, die dazu noch auf virtuellen Maschinen und physischen Servern laufen.
Die Folge: Mehrere Backup-Produkte mit jeweils spezifischen Backup-Agenten, Snapshot-Schnittstellentreibern und Scripten sind im Einsatz. Der größte gemeinsame Nenner ist zu finden, selbst wenn dies Performance-Verluste nach sich zieht, damit das Management einer hoch spezialisierten Umgebung nicht zu einem Single Point of Failure wird.


Ausfallzeiten minimieren: Es geht bei diesem Punkt um die ununterbrochene Verfügbarkeit des Datenzugriffs. Das betrifft zwangsläufig die Verfügbarkeit von Anwendungsservern wie auch der gesamten Netzwerk-Infrastruktur.
Auf der Speicherebene geht es darum, den Ausfall einer Speicherkomponente von der Festplatte bis zum kompletten Speichersystem verschmerzen zu können. Um den permanenten Datenzugriff sicherzustellen, ist eine dementsprechende Redundanz aller Speicherkomponenten notwendig.
(siehe auch: synchroner Spiegel, asynchroner Spiegel, RAID)


Asynchrone Replikation, asynchroner Spiegel: Würden Daten über typischerweise mehr als 100 Kilometer „gespiegelt“, dann würden sich auf Grund der Laufzeitverzögerung auf der WAN-Strecke die aktuellen Sendedaten mit der Empfangsbestätigung für die vorangegangene Sendungen überschneiden. Ist das der Fall, muss man zur asynchronen Spiegelung wechseln. Dort wird mit größeren Datenpuffern gearbeitet.
Ein Vorteil: Die Übertragungsstrecke kann weltweit angelegt sein.
Ein Nachteil: Die nicht bestätigten Sendedaten können verloren gehen.
In manchen Fällen wählt man deshalb eine Kombination der beiden Verfahren, bei der zuerst die Daten über eine kürzere Distanz synchron gespiegelt werden, womit sie hochverfügbar sind. Anschließend werden diese dann noch asynchron in eine weit entfernte Lokation kopiert, sodass die Daten vor (fast) jeder Katastrophe geschützt aufbewahrt sind.
Da sich bei Einsatz eines asynchronen Spiegels die zeitlichen Abstände einer Übertragung steuern lassen, kann diese Technik verwendet werden, um die sofortige Verbreitung logischer Fehler durch Viren, Updates oder Programmierfehler zu verhindern.
Vorsicht: Bei der asynchronen Replikation muss die Backup-Software mit dem Speichersystem „reden“ können, da die produktive LUN in einen konsistenten Snapshot kopiert werden muss. (siehe auch VSS)


Aufbewahrung von Daten, Archivierung, Retention Time, gesetzliche Vorschriften, Migration von Medien: Steuerrechtliche Vorschriften sehen einen Aufbewahrungszeitraum von zehn Jahren vor. Die gesetzliche Rentenversicherung dehnt diesen Zeitraum auf über 100 Jahre aus. Lange Aufbewahrungszeiträume gelten wegen der Produkthaftung auch für produzierende Hersteller. Die Zeiträume für eine Archivierung ergeben sich in vielen Fällen aus dem jeweiligen Gewerbe.
Grundsätzlich ist es wichtig, sich klarzumachen, dass eigentlich jedes Dokument mit einem Verfallsdatum versehen sein sollte. Da Archivtechnik wie auch die Medien technisch veralten, ist eine Migration von Archivdaten nach drei bis maximal zehn Jahren unumgänglich.
Die Cloud könnte hier für den Anwender neue Möglichkeiten schaffen. Erste Anbieter propagieren, dass sie fähig sind, die Dokumente von der Anwendung und der Hardware getrennt speichern zu können.


Auditing: Beim Auditing wird in einem Extra-File (anders als beim Reporting) jede Aktivität des Backup-Prozesses aufgezeichnet. Hier lässt sich auch nach dem Überschreiben von Medien später noch eruieren, ob die Daten tatsächlich geschrieben wurden.


B2D, Backup to Disk (B2D), Backup to Disk to Tape (B2D2T): Die Disk als Zwischenstufe (Stage) beim Backup auf das Tape löst das Problem des ansonsten erforderlichen kontinuierlichen Datenstroms (streaming). Der Backup-Operator muss allerdings ein Konzept erarbeiten, wie viele Backups er auf die Festplatte zulässt und wann er die Daten von der Disk auf das Tape verlagert. Und nicht zuletzt wann die Daten wieder aus der gesetzlichen Aufbewahrungsfrist herauslaufen und mit dem Löschen auch wieder Medien frei werden.


Backup&Recovery: In vielen Unternehmen sind LAN und SAN und spätestens mit dem Internet-Anschluss auch WAN-Verbindungen installiert. Für den Backup-Administrator stellt sich die grundlegende Frage, über welches Netzwerk er die Daten sichern und über welches er die Daten wiederherstellen soll. Eine Vielzahl von Optionen wie Bandbreite (1/10/100 und 4/8/16 GBit/s), Protokolle (iSCSI, FC, IP, FCIP, FCoE, DSL) sowie unterschiedlichste Latenz- oder Roundtrip-Zeiten werfen viele Fragen auf. Backup&Recovery ist daher mehr als nur der Einsatz von Tape und Backup-Software. Es gilt, die optimalen Bedingungen zwischen geringem Datenverlust, kurzen Ausfallzeiten und Kosten zu finden.


Backup-Lösung: Man kann natürlich lange über vMotion, vStorage, Fehlertoleranz, Cluster-Failover und Replikation reden und damit die Anwendungen und Daten hochverfügbar machen. Letztlich überwiegen allerdings logische Fehler die Ausfallrate von Hardware. Es würde sich, auch aus Kostengründen, empfehlen, zuerst einmal anhand der Anforderungen an das Backup&Recovery zu überlegen, wie viel Datenverlust und Ausfallzeit hinnehmbar sind, bevor man in einen transparenten Storage-Failover investiert.


Backup-Server: Nehmen Sie keine veraltete Hardware für Ihre Backup-Services. Ein 64-Bit-Betriebssystem versteht sich heute von selbst, da sehr viel Rechenpower erforderlich ist, um den Datentransfer zu einem lokal angeschlossenen Streamer abzuwickeln.
Weitere erhebliche Performance-Gewinne sind zu erwarten, wenn die Backup-Software auf dem Backup-Server Dateisysteme browsen muss und dort nur die zuletzt geänderten Dateien herausfinden soll. Nur ein 64-Bit-Betriebssystem hat die Möglichkeit hier mehr als sechs Gigabyte Hauptspeicher einzusetzen und diese aufwändige Rechenarbeit im Hauptspeicher auszuführen.
Tipp: Der Backup-Server sollte in herausfordernden Umgebungen bis zu 12 Gigabyte RAM besitzen. Wünschenswert wäre auch, dass jedes Tape-Laufwerk mit einem eigenen Prozessor-Core arbeitet.