Disaster Recovery Produkte für VMware

Virtualisierte Infrastrukturen haben außer einem effizienteren Einsatz der Ressourcen vor allem den Vorteil, dass sie im Vergleich zu klassischen Serverarchitekturen mit deutlich weniger Aufwand hochverfügbar gestaltet werden können. Virtuelle Maschinen können dann bei einem Serverausfall automatisch auf alternativer Hardware gestartet oder vor einer Wartung unterbrechungsfrei auf einen anderen Storage verschoben werden. Das ist perfekt für den Alltag. Doch was passiert in einem Notfall, wenn ungeplante Ereignisse die gesamte Infrastruktur lahmlegen oder einzelne Anwendungen unbrauchbar machen? In solchen Situationen benötigen Firmen einen Plan B, der nicht nur auf dem Papier gut aussieht, sondern auch in der Praxis funktioniert. Entsprechende Lösungen waren früher sehr aufwendig und teuer. Heute gibt es immer mehr Produkte, mit denen ein Disaster Recovery für virtuelle Maschinen nicht gerade zum Kinderspiel, aber doch viel einfacher und vor allem bezahlbar wird.

Nachfolgend stellen wir fünf Produkte vor, mit denen virtuelle Maschinen und Anwendungen in VMware-Umgebungen repliziert und im Notfall wiederhergestellt werden können:

    1. VMware vCenter Site Recovery Manager
    2. Zerto Virtual Replication
    3. Veeam Backup & Replication
    4. PHD Virtual Backup & Replication
    5. PHD Virtual Reliable DR

Im Anschluss daran finden Sie unser kurzes Fazit und eine Tabelle mit allen wichtigen Leistungsmerkmalen im Überblick.

VMware vCenter Site Recovery Manager (5.5)

Der vCenter Site Recovery Manager (SRM) ist das hauseigene Disaster Recovery Produkt von VMware. Die Management Schnittstelle der Software ist eng in den vCenter Server integriert und fügt zusätzliche Menü-Elemente für die Administration der Recovery-Funktionen hinzu.

Was wird benötigt?

Voraussetzung für den Einsatz des Site Recovery Managers (SRM) ist eine dedizierte vSphere Infrastruktur sowohl am Produktiv- als auch am Recovery-Standort. Auch die SRM-Lizenzen müssen für beide Standorte gekauft werden. Da der vCenter SRM nur das Recovery steuert, nicht aber auch die Replikation der virtuellen Maschinen, muss er noch durch eine geeignete Replikationslösung ergänzt werden. Idealerweise nimmt man dafür vSphere Replication, das mittlerweile kostenlos im Lieferumfang von verschiedenen vSphere Lizenzen enthalten ist. Darüber hinaus können auch Array- (Storage-) basierte Replikationslösungen von Drittanbietern integriert werden. Die Ausführungen in diesem Artikel beziehen sich auf die aktuelle Version des vCenter SRM (5.5) und den Einsatz mit vSphere Replication.

vSphere Replication (VR) wird als virtuelle Appliance an beiden Standorten installiert. Zur Appliance gehören der vSphere Replication Server und der vSphere Replication Management Server (VRMS). Es wird mindestens ein Replication Server pro Host bereitgestellt. Die SRM Server Software wird ebenfalls an beiden Standorten mit einer eigenen Datenbank installiert und in den vCenter Server integriert.

Wie funktioniert es?

Über das entsprechende Menü wählt man zunächst die virtuellen Maschinen aus, die repliziert werden sollen. Diesen werden anschließend Ressourcen am Ziel- bzw. Recovery-Standort zugewiesen. Der Replication Server auf dem ESX Host fungiert als Agent, der alle Änderungen in der geschützten Maschine erfasst und zum Agenten am Recovery-Standort sendet, wo sie der replizierten Offline-Version der virtuellen Maschine hinzugefügt werden. Dabei spielt es keine Rolle, von welchem Typ oder Hersteller die Storage-Systeme am jeweiligen Standort sind.  vSphere Replication repliziert asynchron. Als Recovery Point Objective (RPO), also die maximale Zeitspanne innerhalb der Daten unwiederbringlich verloren gehen dürfen,  kann ein Wert zwischen 15 Minuten und 24 Stunden gewählt werden. Ein RPO von 15 Minuten bedeutet, dass alle 15 Minuten die jeweils letzten Änderungen repliziert werden.

