Das praxisnahe Lexikon

  Agent: Er übernimmt die Kommunikation zwischen Backup-Software und Anwendungsserver respektive Anwendungs-Software. Leider beherrscht nicht jeder Backup-Software alle im Unternehmen eingesetzten Anwendungen wie Datenbanken, PACs, VSS, Snapshots für diverse Anwendungen auf virtuellen und physischen Servern. Die Folge: Mehrere/viele Backup-Produkte mit jeweils spezifischen Backup-Agenten und Scripten sind im Einsatz. Das Management dieser hoch spezialisierten Umgebung sollte darüber nicht zu einem Single Point of Failure werden.

Ausfallzeiten minimieren: es geht bei diesem Punkt um die ununterbrochene Verfügbarkeit des Datenzugriffs. Das betrifft zwangsläufig die Verfügbarkeit von Anwendungsserver und Netzwerk. 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)

Archivierung, gesetzliche Vorschriften, Migration nach zehn Jahren:

Asynchrone Replikation, asynchroner Spiegel: Würden Daten über typischerweise mehr als 100 Kilometer „gespiegelt“, dann würden sich Sendedaten und die Empfangsbestätigungen für die vorangegangenen Sendungen überschneiden. Bei der asynchronen Spiegelung arbeitet man deshalb mit größeren Datenpuffern. 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 synchron gespiegelt, damit hochverfügbar sind, und diese dann noch asynchron in eine weit entfernte Lokation kopiert werden, so dass die Daten vor (fast) jeder Katastrophe geschützt aufbewahrt werden. Da sich mit einem asynchronen Spiegel 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)

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 lost das Problem des ansonsten erforderlichen kontinuierlichen Datenstroms. 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 auch 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 Roundtripzeiten werfen viele Fragen auf. Backup&Recovery ist daher mehr als der Einsatz von Tape und Backup-Software, es gilt die optimalen Bedingungen zwischen geringem Datenverlust, kurzen Ausfallzeiten und Kosten zu finden.

Band, Bandlaufwerk, Tape, Tape-Streamer: Es gibt keine IT-Komponente, die die Gemüter professioneller Anwender mehr bewegt. Doch zur Ehrenrettung der Tape-Technik sei es auch an dieser Stelle gesagt: Es gibt kein schnelleres Speichermedium.
Das ewige Ärgernis vieler Backup-Anwender mit der Tape-Technik: Man hält sie für zu langsam. Einem modernen LTO-5-Bandlaufwerk kann man bis zu 450 MByte Daten pro Sekunde anbieten. Wenn also nicht entsprechend schnell ausreichende Datenmengen geliefert werden, dann wird der Streamer in den Start-Stop-Betrieb gezwungen, sarkastisch auch mit „shoeshining“ bezeichnet, der Laufwerk wie Medium extrem belastet. Das Tape spielt bei der Datensicherung von Fileserver nicht mehr die große Rolle früherer Zeiten, aber bei Datenbanken und auch der Archivierung großer Datenmengen, gibt es bislang keine wirtschaftliche Alternative. Eine neue Rolle könnte dem Tape ausgerechnet durch die Cloud zuwachsen: Als Transportmittel. Wer den Anbieter wechseln oder ein Disaster Recovery durchführen muss, der wird größere Datenmengen nicht über eine WAN-Strecke schicken wollen.

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 an Hand der Anforderungen an das Backup&Restore 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 von selbst, da der Datentransfer zu einem lokal angeschlossenen Streamer enorm ist. Weitere erhebliche Performance-Gewinne sind zu erwarten, wenn die Backup-Software auf dem Backup-Server Dateisysteme browsen muss und dann nur die geänderten Dateien herausfinden soll. Nur ein 64-Bit-Betriebssystem hat die Möglichkeit hier mehr als sechs Gigabyte Hauptspeicher einzusetzen. Der Backup-Server sollte in herausfordernden Umgebungen bis zu 12 Gigabyte RAM besitzen. Zu beachten ist auch, dass jedes Tape-Laufwerk mit einem eigenen Prozessor-Core arbeitet.   

