Disaster-Recovery-Benchmark: Acronis vs Comet vs MSP360

Wir haben Acronis Cyber Protect Cloud, Comet Backup und MSP360 Managed Backup in Sachen Disaster Recovery bewertet. Jeder Anbieter erstellte ein Image eines Live-Windows-Server-2022 und eines Live-Ubuntu-24.04-Servers, auf denen dieselbe deterministische Workload lief: ein Webdienst, eine Datenbank mit 10.000 Zeilen und 50 Dateien. Anschließend wurde die gesamte Maschine auf einem separaten Server wiederhergestellt, nachdem ein Ransomware-artiger Disaster die Daten verschlüsselt hatte.

Ergebnisse des Disaster-Recovery-Benchmarks

Was jede Spalte bedeutet:

• Gewichtete Punktzahl: die Gesamtsumme der Rubrik über die sieben Dimensionen, als Referenz angegeben; der Benchmark bewertet jede Dimension für sich.
• Wiederherstellungszeit: die End-to-End-Wiederherstellungszeit (RTO), vom Auslösen des Failovers bis zur Antwort des wiederhergestellten Dienstes auf eine externe Prüfung.
• Failover-Erkennung: ob das Produkt ein Test-Failover ausführen und bestätigen kann, dass der wiederhergestellte Rechner gebootet hat – von einer automatisierten Screenshot-Prüfung bis hin zu gar keiner Prüfung.
• 3rd-Party-Integrationen: wie viele der sieben Wiederherstellungsziele (Anbieter-Cloud, AWS, Azure, Google Cloud, lokaler Hypervisor, regionenübergreifend, cloudübergreifend) das Produkt als Ziel nutzen kann.
• DR-Engine: ob das Produkt das Failover orchestriert (einen Recovery-Server und ein Runbook) oder lediglich ein Backup manuell wiederherstellt.

Siehe die vollständige Disaster-Recovery-Benchmark-Methodik für die Bewertungsrubrik und das T0-T6-Zeitprotokoll.

Die wichtigsten Erkenntnisse:

• Acronis stellte den verschlüsselten Server mit einem einzigen Runbook-Klick in 73 Sekunden unter Windows und in etwa 108 Sekunden unter Linux wieder her. Die Workload startete auf einem frischen Server in der Anbieter-Cloud, erhielt automatisch eine öffentliche IP und kam bytegenau sauber zurück.
• Comet und MSP360 haben keine Failover-Engine. Die Wiederherstellung ist eine manuelle Restore-to-VM, die mehrere zehn Minuten dauerte und bei jedem Schritt einen Bediener erforderte: Ziel bereitstellen, Disk-Image schreiben, Netzwerk neu konfigurieren, neu starten.
• Alle drei erzielten eine bytegenaue Wiederherstellung. Das 50-Dateien-SHA-256-Manifest und die Datenbankprüfsumme stimmten in jedem Fall mit der Baseline vor dem Disaster überein; der Unterschied liegt also in Geschwindigkeit und Bedieneraufwand, nicht in der Datenintegrität.

Benchmarkte Disaster-Recovery-Produkte

Acronis Cyber Protect Cloud

Acronis ist das einzige Produkt im Test mit einer Disaster-Recovery-as-a-Service-Failover-Engine. Es betreibt einen Recovery-Server in der Acronis-Cloud, führt ein Failover aus einem Runbook durch und validiert das Ergebnis mit einem automatisierten Test-Failover. Es erhält seine Punktzahl für Automatisierung, Wiederherstellungsgeschwindigkeit und Zielabdeckung; die größte Einschränkung ist das agentenbasierte Failback.

Failover-Automatisierungstiefe