vSphere Replication arbeitet ohne Snapshots und damit auch ohne nennenswerte Beeinträchtigung der Performance. Eine Ausnahme ist die anwendungskonsistente Replikation auf der Basis von Microsoft Volume Snapshot Service (VSS) – diese sind mit entsprechenden Snapshots verbunden. Informationen über geänderte Blöcke werden in einer PSF-Datei („Persistent State File“) im Verzeichnis der virtuellen Maschine (VM) gespeichert. Bei jedem Replikationszyklus werden die geänderten Blöcke als LWD („Lightweight Delta“) gebündelt zum Recovery-Standort übertragen. Die Replikation nutzt nicht die CBT-Funktion („Changed Block Tracking“) von vSphere, die somit weiterhin für Backup und andere Programme uneingeschränkt verfügbar bleibt.

Was kann es?

Für die Erstsynchronisation können sogenannte „Seed“-Kopien am Recovery-Standort genutzt werden, um die Bandbreite für das erstmalige Replizieren zu minimieren. Anschließend werden nur noch die geänderten Blöcke repliziert.

Für das Failover, also das Starten der Ersatzsysteme am Recovery-Standort, kann man die Boot-Reihenfolge definieren und individuelle Skripts hinterlegen. Auch die IP-Adressen der virtuellen Maschinen können automatisch neu konfiguriert werden. Darüber hinaus ist es möglich, mehrere Standorte in das Disaster Recovery einzubinden, die alle an einen gemeinsamen Recovery-Standort replizieren.

Die Recovery-Pläne können ohne Unterbrechung der Produktionssysteme automatisiert getestet werden. Dafür werden die replizierten Maschinen in einer separaten Umgebung gestartet, getrennt von den virtuellen Maschinen der Produktionsumgebung. Die Ergebnisse der Tests und das erreichte Recovery Time Objective (RTO) können als detaillierte Berichte ausgegeben bzw. gespeichert werden.

Normalerweise wird beim Disaster Recovery immer der zuletzt  replizierte Stand der virtuellen Maschine wiederhergestellt.  Falls aber die letzte Version fehlerhaft ist oder aus einem anderen Grund  eine frühere Version bevorzugt wird, benötigt man historische Wiederherstellungspunkte.  Dieses sogenannte Multiple-Point-In-Time-Recovery (MPIT) bietet jetzt auch die neueste Version des vCenter Site Recovery Managers. Dafür können bis zu 24 historische Snapshots der Replica-VM gespeichert und via Snapshot Manager rekonstruiert werden.

Der Site Recovery Manager mit vSphere Replication kann auch genutzt werden, um virtuelle Maschinen geplant an einen anderen Standort zu migrieren. Mittels Datensynchronisation wird sichergestellt, dass die virtuellen Maschinen am Zielstandort anwendungskonsistent und ohne Datenverlust starten.

Zerto Virtual Replication 3.0

Während der Site Recovery Manager von VMware eher ein Orchestrierungswerkzeug ist, das Replikationstools über Schnittstellen integriert, wurde Zerto explizit als Disaster Recovery Lösung für virtuelle Infrastrukturen entwickelt. Eine beliebig skalierbare, Hypervisor-basierte Replikationslösung ist das zentrale Element der Software.

Was wird benötigt?