Backup-Service in einem Cluster betreiben: Da bei diesem Konzept  das Betriebssystem und die Backup-Applikation doppelt auf zwei physischen Servern vorhanden sind und die Daten geshart auf einem redundanten Speicher liegen, ist die Verfügbarkeit des Services deutlich höher als auf einem Einzelsystem oder in einer virtualisierten Umgebung.

Backup-Service virtualisieren: Keine gute Idee aus zwei Gründen. Erstens: Schreibt die Backup-Applikation in einer VM ihre Backup-Daten in ein SAN, dann darf das SAN niemals ausfallen. Zweitens: Die Backup-Applikation schreibt die Metadaten jeder Datensicherung in eine Datenbank. Liegt diese Datenbank auf demselben Array wo auch die zu sichernden Daten liegen, dann wird eine massive I/O-Last beim Lesen der Daten, beim Schreiben des Backups und nicht zuletzt beim Schreiben der Metadaten in die Datenbank erzeugt.

Betriebssystem/Anwendungen: Nicht immer lohnt es sich in die Ferne zu schweifen. Schon Betriebssysteme wie Anwendungen selbst bieten viele Optionen, um Daten wiederherstellen zu können. Datenbank-Anwendungen bieten ab und zu die Option zwei Kopien anzulegen. Das ist aus sicht der Anwendung proaktiver Schutz gegen Datenverlust. Microsoft bietet mit VSS einen Snapshot-Service für Fileserver, Datenbanken und Hyper-V. Teilweise kann der Anwender selbst mit der rechten Maustaste seine gelöschten Daten wiederherstellen.

Bottleneck, Flaschenhals: Backup&Restore sind technisch sehr herausfordernde Anwendungen. Der Server muss über diverse Stufen wie Agenten, Dateisystem, Netzwerk einen beständigen Datenstrom an das Bandlaufwerk liefern, damit dieses mindestens mit der minimalen Bandgeschwindigkeit fortlaufend Daten auf das Band schreiben kann. Eine Cache im Bandlaufwerk und auch variable Bandgeschwindigkeiten können dafür sorgen, dass Schwankungen in der Datenstromgeschwindigkeit ausgeglichen werden. Ziel muss es sein, alle Engpässe auf dem Weg zum Bandlaufwerk zu beseitigen. Ein 1 GBit-Netzwerk, das pro Sekunde im besten Fall 125 MByte transportiert, wird für einige moderne LTO-Laufwerke zum Engpass und führt dadurch um schnelleren Verschleiß des Gerätes.     

CBT, Change Block Tracking: Während die Datensicherungsmethoden Voll, Differentiell und Inkrementell dem Backup-Server Informationen geben, welche Dateien zu sichern sind, ist das im SAN anders. Hier werden klassischerweise Blöcke ausgetauscht, die eigentlich keine Kennzeichnung über ihren Änderungsstatus besitzen. Im SAN konnte deshalb bislang nur eine Vollsicherung durchgeführt werden. Mit dem CBT bekommen virtuelle Maschinen die Möglichkeit in einem Inhaltsverzeichnis aufzuzeichnen welche Blöcke an den Backup-Sever gesendet wurden. Beim nächsten Mal müssen dann nur noch die geänderten Blöcke übertragen werden. Damit kann man auch im SAN die klassischen Datensicherungsmethoden umsetzen. Wendet man CBT für Datenbanken in einem VMFS-Umfeld an, lassen sich auch größere Volumes mit vMotion leicht auf ein zweites Speichersystem umziehen.

CDP, Continuous Data Protection:

Clone:

CSV, Cluster Shared Volume: Ein (NTFS-) Laufwerk, das von allen Knoten eines Clusters benutzt wird.

Datenbanksicherung: Werden die Daten in einem VMFS abgelegt, kann man mit vMotion und den vStorage-APIs arbeiten. Werden die Daten per RAW-Device gespeichert, reduziert sich das Backup auf die Sicherung über das Netzwerk. (siehe auch: Daten in einer VM)

Daten in einer VM: Es gibt drei Möglichkeiten einer virtuellen Maschine Storage zur Verfügung zu stellen: 1. VMFS – das VMware Filesystem; 2. Oracle Datenbanken lassen sich virtualisieren, bevorzugen allerdings das RAW-Format; und 3. eine LUN auf einem Array erstellen und diese dem iSCSI-Initiator (IQM) in der VM präsentieren.

