Disaster Recoveryund Recovery Testing.

Replikation von Azure-VMs zwischen Regionen sowie von On-Premises-VMware- und Hyper-V-VMs und physischen Windows- und Linux-Servern nach Azure.

Kontinuierliche Replikation für Azure-VMs und VMware-VMs; Failover und Failback werden im Azure-Portal gesteuert.

Recovery Plans gruppieren VMs, legen die Startreihenfolge mehrstufiger Anwendungen fest und lassen sich um Skripte, manuelle Schritte und Azure-Automation-Runbooks ergänzen.

Testfailover (DR-Drill) laufen laut Microsoft ohne Einfluss auf laufende Replikation und Produktion; empfohlen wird ein vom Produktionsnetz isoliertes Testnetz.

Replikation, Recovery Plans und Testfailover für hybride Workloads sind ohne eigenes Ausweichrechenzentrum aus einem Dienst nutzbar.

Ziel ist Azure; ein eigener RPO/RTO-Testnachweis als Bericht ist auf den abgerufenen Seiten nicht beschrieben, die Funktion für Azure Extended Zones ist laut Microsoft in Vorschau.

Wiederherstellung von On-Premises-Servern, cloud-basierten Servern und AWS-Workloads in eine gewählte AWS-Region.

Blockbasierte Replikation in einen kostengünstigen Staging-Bereich; AWS nennt RPO im Sekunden- und RTO im Minutenbereich sowie Point-in-Time-Recovery.

Launch-Einstellungen lassen sich gesammelt verwalten; Post-Launch-Actions führen nach dem Start automatisch Schritte wie Konfiguration oder Monitoring-Aktivierung aus.

Nicht-disruptive Recovery- und Failback-Drills sind vorgesehen; nach der Wiederherstellung kann die Replikation zurück an den Primärstandort laufen.

Geringe Standby-Kosten durch Staging-Bereich und Drills ohne Eingriff in die Produktion.

Ziel ist ausschliesslich AWS; eine Recovery-Plan-Orchestrierung über mehrere Anwendungen hinweg ist auf den abgerufenen Seiten nicht beschrieben, Abhängigkeiten sind selbst zu modellieren.

Disaster Recovery für virtuelle Maschinen auf vSphere über gepaarte Standorte mit Protection Groups und Recovery Plans.

Recovery Plans laufen als Test Recovery, Planned Migration oder Disaster Recovery; bei Array-Replikation über Storage Replication Adapter (SRA).

Netzwerk-Mappings und IP-Anpassungsregeln für den Zielstandort werden im Recovery Plan hinterlegt.

Nach einem Failover stellt der Reprotect-Workflow die Schutzrichtung um und bereitet die Rückführung vor.

Recovery Plans mit Testmodus sind eng in vSphere integriert.

Nur für VMware-Umgebungen; Produkt- und Lizenzseite im Abruf nicht auswertbar, Replikationsarten und Cloud-Ziele daher nur aus Broadcom-Knowledge-Base und nicht als Matrixwert belegt; Lizenzmodell seit der Übernahme durch Broadcom geändert prüfen.

Auto Recovery für hybride Workloads; Cloud Rewind für die Wiederherstellung kompletter Anwendungen in AWS, Azure und Google Cloud.

Kontinuierliche und periodische Replikation von Sicherungen und Snapshots zu Recovery-Sites; Commvault nennt RPO unter einer Minute und Hot- und Warm-Site-Optionen.

Recovery-Orchestrierung mit Pre- und Post-Skripten, etwa für Malware-Scans mit Drittwerkzeugen.

Wiederherstellungstests in isolierten Umgebungen; Cloud Rewind nennt audit-taugliche Berichte für regulatorische Anforderungen.

Deckt On-Premises-Replikation und Cloud-Anwendungswiederherstellung in einer Plattform ab.

Zwei getrennte Funktionsbereiche mit eigener Lizenzierung; Failback ist auf den abgerufenen Seiten nicht ausdrücklich beschrieben.

DR für Workloads auf der Nutanix Cloud Infrastructure, wahlweise zwischen eigenen Standorten, in die Public Cloud oder über Partner.

Replikation als Sync, NearSync oder Async mit RPO von 0 Minuten bis 24 Stunden; AHV Metro für RPO 0 bei kritischen Anwendungen.

Recovery Plans und Protection Plans über eine zentrale Verwaltung; granulare Failover einzelner Entitäten.

Nicht-disruptive, granulare Testfailover zur Validierung des DR-Plans; Failover und Failback werden orchestriert.

Replikationsarten von synchron bis asynchron mit integrierten Recovery Plans und Testfailover.

An die Nutanix-Plattform gebunden; Test- und RPO-Berichte sind auf der Produktseite nicht beschrieben.

Schutz und Wiederherstellung für VMware, Microsoft Hyper-V, Microsoft Azure und AWS.

Continuous Data Protection repliziert Änderungen in Echtzeit; journalbasierte Wiederherstellung auf einen Zeitpunkt kurz vor einem Angriff, Datenverlust laut HPE im Sekundenbereich.

Automatisierung und Orchestrierung für Wiederherstellung und Migration; Reporting und Analytics werden im Zusammenhang mit Ransomware-Funktionen genannt.