Zerto Virtual Replication wird an allen Produktivstandorten, die repliziert werden sollen und am Ziel- bzw. Recovery-Standort installiert. Zunächst wird der Zerto Virtual Manager als virtuelle Appliance (Windows) installiert und in das vCenter Management integriert. Für jeden ESX-Host wird eine Virtual Replication Appliance benötigt, die der Virtual Manager softwarebasiert automatisch bereitstellt. Wenn die Daten zu einem Cloud Provider repliziert werden sollen, um die Ersatzsysteme im Notfall in einer gemieteten Infrastruktur wiederherstellen zu können, werden die anderen Komponenten vom Cloud Provider bereitgestellt. Für die Kommunikation zwischen Kunden-Standort und Cloud Provider wird üblicherweise eine IPSec-VPN Verbindung genutzt, die separat aufgebaut werden muss. Die Replikation zu einem zertifizierten Service Provider unterstützt Zerto darüber hinaus mit einem flexiblen Lizenzmodell. Der Kunde zahlt in diesem Fall nur eine monatliche Gebühr die abhängig von der Anzahl der virtuellen Maschinen, die gleichzeitig repliziert werden sollen und dem insgesamten Storagebedarf ist.

Wie funktioniert es?

Der Zerto Management Server wird bei der Installation in den vCenter Server integriert und der vCenter Client mit Hilfe eines Plug-Ins um neue Menüfunktionen ergänzt. Über den vCenter Client können anschließend die virtuelle Maschinen für die Replikation ausgewählt, der Ziel-Standort definiert und Disaster Recovery Pläne erstellt und getestet werden. Die kontinuierliche Replikation von Zerto arbeitet fast in Echtzeit und ermöglicht so RPOs im Sekundenbereich. Dabei kommt Zerto komplett ohne Snapshots aus und beeinträchtigt deshalb auch nicht die Performance der Anwendungen. Die Daten werden von der Virtual Replication Appliance (VRA) direkt aus dem I/O-Datenverkehr der virtuellen Maschinen kopiert und komprimiert zur VRA am Recovery-Standort übertragen. Ebenfalls ohne Snapshots funktioniert das Multiple-Point-In-Time-Recovery von Zerto, über das beliebige Zeitpunkte innerhalb eines bis zu 5 Tage großen Zeitraums wiederhergestellt werden können. Das Produkt ist nicht an bestimmte Storage-Systeme gebunden. Heterogene Storage-Plattformen am Produktiv- und Recovery-Standort sind also kein Problem. Im Zusammenhang mit einem Cloud Anbieter kann die Wiederherstellung direkt in ein virtuelles Datacenter des Kunden erfolgen.

Was kann es?

Zerto unterstützt ebenfalls diverse „Seeding“-Optionen für die Erstreplikation und repliziert anschließend nur die geänderten Blöcke. Darüber hinaus arbeitet die Software mit Datenkomprimierung und WAN-Optimierung, um die Bandbreitennutzung zu minimieren, ohne die RPOs zu gefährden.

In einem Notfall geht es darum, geschäftskritische Applikationen wiederherstellen zu können. Komplexe Anwendungen laufen aber oft nicht auf einer einzelnen Maschine, sondern basieren auf mehreren Komponenten (mehrere Datenbank-, File- und Webserver etc.) bzw. sind horizontal skaliert. Mit Zerto kann man virtuelle Maschinen zu sogenannten Virtual Protection Groups (VPG) zusammenfassen.  Außerdem wird sichergestellt, dass die Anwendungen mit einem konsistenten Datenbestand repliziert und wiederhergestellt werden. Zwei virtuelle Maschinen in einer Virtual Protection Group haben also immer einen zeitsynchronen Stand (im Gegensatz zu anderen Produkten, bei denen die VMs mit leicht voneinander abweichenden Zeitständen wiederhergestellt werden). Das funktioniert auch, wenn sich die VMs auf verschiedenen Hosts und Storage-Einheiten befinden. Beim Failover werden die Maschinen mit einer definierten Boot-Sequenz gestartet. Darüber hinaus können diverse „Quality of Service“-Regeln definiert werden. Wenn nicht der letzte, sondern ein früherer Stand wiederhergestellt werden soll, lassen sich mit der Journal-Funktion bis zu 5 Tage alte historische Wiederherstellungspunkte auswählen.