Datensicherung zwecklos: So ab mehreren Hundert Terabyte Daten überlegen Anwender, ob sich die Datensicherung auf ein Tape-Medium noch lohnt. Die Datenverfügbarkeit lässt sich damit nicht verbessern und das Kopieren und Verwalten der Tape-Daten und –Medien kostet viel Geld. Anwender mit solchen Datenmengen arbeiten auf die kurze Distanz mit einer synchronen Spiegelung und replizieren im aufwändigeren Falle explizit jeden Knoten des synchronen Spiegels in eine dritte und vierte Lokation.

Deduplizierung:

Differenzdatensicherung:

Disaster Recovery:

Einzeldatei-Restore, Single File Restore: Die Wiederherstellung eines einzelnen Files von Band benötigt von Band circa 15 Minuten. Im Backup-Katalog ist hierzu das Band zu identifizieren, das Band ist aus dem Archiv ins Laufwerk zu laden und der Streamer muss das Band bis zum nächsten Header vorspulen. Vergleich: Kann die Einzeldatei von einer Virtual Tape Library, also Festplatte, geladen werden, ist ein Zeitaufwand von etwa 2 Minuten zu kalkulieren. Ob sich der technische Aufwand wie auch die zusätzlichen Lizenzkosten lohnen, hängt von der Häufigkeit solcher Restores ab.

FC-Bandroboter, FC-Library: Während sich die VMware-Appliance beim Backup auf ein NAS-Share leicht tut, ist es für den IT-Administrator eine Herausforderung einer virtuellen Maschinen (VM) durch einen ESX-Server eine FC-Library zu zeigen. Das wird nur für ganz wenige FC-Bandroboter unterstützt und damit ist die Sicherung von Massendaten über ein schnelles Transportmedium in vielen Fällen nicht nutzbar.

File Level Restore aus einem VM-Snapshot: Kann nicht jede Backup-Software aus dem Snapshot einer virtuellen Maschine ein einzelnes Files wiederherstellen. Die Frage stellt sich wo die zeitliche Grenze für ein File Level Restore liegt.
 
File System Performance: Dateisysteme sind langsam. Jede tiefer gehende Verzeichnisstruktur kostet Performance, so dass eine Single-Stream Backup-Software wie Backup Exec nicht in der Lage ist, moderne Tape Laufwerke mit einem kontinuierlichen Datenstrom zu versorgen. Backup-Software wie Data Protector, Commvault, TSM, die mehrere Datenströme (Multiplexing) gleichzeitig unterstützt, ist zwar flotter beim Backup, kann dann aber beim Restore nicht mit der Single-Stream-Lösung mithalten. Ziel des Backups muss es allerdings sein, das Tape zum Bottleneck zu machen. Zum Vergleich: die File Systeme Performance bei Windows liefert Daten mit 7 bis 15 Megabyte pro Sekunde ab, SuSe-Linux Dateisysteme (Samba-Server mit Linux Media Agenten) transportieren Dateien mit bis zu 120 MByte/s. Zum Vergleich: Bei Datenbanken wie Oracle auf HP-UX bringt es die Backup-Software komprimiert auf 450 MByte/s pro Laufwerk.

Hypervisor: VMware, Hyper-V und Xen sind die bekannteren Hypervisoren. Obwohl sie dem Gast-Betriebssystem alle auf ähnliche Art und Weise die Ressourcen des Host zur Verfügung stellen, unterscheiden sie sich bei den Backup-Funktionen erheblich. Während VMware sich über vStorage-APIs mit vielen modernen externen Speichersystem verständigt, kann Hyper-V in Windows Umgebungen mit VSS konsistente Bedingungen bei der Datensicherung herstellen und bei XEN ist der Administrator auf Scripts verwiesen.  

Hyper-V: Hat Schnittstelle zu VSS. Das wird von vielen Backup-Programmen unterstützt. Ein Tool ist DPM.  

Inkrementelle Datensicherung:

iSCSI-SAN: Ein iSCSI-SAN sollte wie ein FC-SAN „gesizt“ werden. Das heißt, redundante Switche, die Jumbo-Frames und Flow-Control beherrschen sollten.