Runbooks orchestrieren das Failover über geordnete Schritte, parallele Aktionen innerhalb eines Schritts, Abschlussprüfungen per Ping und Port, manuelle Genehmigungs-Gates und verschachtelte Runbooks. Das Compliance-Dashboard überwacht RPO-Ziele, geeignete Geräte und das Rechenpunkt-Kontingent. Kein anderes Produkt im Test kodifiziert die Wiederherstellung, statt sie einem Bediener zu überlassen.

Test-Failover-Fähigkeit

Das nicht-disruptive Test-Failover startet den Recovery-Server in einem isolierten Netzwerk, und Automated Test Failover validiert einen geplanten Boot mit einer KI-Screenshot-Prüfung. Es funktionierte in beide Richtungen und lieferte ein korrektes Fehlerurteil bei einem Linux-Server, der bei der Journal-Wiederherstellung hängen blieb, sowie einen korrekten Erfolg bei einem sauberen Windows-Boot.

End-to-End-RTO

73 Sekunden unter Windows, etwa 108 Sekunden unter Linux (94 und 121 in zwei Übungen). Ein Runbook-Klick startet den Recovery-Server, weist eine öffentliche IP zu und stellt die wiederhergestellte Anwendung bereit. Der wiederhergestellte Zustand war bytegenau im Vergleich zur Baseline vor dem Disaster.

RPO

Die Wiederherstellung verwendete ein Backup, das drei bis vier Minuten alt war, innerhalb des RPO-Compliance-Schwellenwerts. Der Schwellenwert ist von 15 Minuten bis 14 Tagen konfigurierbar.

Failback und Reprotect

Vierphasiges Delta-Failback (Planung, Datenübertragung, Umschaltung, Validierung), wobei der Cloud-Server während der Übertragung live bleibt. Für die Rückkehr zur ursprünglichen Hardware sind bootfähige Medien und ein manuelles Reprotect erforderlich.

Konnektivität und Netzwerkflexibilität

Der Cloud-only-Modus benötigt keine VPN-Appliance. Site-to-Site-OpenVPN, Multi-Site-IPsec, Point-to-Site-VPN, öffentliche IP pro Server und benutzerdefiniertes DNS sind alle verfügbar. Es gibt keine integrierte Umleitung von öffentlichen DNS-A-Records.

DR-Zielabdeckung

Sechs von sieben Zielen. Ein verwalteter DR-Standort in Acronis Cloud oder Azure, Instant Restore auf lokale VMware- und Hyper-V-Hosts, Wiederherstellung auf physisch unterschiedlicher Hardware sowie eine dokumentierte Restore-zu-EC2-Migration in das eigene AWS-Konto des Kunden. Das orchestrierte Failover selbst läuft in Acronis Cloud oder Azure, sodass EC2 per manueller Wiederherstellung und nicht per automatisiertem Failover erreicht wird. Nur für Google Compute Engine gibt es keinen dokumentierten Weg.

Eine Zuverlässigkeitsanmerkung ergab sich aus den Übungen. Die saubere, bytegenaue Wiederherstellung wurde zweimal nachgewiesen: in der ersten Übung (eine RTO von 94 Sekunden mit bestandener Integritätsprüfung) und im nicht-disruptiven Test-Failover. Die zweite Übung brachte zwei Stolpersteine bei Wiederherstellungspunkten zutage, die beide keine Fehler der Recovery-Engine waren. Ein Wiederherstellungspunkt, der erfasst wurde, während sich die Quelle mitten im Neustart befand, startete in einen hängenden Journal-Recovery-Zustand und musste wiederholt werden. Das Stoppen dieses Failovers setzte das Quell-Backup automatisch fort, wodurch die weiterhin verschlüsselte Quelle erfasst wurde; der zweite Versuch bootete daher pünktlich, landete aber auf diesem neueren verschlüsselten Punkt. Der Recovery-Server ist nicht besser als der Wiederherstellungspunkt dahinter; daher ist das Pausieren des Backups während eines Vorfalls und das Failover von einem bekanntermaßen sauberen Punkt die sicherere Reihenfolge.

Comet Backup