Zerto bietet darüber hinaus umfangreiche Test- und Reporting-Optionen.  So sieht der Anwender jederzeit, ob die definierten RPOs eingehalten werden.  Die Disaster Recovery Pläne können beliebig oft getestet werden. Für ein Test-Failover werden die replizierten Maschinen und Anwendungen am Recovery-Standort in einer „Sandbox“-Umgebung wiederhergestellt, ohne den Betrieb der Produktivsysteme am primären Standort zu beeinflussen. Auch wird während des Test-Failovers die Replikation aufrecht erhalten, sodass der Schutz auch während einer Tests erhalten bleibt.

Schließlich kann man mit Zerto auch virtuelle Maschinen und Anwendungen ohne längere Betriebsunterbrechung an einen anderen Standort migrieren bzw. Klone für Tests etc. erstellen.

Veeam Backup & Replication v7

Veeam Backup & Replication wurde speziell für die Datensicherung in virtuellen Umgebungen entwickelt. Es kombiniert umfangreiche Backup-Funktionen für Dateien und virtuelle Maschinen mit imagebasierter Replikation für das Disaster Recovery von virtuellen Maschinen.

Was wird benötigt?

Veeam Backup & Replication wird auf einem Windows-Server (bzw. einer virtuellen Maschine) installiert. Zum Lizenzumfang gehört der Backup Enterprise Manager Server für die Administration der Software. Mit der Version 7  bietet Veeam auch ein Plug-In für den vSphere Web Client. Damit kann man sich Statusinformationen und Statistiken über den Stand der Datensicherung anzeigen lassen.

Wie funktioniert es?

Von den zu schützenden Maschinen werden identische Kopien (Replicas) am Ziel- bzw. Recovery-Standort angelegt und fortlaufend synchronisiert. Veeam nutzt dafür Snapshots. Aus den Snapshots werden jedes Mal nur die geänderten Datenblöcke zur Replica kopiert. Im Gegensatz zum Backup werden bei der Replikation die Kopien nicht in komprimierter Form gespeichert, so dass sie sofort startfähig sind. Analog dem Backup wird auch die Replikation über Jobs gesteuert. Jobs können manuell oder automatisch gestartet bzw. kontinuierlich ausgeführt werden. Eine kontinuierliche Replikation einer VM bedeutet, dass sofort nach der Erstellung, Übertragung und Löschung eines Snapshots direkt der nächste Durchlauf angestoßen wird. Das führt zu RPO-Zeiten im Minutenbereich, belastet aber wegen der Snapshots auch deutlich die Produktiv-Infrastruktur.

Erfolgt die Replikation über WAN, kann an beiden Standorten ein VMware Backup Proxy bereitgestellt werden. Optimierungsfunktionen wie Komprimierung und Bandbreitenbegrenzung unterstützen einen effizienten Datentransfer.

Was kann es?

Damit große Datenmengen initial nicht über das WAN repliziert werden müssen, bietet auch Veeam eine Seeding-Funktion. Dafür wird zunächst ein Backup erzeugt, aus dem am Recovery-Standort die virtuelle Maschine wiederhergestellt und als Ziel für die Replikation definiert wird. Mehrere virtuelle Maschinen können gruppiert und in einem Replikationsjob zusammengefasst werden.

Für jede Replica kann eine frei wählbare Anzahl Wiederherstellungspunkte gespeichert werden. Dafür werden alle Änderungen seit dem letzten Durchlauf in einer Snapshot Deltadatei gespeichert. Wegen der bekannten Snapshot-Restriktionen sollte man die Anzahl der Wiederherstellungspunkte in der sogenannten „Retention Policy“ begrenzen.