Image:

Migration: Unverzichtbar für das Disaster Recovery. Ausnahmsweise steht nicht der Anbieterwechsel im Vordergrund, sondern die Aus- wie die Rückverlagerung von virtuellen Maschinen inklusive der Daten. Letzteres stellt die große Herausforderung für alle Virtualisierungsanbieter dar, da die Bewegung größerer Datenmengen zwischen zwei Standorten nur mit tiefen Griffen in die technische Trickkiste zu bewältigen ist. Während für VMware-Umgebungen viele, auch von Storage-Herstellern, Verfahren für die unterbrechungsfreie Migration und Weiterbenutzung zur Verfügung stehen, besteht bei Microsoft einiger Nachholbedarf. Mit Windows Server 8 soll Hyper-V fähig werden die gesamten Daten auch ohne den Virtual Machine Manager über das Netzwerk kopieren zu können.

LAN Backup&Restore: Auch wenn Backup&Restore hier zusammengeschrieben werden, um den Sinn dieser Kopieraktion anzudeuten, so verlaufen beide Prozesse in der Praxis sehr unterschiedlich. Ein schnelles Backup ist nur auf Kosten eines langsamen Restores möglich oder umgekehrt. Siehe auch Multistreaming und File System Performance.

LTO-5: Das derzeitige Maß aller Dinge in der Streamer-Technik – nach Marktanteilen betrachtet. Oracle wie auch IBM können leistungsfähigere Laufwerke liefern, die aber für den Massenmarkt zu teuer sind. Seit dem zweiten Quartal 2010 ist LTO-5 mit einer komprimierten Speicherkapazität bis zu 3 TByte sowie einer Transferrate von bis zu 280 MByte/s auf dem Markt. Um die Anforderungen an die Datenquelle zu senken, hat HP das eigene Laufwerk so modifiziert, dass unkomprimierte Datenraten im Bereich von 47 bis 140 MByte/s verarbeitet werden können.

NDMP, Network Data Management Protocol: Proprietäres Ptorocol, das bei Filern genutzt wird. Das Backup erfolgt sehr schnell, der Restore ist aufwändiger. NDMP umgeht den auch bei einem FC-SAN-Backup notwendigen Umweg über den Backup-Server und schreibt die Daten direkt vom Filer auf die Tape Library. Das macht NDMP so schnell. Der Backup-Server erhält nur den Report über die gesicherten Dateien. Zu beachten ist, dass der Einsatz einer Deduplizierung nur mit einer für NDMP zertifizierten Dedup-Appliance möglich ist.

Notfallhandbuch: Ein Notfallhandbuch sollte die möglichen Fehlerquellen der IT enthalten und Gegenmaßnahmen aufzeigen. Wichtig ist auch zu wissen, wer entscheidet, ob überhaupt ein Fehler aufgetreten ist, und wer darf mir Anweisungen erteilen, einen Restore durchzuführen. Das lässt sich beliebig mit Erfassung aller Services und Service-Owner und dem entsprechenden Wiederherstellungsprozessen vertiefen.

Online-Backup: Gemeint ist nicht, die Datensicherung eines Speichersystems im laufenden Betrieb. Dies ist zwar prinzipiell durch einen Snapshots möglich, führt aber dazu, dass sich schon während dieser kurzen Phase Datenblöcke ändern könnten. Das Backup wäre inkonsistent und damit unbrauchbar. Bei einem Online-Backup spricht die Backup-Anwendung mit der Datenbank, die alle Transaktionen kurz anhält, so dass ein stabiler Zustand entsteht. Zusammen mit den Daten aus dem Transaktionslog lässt sich (meistens) ein arbeitsfähiger Restore generieren. Dies sollte ab und zu durch einen Test sichergestellt werden.

Online-Deduplizierung: Der Speicherplatz auf den primären Speichersystemen ist teuer. Warum also nicht direkt die Daten an der Quelle deduplizieren sprich komprimieren. NetApp zum Beispiel erlaubt es in einem Post-Prozess ein Volume zu deduplizieren. Eine Überprovisionierung des Volumes ist damit möglich. Eine gewisse Geschicklichkeit ist allerdings notwendig, wenn man das Backup dieses Volumes restaurieren will, da auf dem Tape nur die entdeduplizierten Daten gespeichert werden. Einziger Anbieter ist Commvault, der auch deduplizierte Daten auf Band schreiben kann.