Comet ist ein Backup-Produkt ohne Disaster-Recovery-Engine. Es erzielte 0 Punkte bei Failover-Automatisierung und Test-Failover, weil es beides nicht besitzt, und holte seine Punkte über den manuellen Restore-to-VM-Weg und die Breite der Wiederherstellungsziele. Die Disk-Image-Wiederherstellung funktioniert. Im Benchmark brachte es einen von Ransomware betroffenen Ubuntu-Server auf einem frischen Host bytegenau und extern erreichbar zurück.

Failover-Automatisierungstiefe

Keine. Kein Recovery-Server, kein Runbook, kein One-Click-Failover. Die Wiederherstellung ist ein manueller End-to-End-Prozess. Comets eigener Disaster-Recovery-Leitfaden beschreibt kein Workload-Failover; er behandelt den Schutz der eigenen Comet-Konsole durch Replikation und die erneute Registrierung eines frischen Agents, nachdem ein Client-Gerät verloren ging.

Test-Failover-Fähigkeit

Keine. Der „Simulate restore only“-Modus des Wiederherstellungsassistenten ist ein Probelauf, der keine Maschine startet; daher gibt es kein zu bewertendes Test-Failover.

End-to-End-RTO

Das Schreiben des Disk-Images auf die Platte eines frischen Servers dauerte etwa zwei Minuten, aber der gesamte Ablauf (Rescue-Boot, Agent-Installation, Restore auf physisches Gerät, Netzwerk-Umschreibung, Neustart) dauerte 15 bis 25 Minuten. Der wiederhergestellte Server entsprach der Prüfsumme vor dem Disaster und stellte seine Anwendung unter einer neuen IP bereit.

RPO

Geplante Disk-Image-Backups mit inkrementellen Sicherungen, kein kontinuierlicher Datenschutz. Das erste Backup des Live-Root-Volumes füllte den differenziellen Speicher und erforderte, dass die Workload für ein sauberes Image stillgelegt wurde.

Failback und Reprotect

Failback ist dieselbe manuelle Wiederherstellung in umgekehrter Richtung, ohne Delta-Synchronisierung und ohne automatisches Reprotect.

Konnektivität und Netzwerkflexibilität

Keine DR-Netzwerkfunktionen. Die wiederhergestellte Maschine übernahm das MAC-basierte statische Netplan der Quelle, das wir manuell auf die Adresse des Wiederherstellungs-Hosts umschreiben mussten, bevor sie erreichbar war.

DR-Zielabdeckung

Nativ auf Bare-Metal, Hyper-V, VMware vSphere und Proxmox; AWS und Azure über VMDK- und VHDX-Export. Hier zeigte sich eine Einschränkung: Ein Restore-to-File-Image wird auf die volle Datenträgergröße aufgebläht, sodass die gleich große Quelldisk die Zwischendatei nicht aufnehmen kann, was den Bare-Metal-Wiederherstellungsweg erzwang.

MSP360 Managed Backup

MSP360 ist ein Backup-Produkt, dessen Disaster Recovery eine manuelle Restore-to-VM ist und dessen Wiederherstellung unter Windows, nicht unter Linux funktioniert. Unter Windows entsprach es der Wiederherstellungsklasse von Comet und startete einen wiederhergestellten Server auf separater Hardware. Die plattformübergreifende Punktzahl ist niedrig, weil der Linux-Agent keine Image-Backups erstellt; daher wird die Hälfte des Benchmarks (Linux-Wiederherstellung) mit null bewertet. Die folgenden Teilwerte gelten für Windows; die plattformübergreifende Gesamtwertung ergibt sich aus den Windows-Werten, gemittelt mit null für Linux.

Failover-Automatisierungstiefe

Keine Engine, kein Runbook, kein Recovery-Server. Die Begriffe „DRaaS“ und „Cloud DR“ auf den Produktseiten laufen auf eine manuelle Restore-to-VM hinaus.