Wenn in einem Notfall die Maschinen am primären Standort nicht mehr verfügbar sind, können die Replicas am Recovery-Standort mit dem letzten Stand oder einem der Wiederherstellungspunkte aktiviert werden. Dieses Failover ist für Veeam ein vorübergehender Zustand, der in ein permanentes Failover geändert werden kann. In diesem Fall wird der Replikationsjob für die betroffene Maschine gelöscht. Alternativ kann auch ein Failback durchgeführt werden, wobei mit Hilfe der Replica die virtuelle Maschine am Produktivstandort wiederhergestellt wird.

Mit der Funktion „Quick Motion“ können virtuelle Maschinen von einem ESX Host bzw. Storage auf einen anderen verschoben werden. Veeam nutzt dafür die VMware vCenter Operationen vMotion und Storage vMotion und ist vor allem dann eine sinnvolle Ergänzung, wenn die VMware-Operationen selbst, z.B. aus Lizenzgründen, nicht zur Verfügung stehen.

Mit der Funktion „SureReplica“ können die Replicas und sämtliche Wiederherstellungspunkte überprüft werden. Die replizierten Maschinen können am Recovery-Standort auch in einer „Sandbox“ bzw. einem „Virtual Lab“ gestartet werden, einer isolierten Umgebung zum Testen des Disaster Recovery ohne Beeinträchtigung der Produktivsysteme.

PHD Virtual Backup & Replication (v 6.5)

Mit seinem Produktportfolio konzentriert sich PHD Virtual ebenfalls auf das Backup und die Wiederherstellung von virtuellen Maschinen.  VMware Backup & Replication bietet Backup-Funktionen und zusätzlich noch die Möglichkeit, die Backups an einen anderen Standort zu replizieren. Die Software kann durch weitere Produkte ergänzt werden. Dazu gehören der CloudHook für das einfache Speichern der Backups in der Cloud und PHD Virtual Reliable DR, mit dem das Disaster Recovery automatisiert und getestet werden kann.

Was wird benötigt?

PHD Virtual wird als virtuelle Appliance (Linux) geliefert und komplett in vSphere integriert und über ein Plugin im vSphere Client administriert. Deshalb wird auch zuerst das Plug-in für VMware vCenter  installiert und anschließend die Virtual Backup Appliance (VBA) in die vSphere Umgebung importiert. Eine VBA ist in der Regel ausreichend für einen VMware Cluster. Wenn mehr Leistung benötigt wird, können weitere VBAs installiert werden. Da die Appliances auf Linux basieren, werden keine Windows Lizenzen benötigt. Auch Backup Proxy Server wie bei Veeam werden mit PHD Virtual nicht benötigt.

Wie funktioniert es?

Die Replikation ist eine Zusatzfunktion zum Backup. Basis der Replikation sind die von der Virtual Backup Appliance (VBA) erstellten Backups. PHD Virtual erstellt wie Veeam imagebasierte Backups auf Blockebene.  Dafür wird ein Snapshot der VM erzeugt und der VBA angefügt. Dieser Snapshot wird wieder gelöscht, sobald das Backup abgeschlossen ist. Mit Hilfe dieser Backups werden am Recovery-Standort identische Kopien der produktiven virtuellen Maschinen erstellt, die im Notfall sofort startfähig sind. Die VBA am Recovery-Standort liest die Daten aus dem Backup-Storage am Produktivstandort und repliziert sie zum Ziel-Storage.

Was kann es?

Auch PHD Virtual bietet „Seeding“ Optionen, damit die virtuellen Maschinen initial nicht komplett über das WAN repliziert werden müssen. So kann zum Beispiel ein Backup der Maschine auf einem beweglichen Speichermedium erzeugt werden. Am Recovery-Standort wird dieses Backup in den eigentlichen Ziel-Storage repliziert.