Recovery-Tests sind laut HPE nicht-disruptiv.

Journalbasierte CDP mit sehr kurzen Wiederherstellungspunkten über mehrere Hypervisoren und Clouds.

Failback und konkrete RPO/RTO-Testberichte sind auf der abgerufenen HPE-Seite nicht beschrieben; HPE-Website im Direktabruf gesperrt, Inhalt nur über Abrufwerkzeug ausgewertet.

Orchestrierte Wiederherstellung nach VMware vSphere, Microsoft Hyper-V, Azure Local und Microsoft Azure sowie Storage-Failover für NetApp und HPE.

Replica Plans und CDP Replica Plans mit Failover und Failback, Restore Plans aus Sicherungen sowie Wiederherstellung in Clean-Room-Recovery-Locations.

DataLabs für isolierte Tests; Berichte lassen sich abonnieren und mit Aufbewahrungsfristen versehen.

Veeam Data Platform nennt DR-Tests mit audit-tauglichem Reporting; Orchestrierung ist Premium-Funktion.

Verbindet Replikation, Restore aus Sicherungen und Testnachweise in einem Orchestrierungswerkzeug.

Setzt eine Veeam-Backup-&-Replication-Umgebung voraus und ist Teil der höchsten Edition; Cloud-Ziel laut Dokumentation Azure.

Hochverfügbarkeit und DR für Windows- und Linux-Systeme auf physischer, virtueller und Cloud-Infrastruktur, auch über gemischte Hypervisoren.

Asynchrone Replikation auf Byte-Ebene in Echtzeit; Heartbeat-Überwachung löst automatisches Failover aus und passt DNS-Einträge an.

Bandbreitenbegrenzung, Kompression und Verschlüsselung der Replikation; unterstützt Cloud-Migrationen.

Prüfung der DR-Bereitschaft durch nicht-disruptive, offline durchgeführte Testläufe; Failover und Failback automatisiert.

Serverbezogene Echtzeitreplikation mit automatischem Failover, unabhängig vom Hypervisor.

Ansatz pro Server ohne beschriebene anwendungsübergreifende Recovery Plans; Nachweisberichte zu RPO/RTO auf der Produktseite nicht genannt.

Windows- und Linux-Server, physisch, virtuell und in der Cloud, einschliesslich VMware vSphere und Microsoft Hyper-V; Failover in die Acronis Cloud, für MSP auch nach Azure.

Basis sind imagebasierte Sicherungen in der Acronis Cloud; RPO-Schwellen lassen sich festlegen und überwachen.

Runbooks mit geordneten und parallelen Schritten sowie Abschlussprüfungen bringen abhängige Systeme in Reihenfolge online.

Testfailover in isolierter Umgebung, automatisierte Boot-Prüfungen per Screenshot-Analyse mit Ergebnisbericht; inkrementelles Failback. Acronis hat seinen Hauptsitz in Schaffhausen.

DR als Dienst mit Runbooks, geplanten Tests und Failback ohne eigenes Zweitrechenzentrum, auch für KMU und MSP.

Wiederherstellung basiert auf Sicherungen statt kontinuierlicher Replikation, das erreichbare RPO hängt vom Sicherungsintervall ab; Datenstandort des Acronis-Rechenzentrums je Region prüfen.

Disaster Recovery für zustandsbehaftete Kubernetes-Anwendungen.

Synchrone DR mit RPO 0 für Cluster in derselben Metro-Region, asynchrone DR mit begrenztem Datenverlust über grössere Distanzen.

Teil der Portworx-Plattform mit Portworx Enterprise (Storage) und Portworx Backup; Ökosystem nennt Red Hat OpenShift, SUSE, Amazon EKS, Azure AKS und Google Kubernetes Engine.

Schnelle Failover zwischen Clustern; die Produktseite weist den Anbieter als «Portworx by Everpure» aus.

Synchrone Replikation mit RPO 0 auf Ebene der Kubernetes-Anwendung.

Nur für Kubernetes, DR setzt Portworx-Storage voraus; Testfailover, Failback und Berichte sind auf der Produktseite nicht beschrieben.

Verteilter, replizierter Blockspeicher für Linux, eingesetzt für Hochverfügbarkeit und standortübergreifende DR.

Der DRBD-Kerneltreiber spiegelt Schreibvorgänge auf einen oder mehrere Peers, laut DRBD-Benutzerhandbuch asynchron (Protokoll A), semi-synchron (B) oder synchron (C); DRBD Proxy puffert und komprimiert für WAN-Strecken.

Mehrere Pfade für Bandbreitenbündelung und Link-Failover; LINBIT führt DRBD Reactor und LINBIT HA als ergänzende Produkte für Hochverfügbarkeit.

LINBIT hat seinen Hauptsitz in Wien; DRBD entstand an der TU Wien.

Offene, hypervisorunabhängige Replikationsschicht auf Blockebene mit synchronem Modus.

Replikationsbaustein ohne eigene DR-Runbooks, Testfailover oder Nachweisberichte; Orchestrierung und Tests müssen selbst aufgebaut werden; Lizenz (GPL) nur aus Sekundärwissen, im Abruf nicht belegt.