Test-Failover-Fähigkeit

Die Funktion „Run Restore Verification“ startet das Image als Hyper-V-VM und prüft auf eine erfolgreiche Anmeldung – mehr als ein Probelauf –, benötigt aber lokales Hyper-V (auf den Cloud-Testhosts nicht vorhanden) und validiert ein Backup, statt auf einen Recovery-Standort überzugehen.

End-to-End-RTO

Wir stellten ein Full-Disk-Image mit GPT-zu-BIOS/MBR-Konvertierung wieder her, schrieben es auf einen separaten Cloud-Server, booteten Windows auf dem neuen Host und erreichten eine externe Health-Probe bytegenau sauber. Die Restore-Engine erzeugte das bootfähige Image in fünf bis sechs Minuten; der Rest bestand aus dem Verschieben des Images, dem Booten und einer manuellen Netzwerkkorrektur. End-to-End war die Bare-Metal-Restore-to-VM ein 15- bis 25-minütiger, mehrstufiger manueller Prozess, dieselbe Klasse wie Comets Linux-Wiederherstellung. Eine einfachere In-Place-Wiederherstellung nur der verschlüsselten Daten bei weiterhin laufendem Server dauerte etwa 10 Minuten.

RPO

Geplante Image-Backups mit inkrementellen Sicherungen per Changed Block Tracking, kein kontinuierlicher Datenschutz.

Failback und Reprotect

Manuelle vollständige Wiederherstellung zurück zur Quelle, keine Delta-Synchronisierung, kein automatisches Reprotect.

Konnektivität und Netzwerkflexibilität

Keine DR-Netzwerkfunktionen. Der wiederhergestellte Server startete mit der statischen IP der Quellmaschine und war nicht erreichbar, bis wir die korrekte Adresse über die Out-of-Band-Konsole festlegten.

DR-Zielabdeckung

Physischer Datenträger, Hyper-V, VMware vSphere und VirtualBox sowie alle drei Public Clouds über native Optionen des Wiederherstellungsassistenten: Restore zu Amazon EC2, Restore zu Azure VM und Restore zu Google Cloud Instance (Image-Export zu AWS VM Import ist der indirekte Fallback). Die native Google Cloud-Wiederherstellung macht MSP360 zum einzigen Produkt im Test, das Google Compute Engine erreicht; bei der reinen Zielanzahl liegt es damit gleichauf mit Acronis und vor Comet. Es fehlt lediglich die vom Anbieter verwaltete DR-Cloud, über die es gar nicht verfügt. Die GPT-zu-BIOS/MBR-Konvertierung, die den Bare-Metal-Restore auf einem BIOS-Host bootfähig machte, ist ein nützlicher Teil dieser Bandbreite.

Die Linux-Lücke ist die entscheidende Einschränkung. Der Linux-Agent von MSP360 erstellt nur dateibasierte Backups, kein Disk-Image; daher gibt es kein bootfähiges System-Image und keine Restore-to-VM unter Linux. Für einen MSP mit einer Linux-Flotte deckt die Disaster Recovery mit MSP360 nur die Hälfte des Bestands ab.

Funktionsvergleich

Failover und Orchestrierung

Drittanbieter-Integrationen und Wiederherstellungsziele

Die Wiederherstellungsreichweite ist bei den dreien ähnlich, setzt sich aber unterschiedlich zusammen. Acronis stellt in seine eigene Cloud, Azure, lokale VMware- und Hyper-V-Hosts sowie in ein AWS-EC2 des Kunden über eine dokumentierte Restore-zu-EC2-Migration wieder her; es fehlt nur Google Compute Engine. MSP360 verfügt über keine verwaltete Cloud, unterstützt aber alle drei Public Clouds nativ (sein Wiederherstellungsassistent bietet Restore zu EC2, Azure VM und Google Cloud Instance) und ist damit das einzige Produkt hier, das Google Compute Engine unterstützt.