Performance:

Point in Time:

Point in Time Restore:

Priorisierung: Die Datenmenge auf Fileservern wächst bekanntermaßen immer schneller. Die Faustregel besagt, dass sich etwa 100 GByte pro Stunde auf ein Band sichern lassen. In vielen Fällen bei Datenmengen oberhalb von ein Terabyte reicht damit das Backup-Fenster nicht mehr für eine Vollsicherung. Wer die aktiven Daten priorisieren kann und damit die inaktiven auf ein preiswerteres Speichermedium migrieren kann, der beschleunigt seine Datensicherung erheblich.

Protokolle: Daten lassen sich von der Quelle zum Ziel mit unterschiedlichen Protokollen transportieren. Zu den bekannten gehören CIFS (Windows), NFS (Unix), iSCSI (IP-SAN) und FC (FC-SAN).

Quota: Speicherplatzbeschränkung. Jede Überschreitung kostet Budget. Quotas können aber auch das ungebremste Wachstum unstrukturierter Dateien hemmen und so das Backup erleichtern.

Raw Device: Das Storage-System hat eine LUN, die durch den ESX-Server an die Host-Anwendung durchgereicht wird. Dieses RAW-Device lässt sich nicht „sharen“ und kann nur von einem Host benutzt werden. RAW-Devices lassen sich nicht mit VMware Bordmittel sichern. Der Snapshot muss im Storage-Array angestoßen werden.

Recover Point:

Replikation:

Reporting: Dokumentation ist ein ungeliebtes Thema. Aber die Frage nach der aktuellen Datenmenge kommt irgendwann immer. Wie viele Daten müssen Sie sichern, welches Datenwachstum haben Sie. Mit einem monatlichen Report aus dem Backup können Sie diese wichtigen Daten für ein neues Backup-Konzept schnell generieren.  

Retention Time, Aufbewahrungszeitraum: Während niemand ein älteres Backup ohne Not auf ein Produktivsystem zurückspielen will, ist das für eine einzelne Datei nicht so abwegig. Wer diesen Zeitraum erweitern will, ohne die vorhandenen Speicherkapazitäten aufzurüsten, dem bleibt der Weg über Deduplizierung oder „for ever incremental“. Hier wachst die Datenmenge über die Zeit nur langsam an.
:
 
Restore: Wer entscheidet darüber, dass ein Restore notwendig ist und durchgeführt werden muss?

RPO, Recovery point Objective, Datenverlust:

SAN, Datenströme über FC:

Schnelle Daten, langsame Daten: Auch wenn viele das Tape als Backup-Medium immer wieder aufs Neue Abschreiben und es gerade noch für Archivierungszwecke gelten lassen, für schnelle Daten, und das sind Datenbankdaten, gibt es nichts effizienteres als Tape. Mit einem modernen Tape kann man heutzutage 460 MByte Daten pro Sekunde „wegschaufeln“.  

Sharepoint: Immer mehr Dokumente werden in Sharepoint-Umgebungen aufbewahrt. Der Backup-Operator muss hier die Abhängigkeiten berücksichtigen, da Sharepoint aus einem Portal-, einem Application- und einem Datenbankserver besteht. In einer größeren Umgebung sind Portal- und Application-Server auf einem Rechner installiert, der Datenbank-Server ist eventuell geclustert auf anderen Servern. Die Sharepoint-Integration der Backup-Software muss Farm-aware sein. Eine diskrete Sicherung der einzelnen Farmbestandteil ist möglich, benötigt aber viel Aufwand bei einem Restore, um die voneinander abhängigen Komponenten wieder in einen konsistenten Zustand zu bringen. Ein Farm-aware Client kann diese Aufgabe erleichtern. Der Tivoli Storage Manager, TSM, z.B. erlaubt dem Site-Manager einzelne Dateien zurück zu spielen.
 
