Dramatisch wachsende Datenmengen

Ein Ausweg kann sein, einen einzigen Backup-Agenten auf die Service-Console der virtuellen Maschine zu setzen. Bei diesem Verfahren wird das Backup für alle Maschinen auf einmal erledigt, ein SAN ist nicht notwendig. So sinken auch die Kosten für Connectivity und Lizenzen. Doch auch diese Lösung ist nicht ohne Wermutstropfen. Inkrementelle Backups sind nicht mehr möglich. Vielmehr wird das gesamte Backup zu einem einzigen, riesigen File, das bei jedem Backup neu abgelegt wird. Ein Recovery auf File-Ebene ist nicht möglich. Das hat zur Folg, dass hierfür doch wieder ein Backup-Agent auf jeder VM gebraucht wird.

Alle Anwenderdaten und Informationen zur Konfiguration des Virtuellen Servers werden beim Backup in .vmdk-Files gespeichert. Die Übertragung dieser oft über zwei TB großen Dateien bedingt eine hohe I/O- und CPU-Last. Dies kann schnell zu Engpässen im Storage-Controller oder im Netzwerk führen. Selbst wenn diese Ressourcen ausreichen, müssen immer noch auch Netzwerk- und Storage-Adapter geteilt werden. Ressourcen werden so zum kontinuierlichen Problem.

Schlimmer noch: Da etwa Betriebssysteme oder Anwendungen innerhalb der VMs redundant sind, steigt die Datenmenge weiter. Auch muss die Virtualisierungsschicht selbst gesichert werden. Diese .vmx-Files enthalten wichtige Konfigurationsdaten jeder VM. Und dann gibt es noch die Host-Daten des physikalischen Servers, also Systemdaten, virtuelle Netzwerk-Daten und Speicherkonfigurationen. All dies muss für ein Disaster Recovery schnell wieder herstellbar sein. Keine kleine Aufgabe für ein Backup - das noch dazu schnell ablaufen muss.