Comet erreicht AWS und Azure, indem es eine VMDK oder VHDX exportiert und importiert, ohne verwaltete Cloud und ohne Google Cloud-Pfad. Acronis und MSP360 erreichen jeweils sechs von sieben Zieltypen, Comet fünf. Keines bietet eine integrierte Drittanbieter-DNS-Failover-Integration wie eine automatische Record-Umleitung im Stil von Cloudflare; Acronis bietet benutzerdefiniertes DNS und VPN-Modi, und bei den manuellen Produkten wird das Netzwerk der wiederhergestellten Maschine manuell konfiguriert.

Netzwerk und Failback

Erkenntnisse aus den Disaster-Recovery-Tests

Netzwerkneukonfiguration nach einer manuellen Wiederherstellung

Bei beiden manuellen Produkten startete der wiederhergestellte Server mit der statischen IP der Quellmaschine und nicht mit der des Wiederherstellungs-Hosts; er war im Netzwerk erst erreichbar, nachdem ein Bediener dies korrigierte. Die Adresse befindet sich innerhalb des Disk-Images und wandert daher mit der Wiederherstellung mit. Bei Comet (Linux) schrieben wir die Netplan-Konfiguration in der Rescue-Umgebung um; bei MSP360 (Windows) meldeten wir uns über die Cloud-Konsole am gestarteten Server an und legten die statische IP manuell fest. Ein DRaaS erledigt dies als Teil des Failovers; eine manuelle Wiederherstellung nicht.

Qualität der Wiederherstellungspunkte und Failover-Zuverlässigkeit

Die End-to-End-Business-RTO betrug in der ersten Linux-Failover-Übung 94 Sekunden, bei einem etwa 3 Minuten alten Wiederherstellungspunkt. Das Windows-Failover lieferte über zwei Läufe 73 Sekunden ohne Abweichung. Übung 1 und das nicht-disruptive Test-Failover bestanden jeweils eine bytegenaue T6-Integritätsprüfung, ohne dass Ransomware in das wiederhergestellte System gelangte.

Die beiden Punkte, die in der zweiten Linux-Übung auftraten, waren ein mitten im Neustart erfasster Wiederherstellungspunkt, der in einen hängenden Journal-Recovery-Zustand bootete, und ein automatisch fortgesetztes Quell-Backup, das einen weiterhin verschlüsselten Punkt in den zweiten Versuch einbrachte; beides waren Fehler des Wiederherstellungspunkts und des Betriebs, nicht der Recovery-Engine. Acronis Automated Test Failover erkannte denselben Journal-Recovery-Zustand unabhängig in einem nicht-disruptiven Test und lieferte ein Fehlerurteil – ein Validierungsschritt, der bei Comet und MSP360 fehlt, die im Test-Failover beide 0 Punkte erzielten.

UEFI-zu-BIOS-Konvertierung bei der Wiederherstellung

Der MSP360-Wiederherstellungs-Host bootete im BIOS-Modus, während die Quelle UEFI/GPT nutzte. Die MSP360-Wiederherstellung enthält eine Option „Convert GPT to BIOS/MBR“, die das Partitionslayout und die Boot-Konfiguration für das BIOS-Ziel neu aufbaut, sodass das wiederhergestellte Windows auf abweichender Firmware starten kann. Ohne diese Konvertierung wäre der Datenträger auf dem Wiederherstellungs-Host nicht bootfähig gewesen. Der Restore-to-File-Weg von Comet stieß auf eine andere mechanische Grenze: Das Image bläht sich auf die volle Datenträgergröße auf, sodass der Bare-Metal-zu-Zieldatenträger-Weg der einzige war, der passte.

Backup versus Disaster Recovery