Snapshot, Clone, Point in Time Copy: Wie man ein Foto von einer Person machen kann, so kann man auch von einem Speichersystem einen Schnappschuss machen. Beide zeigen ein Abbild aus der Vergangenheit. Ein Unterschied der beiden Snapshots ist, dass man zu dem vergangenen Zustand des Speichersystems zurückkehren und auf dieser Basis wieder weiterarbeiten kann.

Snapshot der Speicherfestplatte: Moderne, durch einen Controller gesteuerte Speichersysteme sind in der Lage selbst einen Schnappschuss von einer LUN anzufertigen. Diese LUN-Kopie kann man einem Backup-Server präsentieren, der dann alle Daten über ein FC- oder iSCSI-SAN abholen kann. Dadurch sind weder ESX-Server, noch das produktive LAN mit Datentransfers belastet. Diese gilt auch für Raw-Devices.


SMB-Protokoll: Der immer wieder restaurierte Ursprung aller CIFS-Varianten. Über SMB oder SAMBA bei Linux lassen sich Netzwerk-Shares einrichten. Im Windows Server 8 wird diese Funktionalität auf VHD(X)-Dateien erweitert, so dass dort dann auch der Disk Storage virtueller Maschinen abgelegt werden kann. Da diese Funktion unternehmenskritisch ist, arbeitet Microsoft an der Cluster-Fähigkeit der SMB-Freigaben.

SSD, Solid State Disk: Für eine Beschleunigung des File-Backups helfen die schnellen Halbleiterfestplatten nicht. Der limitierende Faktor bleibt das Filesystem, das möglichst flach angelegt sein sollte.

Stream:

Synchroner Spiegel: Über zwei voneinander unabhängige Netzwerkpfade werden Daten auf zwei entfernt voneinander stehende Speichersysteme geschrieben. Der Hardware-Ausfall in dem einen Zweig kann durch das Zweitsystem kompensiert werden. Nachteil: Logische Fehler und Viren werden immer sofort auf beide Systeme übertragen.


Test: Wann haben sie das letzte Mal getestet, ob sich Dateien, einer oder mehrere Services wiederherstellen lassen? Mittels Servervirtualisierung und der Umwandlung von physischen Images auf virtuelle Maschinen sollte sich diese unangenehme Frage in Zukunft viel leichter mit einem „vor kurzem“ beantworten lassen.

Treewalk: Bei diesem Vorgang guckt das Backup-Programm, was denn alles zu sichern ist. Bei 10.000 Dateien ist das kein größerer Zeitaufwand. Handelt es sich jedoch um einige Millionen Dateien, dann ist schon dieser erste Schritt sehr zeitaufwändig. Da Dateien unterschiedlichster Größenordnung in den Verzeichnissen abgelegt werden, sind Datentransferraten von 20 MByte/s ziemlich gut. Nur mit Multistreaming lassen sich dann moderne Streamer mit einem ausreichenden Datennachschub am Laufen halten.

Trunk: Backup-Server sind in vielen Fällen mit zwei Netzerkkarten mit je zwei Ports ausgestattet. Diese vier Leitung lassen sich per Software-Treiber zu einem Trunk verbinden, der bei je 1 GBit/s einen Datendurchsatz von 320 MByte pro Sekunde zulässt. Diese Leistung lässt sich vermutlich nur mit Datenbankdateien, keinesfalls aber mit Fileserver-Dateien umsetzen.

Unified Remote Access: Eine für Windows Server 8 geplante Funktion, die VPN und WLAN koppeln soll. Die lokal laufende VM ließe sich so ohne weitere Konfiguration auf einen zweiten Server verschieben unter Beibehaltung der lokalen IP-Adresse.

VHD, virtuelle Harddisk: Ablageort für virtuelle Festplatten. Der präferierte Ort dafür waren bislang lokal installierte Festplatten oder CSVs. Der Ablageort wird in Zukunft auf Netzwerkfreigaben erweitert.

Vollsicherung:

Virtueller Switch: Virtuelle Maschinen verbinden sich per virtuellem Switche mit dem realen Netzwerk. In Windows Server 8 wird Microsoft dies um Filterfunktionen ergänzen, so dass sich Bandbreitenbegrenzungen einstellen lassen. Außerdem wird DHCP- und Router-Advertisement-Traffic ausgfiltert.