PHD Virtual arbeitet ausgesprochen WAN-effizient. Repliziert wird inkrementell, also nur die geänderten Daten. Deduplizierung und Komprimierung verringern zusätzlich die benötigte Bandbreite. Darüber hinaus kann die Backup-Appliance mehrere Backup- und Restore-Prozesse gleichzeitig, d.h. parallel durchführen.

Wird das Failover aktiviert, werden die Replicas am Recovery-Standort gestartet und können die Rolle der Produktivsysteme übernehmen. Die entsprechenden Maschinen werden dann automatisch aus dem Replikationsjob entfernt. Die Replicas können auch in einem Test-Modus gestartet werden, um das Disaster Recovery ohne Beeinträchtigung der Produktivsysteme zu testen.

PHD Virtual Reliable DR 

Während PHD Virtual Backup & Replication in erster Linie ein Backup-Produkt ist, mit dem man auch seine Backup-Daten an einen anderen Standort replizieren kann, konzentriert sich Reliable DR ganz auf das Disaster Recovery. Das Produkt bietet umfangreiche Test- und Reporting-Funktionen für eine garantierte Wiederherstellung der Systeme  und Anwendungen am Ersatzstandort. Zum Funktionsumfang gehört auch eine Snapshot-basierte Replikation. PHD Virtual Reliable DR kann aber auch als funktionelle Ergänzung zusammen mit anderen Replikationsprodukten eingesetzt werden.

Was wird benötigt?

PHD Reliable DR wird am Recovery-Standort auf einem Windows 2008 Server, vorzugsweise als virtuelle Maschine, installiert. 

Wie funktioniert es?

Für das Replizieren der virtuellen Maschinen stehen drei Alternativen zur Verfügung:

  • Replikation mit dem im Produkt integrierten Replikationstool
  • Replikation mit PHD Virtual Backup & Replication (siehe oben)
  • Integration einer SAN-basierten Replikationslösung eines anderen Anbieters  (erfordert passende Storage-Systeme an beiden Standorten)

PHD Virtual Reliable DR interagiert mit dem Hypervisior am Produktivstandort, ohne dass dort Software installiert werden muss. Sämtliche Prozesse werden vom Recovery-Standort aus gesteuert. Die im Produkt integrierte Replikation erstellt von den zu replizierenden Maschinen Snapshots und überträgt diese zum Replica-Standort. Hierfür muss genügend Bandbreite vorhanden sein, da Funktionen wie Deduplizierung oder Komprimierung fehlen. Hierfür empfiehlt es sich, Reliable DR in Kombination mit PHD Virtual Backup & Replication zu verwenden.

Was kann es?

Reliable DR ist vor allem ein Orchestrierungstool, mit dem das Disaster Recovery völlig automatisiert ausgeführt und getestet werden kann. Über ein Dashboard wählt man per Drag & Drop die virtuellen Maschinen aus und definiert die Boot-Reihenfolge für das Disaster Recovery. Die Recovery-Tests werden in einer Sandbox-Umgebung durchgeführt und beeinträchtigen nicht die Produktivsysteme. Die Testergebnisse sind sofort anhand eines Ampelsystems sichtbar: eine grüne Markierung zeigt an, dass der Test erfolgreich war. Gelb bedeutet, dass zwar die Wiederherstellung erfolgreich war, aber die gewünschten Zielvorgaben (RPO oder RTO) nicht eingehalten werden konnten. Rot signalisiert eine nicht geglückte Wiederherstellung. Da es letztendlich um die Wiederherstellung von Anwendungen und Services geht, überprüft Reliable DR die Disaster Recovery Pläne service- und anwendungsorientiert. Die Tests können so oft wie nötig – bis zu mehrmals täglich – und für beliebig viele virtuelle Maschinen durchgeführt werden. Die erfolgreich getesteten Wiederherstellungspunkte werden als  zertifizierte Wiederherstellungspunkte in der Datenbank gespeichert.  Umfangreiche Reporting Optionen unterstützen Compliance Anforderungen.