Ein Backup ist eine Kopie von Daten, die wiederhergestellt werden kann. Disaster Recovery ist der orchestrierte Prozess, eine Workload auf anderer Infrastruktur wieder in Betrieb zu nehmen, nachdem das Original verloren ging – gemessen daran, wie schnell der Dienst zurückkehrt (RTO) und wie viele Daten verloren gehen (RPO).

Der Benchmark zeigt diese Lücke. Alle drei Produkte erzeugten ein korrektes Backup und eine bytegenaue Wiederherstellung. Eines der drei, Acronis, verwandelte dieses Backup mit einem Klick in 73 Sekunden in einen laufenden Dienst auf einem frischen Server. Die beiden anderen stellten dieselben Daten korrekt wieder her, überließen Failover, Boot und Netzwerk jedoch einem Menschen; deshalb dauerte ihre Wiederherstellung mehrere zehn Minuten und ihre Automatisierungsdimensionen wurden mit null bewertet. Ein Produkt kann ein ausgezeichnetes Backup-Tool sein und trotzdem kein Disaster-Recovery-Tool sein.

Was bedeutet Disaster-Recovery-as-a-Service (DRaaS)?

Disaster-Recovery-as-a-Service bedeutet, dass der Anbieter die Wiederherstellungsumgebung hostet und das Failover orchestriert, sodass der Kunde in eine verwaltete Infrastruktur wiederherstellt, ohne sie selbst aufzubauen. Acronis erfüllt diese Definition. Ein Recovery-Server bootet in seiner Cloud aus einem Runbook.

Comet, MSP360 und ähnliche Backup-Produkte verwenden auf ihren Marketingseiten Disaster-Recovery-Begriffe, MSP360 sogar „DRaaS“ und „Cloud DR“, um etwas anderes zu beschreiben: die manuelle Wiederherstellung eines Disk-Images auf einer virtuellen Maschine oder Cloud-Instanz, die der Kunde selbst bereitstellt und betreibt. Die Fähigkeit ist real und die Zielliste breit, aber die Orchestrierung übernimmt der Bediener. Ein Käufer, der „DRaaS“ liest, sollte prüfen, ob das Produkt eine Failover-Engine enthält (einen Recovery-Server, ein Runbook, ein Test-Failover) oder ob „DR“ nur die Wiederherstellungsfunktion des Backup-Produkts unter einem Marketing-Label ist.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Disaster-Recovery-Benchmark-Methodik

Der Benchmark misst Disaster Recovery und nicht den Backup-Durchsatz. Daher durchlief jedes Produkt denselben Wiederherstellungslebenszyklus: Agent installieren, ein sauberes Image eines Live-Servers erstellen, auf diesem Server einen Disaster auslösen, ihn auf einer separaten Maschine wiederherstellen und den wiederhergestellten Zustand gegen eine bekannte Baseline prüfen. Die Zeiten für Image-Backups werden als verstrichene Zeit angegeben, nicht als Durchsatz.

Testumgebung

Die Quellen waren zwei Cloud-Server, ein Windows Server 2022 und ein Ubuntu 24.04, jeweils eine Cloud-VPS mit einer 75-GB-Disk. Die Wiederherstellungsziele waren separate Cloud-Server derselben Klasse (und für Acronis die eigene Cloud des Anbieters).

Jede Quelle führte eine deterministische Workload aus, damit die Wiederherstellung Byte für Byte geprüft werden konnte. Die Workload bestand aus einem kleinen Webdienst, der /health mit HTTP 200 beantwortete, einer Datenbanktabelle mit 10.000 Zeilen mit bekannter fester Prüfsumme, 50 deterministischen Dateien und einem SHA-256-Baseline-Manifest aller Dateien. Da die Workload bei jedem Lauf identisch ist, ist die Frage, ob der exakte Zustand vor dem Disaster zurückgekehrt ist, eine Ja/Nein-Prüfung und keine Ermessensentscheidung.

Disaster- und Wiederherstellungsprotokoll