VTL, Virtual Tape Library: Eine VTL ist die Emulation einer Bandbibliothek. Vorteil: Der Host sieht eine normale Library und kann diese wie gewohnt als Ziel eines Backup-Jobs angeben. Zusammen mit Deduplizierung kann man die Datenmenge auf der VTL oder dem D2D-System konzentrieren. Mit solchen Appliances lassen sich dezentrale Datensicherungen mit geringerem Aufwand zur Zentrale übertragen und dort konsolidieren.   

Tivoli, “for ever incremental”:

VAAI:

VMDK, Virtual Machine Disk Format:

VMFS, Virtual Machine File System: Konventionelle Dateisysteme gewähren jeweils nur einem Server den Lese-/Schreibzugriff auf eine bestimmte Datei. VMware vStorage VMFS ist dagegen ein Cluster-Dateisystem, das von den Vorteilen eines gemeinsam genutzten Storage-Systems profitiert und es mehreren Instanzen von VMware ESX ermöglicht, parallel im selben Storage zu lesen und zu schreiben.
[[Das VMware VMFS (Virtual Machine File System) unterstützt Filesystem-Größen von mehr als 2 TB. Allerdings ist es dazu erforderlich, mehrere RAID Volumes (von denen jeweils maximal 2 TB minus 512 Byte genützt werden können) als sogenannte VMFS Extends zusammenzufassen. [[Umschrieben]]


Falls Sie etwa ein VMFS mit 3 TB nutzen möchten, erstellen Sie auf dem RAID System dazu z.B. zwei RAID Volumes mit jeweils 1,5 TB. Diese beiden RAID Volumes fassen Sie dann als zwei Extends zu einem VMFS mit 3 TB zusammen.
VMware Data Recovery 2.0, VDR 2.0: Integration von Datenbanken, soll besser sein.
VSS, Volume Shadowcopy Services: Das VSS-System besteht aus drei Teilen: einem Requester, einem Provider und einem Writer. Der Requester ist die Applikation, die einen Snapshot anfordert und der Provider erstellt diesen. In einer einfachen Konfiguration ist das Windows-Betriebssystem selbst der Provider, in größeren Systemen kann der Provider ein Speichersystem sein, das mit VSS verbunden ist. Zu guter Letzt muss jede Anwendung, die von VSS unterstützt werden soll, ihren eigenen VSS Writer erzeugen. Dieser stoppt alle Schreibaktivitäten der Anwendung und erzeugt anschließend einen Snapshot.

Vplex

vStorage-API:
Vorsicht: zeigen Sie Windows niemals die VMware-LUNs. Dem Diskmanager bei einem Rescan der Speichersystems niemals alle Abfragen gedankenlos zu bestätigen, da Microsoft immer noch alle LUNs mit seiner Signatur überschreibt und unlesbar macht.

VADP, VMware Storage APIs for Data Protection:

Wartungsvertrag: Eine Alternative zu jedem Service, der nicht virtualisiert werden sollte und für den ein Cluster zu aufwändig ist.

Wiederherstellungszeit: Die gesamte Zeitdauer vom Beginn eines IT-Crashs bis zur Wiederherstellung des Service. Dies schließt den Austausch der Hardware, die Installation des Betriebssystems, den Restore der Daten, das Recovery der Daten, Test der Daten, und die Freigabe der Daten durch den Fachbereich ein.
Eine Alternative zu dieser konventionellen Wiederherstellung eines Services wäre es ein Point-in-Time-Recovery durchzuführen, also einen älteren Snapshot zu benutzen, auf dem die Anwender wieder konsistent aufsetzen können. Zu prüfen wäre dabei, ob dieser Wiederherstellungspunkt nicht zu alte Daten benutzt und wenn ja, ob sich die in der Zwischenzeit neu hinzugekommenen Daten wieder nachtragen lassen. Das ist auf jeden Fall mit der Geschäftsführung zu besprechen.

XEN: Die Backup-Schnittstelle von XEN ist ein Script. Das Script veranlasst den XEN-Server einen Snapshot anzufertigen und dieser wird danach dem Backup-Server präsentiert.