Reliable DR kann ebenfalls eingesetzt werden, um Anwendungen in ein anderes Rechenzentrum bzw. in die Cloud zu migrieren. Auch hier wird zunächst die Vollständigkeit und Wiederherstellbarkeit am neuen Standort überprüft. Anschließend werden die Anwendungen automatisiert am alten Produktivstandort heruntergefahren und am neuen Standort gestartet.

Anmerkung: PHD Virtual wurde im Dezember 2013 von Unitrends übernommen.

Fazit

Die Wahl des passenden Disaster Recovery Produkts ist abhängig von der Größe der zu schützenden Infrastruktur, der Bandbreite zum Recovery-Standort und vor allem von den Anforderungen hinsichtlich RPO und Wiederherstellungszeit. VMware vCenter Site Recovery Manager (SRM) ist vor allem für Unternehmen mit VMware Infrastrukturen in zwei oder mehr Rechenzentren geeignet. Für Firmen und Organisationen ohne eigenen Recovery-Standort in einem zweiten Rechenzentrum ist Zerto Virtual Replication eine interessante Alternative. Zerto kann gut mit einem geeigneten Cloud Service kombiniert werden und ermöglicht eine kontinuierliche Replikation mit RPOs im Sekunden- oder Minutenbereich ohne Performance-Einbußen. Weitere Vorteile sind die gute Skalierbarkeit und die Möglichkeit, Anwendungen mit mehreren VMs zu Konsistenzgruppen zusammenfassen zu können. Die Backup & Replication Produkte von Veeam und PHD Virtual richten sich eher an kleinere und mittlere Unternehmen, die das Backup für ihre virtuellen Maschinen mit einer Disaster Recovery Lösung verbinden wollen. Startfähige und regelmäßig aktualisierte Kopien der VMs werden in der Cloud gespeichert und können in einem Notfall entweder am Ersatzsandort gestartet oder zur Wiederherstellung der Maschinen am Produktivstandort genutzt werden.

Die wichtigsten Leistungsmerkmale im Überblick

 vCenter SRM mit vSphere ReplicationZerto Virtual ReplicationVeeam Backup & ReplicationPHD Virtual
Backup & Replication
PHD Virtual Reliable DR
Replikationstechnik„Lightweight Delta“ (LTW)I/O DatenstromImagebasiert (Snapshots)Imagebasiert (Snapshots)Imagebasiert (Snapshots)
Recovery Point Objectives (RPO)15 min – 24 hSekunden -MinutenZeitbedarf für das Erstellen & Löschen
der Snapshots
Zeitbedarf für das Erstellen, Löschen & Replizieren der SnapshotsMinuten
Point-in-Time WiederherstellungBegrenzte Anzahl Crash-konsistenter Wiederher-stellungspunkteBeliebiger Zeitpunkt sowie Crash- und anwendungs-konsistente Wiederher-stellungspunkteCrash- und Anwendungs-
konsistente
Wiederher-
stellungspunkte
letzte Sicherungabhängig von Replikations-
lösung
Storage-agnostischjajajajaja
Konsistenz über mehrere VMs hinwegneinjaneinneinnein
vApp Supportneinjajaneinja
Replica-Seeding jajajajaja
Replikation von mehreren Standorten auf einen zentralen Recovery-Standortjajajajaja
Datenkomprimierung jajajajanein
Deduplizierungneinneinneinjanein
Verschlüsselte DatenübertragungneinneinJajanein
Automatisierter Failback jajajaneinja
VMware vCenter to vCenter Replikationjajajajaja
VMware vCenter to vCloud Director Replikationneinjajaneinja
Automatisierte Failover Testsjajajaneinja
ManagementvSphere Center
Client Plug-In
vSphere Center
Client Plug-In, Web Interface
Veeam Backup
Enterprise
Manager Server
vSphere Center
Client Plug-In
Web Interface