Der Disaster war eine kontrollierte, reversible Ransomware-Simulation, keine echte Malware. Bei T0 base64-kodierte er die Workload-Dateien in Der Disaster war eine kontrollierte, reversible Ransomware-Simulation, keine echte Malware. Bei T0 base64-kodierte er die Workload-Dateien in .locked-Kopien und löschte die Originale, überschrieb jede Datenbankzeile mit einem ENCRYPTED_BY_RANSOMWARE_SIM-Marker und hinterlegte eine Lösegeldforderung. Das Betriebssystem blieb absichtlich aktiv, und die Daten wurden beschädigt, sodass die Wiederherstellung vom Wiederherstellungspunkt des Anbieters und nicht von einem abgestürzten Host aus gesteuert werden konnte.

Die Wiederherstellung folgte einem festen Zeitstempel-Protokoll:

• T0, Disaster ausgerufen (hier beginnt die Zeitmessung).
• T1, der Bediener löst das Failover aus (ein Runbook-Klick bei Acronis, die erste manuelle Wiederherstellungsaktion bei den anderen).
• T3, die wiederhergestellte VM erreicht den Login.
• T4, die Anwendung antwortet (Port offen, Health 200).
• T5, der wiederhergestellte Dienst ist von einem externen Client erreichbar; dies ist die geschäftliche Haupt-RTO: RTO = T5 – T1.
• T6, die Datenintegrität wird bestätigt, indem das SHA-256-Manifest und die Datenbankprüfsumme gegen die Baseline neu berechnet werden und bestätigt wird, dass keine .locked-Dateien oder Lösegeldforderungen verbleiben.

Die Zeiten stammen aus zwei Quellen, nicht aus einer Stoppuhr. Die Anbieterkonsole liefert T1 bis T4 (das Aktivitäten- oder Jobprotokoll), und eine externe Prüfung von einer separaten Maschine liefert T5.

Die Wiederherstellungszeiten werden bewusst mit unterschiedlicher Genauigkeit angegeben. Acronis stellt mit einer einzigen automatisierten Runbook-Aktion wieder her, sodass die End-to-End-Zeit ein sauberes, wiederholbares Fenster ist; es absolvierte zwei aufeinanderfolgende Failover-Übungen, und die Tabelle gibt den Durchschnitt an. Die manuellen Restore-to-VM-Wiederherstellungen (Comet und MSP360) sind mehrstufige Abläufe, bei denen der Bediener ein Ziel bereitstellt, das Image wiederherstellt und das Netzwerk manuell neu konfiguriert; daher hängt die End-to-End-Zeit vom Bediener ab und wird als Bereich statt als Einzelwert angegeben. Die rein maschinellen Teile dieser Wiederherstellungen sind präzise (das Disk-Image-Schreiben bei Comet dauerte etwa zwei Minuten, und die MSP360-Restore-Engine erzeugte das bootfähige Image in fünf bis sechs Minuten), aber der gesamte Ablauf ist vom Bediener abhängig.

Bewertungsmethodik

Sieben Dimensionen werden von 0 bis 100 bewertet und gewichtet. Die Failover-Automatisierungstiefe macht 20 % aus, die Test-Failover-Fähigkeit 10 %, die End-to-End-RTO 20 %, die RPO 10 %, Failback und Reprotect 10 %, Konnektivität und Netzwerkflexibilität 10 % und die DR-Zielabdeckung 20 %. Jede Dimension wird separat ausgewiesen; die gewichtete Gesamtsumme ist eine Informationsangabe, auf die nächsten zehn gerundet.

Windows und Linux werden als separate Teilwerte bewertet und gemittelt. Ein Produkt, das Disaster Recovery auf einem Betriebssystem nicht unterstützt, erhält für diesen Teilwert null; die Lücke wird als Befund ausgewiesen und nicht leer gelassen, weshalb die nur unter Windows funktionierende Wiederherstellung von MSP360 im Durchschnitt etwa der Hälfte ihres Windows-Teilwerts entspricht.

Fähigkeiten, die ein Produkt nicht besitzt, werden anhand des Fehlens bewertet und als Befund ausgewiesen (zum Beispiel setzt das Fehlen einer Failover-Engine bei Comet und MSP360 deren Automatisierungs- und Test-Failover-Dimensionen auf null). „Anhand des Fehlens“ bedeutet, dass die Funktion nicht existiert, bestätigt am Produkt, und nicht, dass eine Dimension ungetestet blieb.

Kategorie-Punktzahlen

Die Punktzahlen sind der Durchschnitt der Windows- und Linux-Teilwerte. Acronis und Comet unterstützen Disaster Recovery auf beiden Betriebssystemen, daher entspricht ihr Durchschnitt ihrem Wert pro Betriebssystem. MSP360 unterstützt imagebasierte Wiederherstellung unter Windows, nicht unter Linux; daher ist sein Linux-Teilwert 0 und jede Dimension wird halbiert.

Der Abstand zwischen Acronis und den beiden anderen konzentriert sich auf drei Dimensionen: Failover-Automatisierung (DR1), Test-Failover (DR2) und Konnektivität (DR6). Das sind die Dimensionen, die eine echte DRaaS-Engine bietet und ein Backup-Produkt nicht. Allein diese drei Spalten machen 38 Punkte des Vorsprungs von Acronis gegenüber Comet aus.

Die Zielabdeckung ist nicht der Punkt, an dem sich die Produkte trennen. Acronis und MSP360 erreichen jeweils sechs von sieben Zieltypen, Comet fünf, aber die Mengen unterscheiden sich: Acronis bietet seine verwaltete Cloud, AWS EC2 (dokumentierte Restore-zu-EC2-Migration), Azure, lokale Hypervisoren, regionenübergreifend und cloudübergreifend; es fehlt nur Google Compute Engine. MSP360 hat keine verwaltete Cloud, erreicht aber alle drei Public Clouds nativ – AWS, Azure und Google Compute Engine – sowie lokale Hypervisoren. Das bei der Automatisierung schwächste Produkt entspricht damit bei der reinen Zielabdeckung dem stärksten, und genau darum geht es: Der entscheidende Unterschied im Benchmark ist Automatisierung, nicht Breite.

Die halbierte Spalte von MSP360 ist ein Artefakt der Betriebssystemabdeckung und nicht einer schwächeren Windows-Wiederherstellung. Allein unter Windows erreicht MSP360 bei der End-to-End-RTO denselben Wert 70 wie Comet unter Linux, weil beide dieselbe Klasse manueller Restore-to-VM ausführen. Der plattformübergreifende Durchschnitt sinkt auf 21, weil MSP360 unter Linux überhaupt keine imagebasierte Wiederherstellung durchführen kann.

Einschränkungen und Umfang

Die Disaster-Recovery-Seite wurde auf Cloud-VMs ohne verschachtelte Virtualisierung getestet; daher wurde jede Funktion, die einen lokalen Hypervisor benötigt (z. B. die Hyper-V-Restore-Überprüfung von MSP360, lokale Replikationsziele), anhand der Dokumentation und der Produkt-UI bewertet und nicht praktisch ausgeführt. Die Dimension Konnektivität wurde im Cloud-only-Modus praktisch getestet; die VPN- und IPsec-Modi wurden anhand von Konsole und Dokumentation bewertet.

Weiterführende Literatur

• Backup-Software-Benchmark: Acronis vs NinjaOne vs Comet vs MSP360
• Top 7 SaaS-Backup-Lösungen
• Google Workspace-Backup: NinjaOne vs Acronis vs CloudAlly

Diese Forschung zitieren

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Disaster-Recovery-Benchmark: Acronis vs Comet vs MSP360}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Abgerufen am 4. August 2026}
}

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenwissenschaftler bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten