Disaster-Recovery-Benchmark: Acronis vs Comet vs MSP360
Wir haben Acronis Cyber Protect Cloud, Comet Backup und MSP360 Managed Backup im Bereich Disaster Recovery getestet. Jeder Anbieter erstellte ein Image eines laufenden Windows Server 2022 und eines laufenden Ubuntu-24.04-Servers mit derselben deterministischen Workload – einem Webservice, einer Datenbank mit 10.000 Zeilen und 50 Dateien – und stellte anschließend die gesamte Maschine auf einem separaten Server wieder her, nachdem ein Ransomware-artiger Vorfall die Daten verschlüsselt hatte.
Ergebnisse des Disaster-Recovery-Benchmarks
Produkt | Gewichtete Punktzahl | Wiederherstellungszeit | Failover-Erkennung | 3rd-Party-Integrationen | DR-Engine |
|---|---|---|---|---|---|
90 | 73 Sek. (Windows) / 108 Sek. (Linux) | Automatisiert (KI-Screenshot) | 6 von 7 Zielen | ✓ | |
Comet | 40 | ~15–25 Min. (Linux) | Keine | 5 von 7 Zielen | ✗ |
MSP360 | 20 | ~15–25 Min. (Windows) | Hyper-V-abhängig | 6 von 7 Zielen | ✗ |
Was jede Spalte bedeutet:
- Gewichtete Punktzahl: die Gesamtbewertung über die sieben Dimensionen, als Referenz angegeben; der Benchmark bewertet jede Dimension für sich.
- Wiederherstellungszeit: die End-to-End-Wiederherstellungszeit (RTO), vom Ausrufen des Failovers bis zum Antworten des wiederhergestellten Dienstes auf einen externen Prüfaufruf.
- Failover-Erkennung: ob das Produkt einen Test-Failover ausführen und bestätigen kann, dass die wiederhergestellte Maschine gestartet wurde – von einer automatisierten Screenshot-Prüfung bis hin zu gar keiner Prüfung.
- 3rd-Party-Integrationen: wie viele von sieben Wiederherstellungszielen (Anbieter-Cloud, AWS, Azure, Google Cloud, lokaler Hypervisor, regionenübergreifend, cloudübergreifend) das Produkt wiederherstellen kann.
- DR-Engine: ob das Produkt das Failover orchestriert (mit Wiederherstellungsserver und Runbook) oder lediglich ein Backup manuell wiederherstellt.
Siehe die vollständige Disaster-Recovery-Benchmark-Methodik für das Bewertungsraster und das Zeitprotokoll T0-T6.
Die wichtigsten Erkenntnisse:
- Acronis hat den verschlüsselten Server mit einem einzigen Runbook-Klick in 73 Sekunden unter Windows und in etwa 108 Sekunden unter Linux wiederhergestellt. Die Workload startete auf einem frischen Server in der Anbieter-Cloud, erhielt automatisch eine öffentliche IP und kam byte-exakt sauber zurück.
- Comet und MSP360 haben keine Failover-Engine. Die Wiederherstellung ist ein manuelles Restore-to-VM, das mehrere zehn Minuten dauerte und bei jedem Schritt einen Bediener erforderte: ein Ziel bereitstellen, das Disk-Image schreiben, das Netzwerk neu konfigurieren, neu starten.
- Alle drei erzeugten eine byte-exakte Wiederherstellung. Das Manifest für 50 Dateien (SHA-256) und die Datenbankprüfsumme stimmten in jedem Fall mit der Baseline vor dem Vorfall überein; der Unterschied liegt also bei Geschwindigkeit und Bedienaufwand, nicht bei der Datenintegrität.
Getestete 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 Wiederherstellungsserver in der Acronis-Cloud, führt Failover über ein Runbook durch und validiert das Ergebnis mit automatisiertem Test-Failover. Seine Punktzahl erzielt es bei Automatisierung, Wiederherstellungsgeschwindigkeit und Zielabdeckung; die größte Einschränkung ist das agentenbasierte Failback.
Automatisierungstiefe des Failovers
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 verfolgt RPO-Ziele, geeignete Geräte und das Compute-Punkte-Kontingent. Kein anderes Produkt im Test kodifiziert die Wiederherstellung, statt sie einem Bediener zu überlassen.
Test-Failover-Fähigkeit
Der nicht disruptive Test-Failover startet den Wiederherstellungsserver in einem isolierten Netz, und der automatisierte Test-Failover validiert einen geplanten Start mit einer KI-Screenshot-Prüfung. Dies funktionierte in beide Richtungen: ein echtes Fehlerurteil bei einem Linux-Server, der in der Journal-Wiederherstellung hing, und ein echter Erfolg bei einem sauberen Windows-Start.
End-to-End-RTO
73 Sekunden unter Windows, etwa 108 Sekunden unter Linux (94 und 121 über zwei Übungen). Ein Runbook-Klick startet den Wiederherstellungsserver, weist eine öffentliche IP zu und stellt die wiederhergestellte Anwendung bereit. Der wiederhergestellte Zustand war byte-exakt gegenüber der Baseline vor dem Vorfall.
RPO
Für die Wiederherstellung wurde ein drei bis vier Minuten altes Backup verwendet, innerhalb der RPO-Compliance-Schwelle. Die Schwelle ist von 15 Minuten bis 14 Tage konfigurierbar.
Failback und Reprotect
Vierphasiges Delta-Failback (Planung, Datentransfer, Umschaltung, Validierung), wobei der Cloud-Server während des Transfers aktiv bleibt. Für die Rückkehr auf die ursprüngliche 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, eine öffentliche IP pro Server und benutzerdefiniertes DNS sind alle verfügbar. Es gibt keine integrierte Umleitung des öffentlichen DNS-A-Records.
DR-Zielabdeckung
Sechs von sieben Zielen. Eine verwaltete DR-Site in der Acronis-Cloud oder in Azure, Instant Restore auf lokales VMware und Hyper-V, Wiederherstellung auf abweichende physische Hardware sowie eine dokumentierte Restore-to-EC2-Migration in das eigene AWS-Konto des Kunden. Das orchestrierte Failover selbst läuft in der Acronis-Cloud oder in Azure, sodass EC2 per manueller Wiederherstellung statt per automatisiertem Failover erreicht wird. Nur für Google Compute Engine gibt es keinen dokumentierten Weg.
Aus den Übungen ergab sich ein Zuverlässigkeitshinweis. Die saubere, byte-exakte Wiederherstellung wurde zweimal nachgewiesen: in der ersten Übung (ein RTO von 94 Sekunden mit bestandener Integritätsprüfung) und im nicht disruptiven Test-Failover. Die zweite Übung brachte zwei Probleme mit Wiederherstellungspunkten ans Licht, die beide nicht auf die Wiederherstellungs-Engine zurückzuführen sind. Ein Punkt, der mitten im Reset des Quellsystems erfasst wurde, startete in einen hängenden Journal-Recovery-Zustand und musste wiederholt werden. Das Stoppen dieses Failovers führte dazu, dass das Quell-Backup automatisch fortgesetzt wurde, das die noch verschlüsselte Quelle erfasste, sodass die Wiederholung pünktlich startete, aber auf diesem neueren verschlüsselten Punkt landete. Der Wiederherstellungsserver ist nicht besser als der Wiederherstellungspunkt dahinter; daher ist es die sicherere Reihenfolge, das Backup während eines Vorfalls zu pausieren und von einem bekanntermaßen sauberen Punkt aus das Failover durchzuführen.
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 sammelte Punkte beim manuellen Restore-to-VM-Weg und bei der Breite der Wiederherstellungsziele. Seine Disk-Image-Wiederherstellung funktioniert. Im Benchmark brachte es einen von Ransomware betroffenen Ubuntu-Server byte-exakt und extern erreichbar auf einem frischen Host zurück.
Automatisierungstiefe des Failovers
Keine. Kein Wiederherstellungsserver, kein Runbook, kein One-Click-Failover. Die Wiederherstellung ist ein manuelles End-to-End-Verfahren. Der Disaster-Recovery-Leitfaden von Comet selbst beschreibt kein Workload-Failover; er behandelt den Schutz der eigenen Comet-Konsole durch Replikation und die erneute Registrierung eines frischen Agents nach dem Verlust eines Clientgeräts.
Test-Failover-Fähigkeit
Keine. Die Option „Nur Wiederherstellung simulieren“ des Restore-Assistenten ist ein Probelauf, der keine Maschine startet; daher gibt es keinen bewertbaren Test-Failover.
End-to-End-RTO
Das Schreiben des Disk-Images auf die Festplatte eines frischen Servers dauerte etwa zwei Minuten, aber das vollständige Verfahren (Rescue-Boot, Agent-Installation, Restore auf physisches Gerät, Netzwerk-Umschreiben, Neustart) dauerte 15 bis 25 Minuten. Der wiederhergestellte Server stimmte mit der Prüfsumme vor dem Vorfall überein und stellte seine Anwendung unter einer neuen IP bereit.
RPO
Geplante Disk-Image-Backups mit Inkrementen, kein kontinuierlicher Datenschutz. Das erste Backup des live genutzten 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 automatisiertes Reprotect.
Konnektivität und Netzwerkflexibilität
Keine DR-Netzwerkfunktionen. Die wiederhergestellte Maschine übernahm das statische Netplan der Quelle mit übereinstimmender MAC; wir schrieben es manuell auf die Adresse des Wiederherstellungshosts um, bevor sie erreichbar wurde.
DR-Zielabdeckung
nativ Bare Metal, Hyper-V, VMware vSphere und Proxmox; AWS und Azure über VMDK- und VHDX-Export. Eine Einschränkung zeigte sich: Ein Restore-to-File-Image wird auf die volle Datenträgergröße aufgebläht, sodass die gleich große Quell-Festplatte die Zwischendatei nicht aufnehmen kann, was den Bare-Metal-Wiederherstellungspfad erzwang.
MSP360 Managed Backup
MSP360 ist ein Backup-Produkt, dessen Disaster Recovery ein manuelles 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 betriebssystemübergreifende Punktzahl ist niedrig, weil der Linux-Agent kein Image-Backup besitzt, sodass die Hälfte des Benchmarks (Linux-Wiederherstellung) null Punkte erhält. Die folgenden Teilwerte gelten für Windows; die betriebssystemübergreifende Gesamtsumme ist der Windows-Wert gemittelt mit null für Linux.
Automatisierungstiefe des Failovers
Keine Engine, kein Runbook, kein Wiederherstellungsserver. Die Begriffe „DRaaS“ und „Cloud DR“ auf den Produktseiten laufen auf ein manuelles Restore-to-VM hinaus.
Test-Failover-Fähigkeit
Die Funktion „Run Restore Verification“ startet das Image als Hyper-V-VM und prüft eine erfolgreiche Anmeldung; das ist mehr als ein Probelauf, benötigt jedoch lokales Hyper-V (auf den Cloud-Testhosts nicht vorhanden) und validiert ein Backup, statt zu einer Wiederherstellungssite zu failovern.
End-to-End-RTO
Wir stellten ein Full-Disk-Image mit GPT-to-BIOS/MBR-Konvertierung wieder her, schrieben es auf einen separaten Cloud-Server, starteten Windows auf dem neuen Host und erreichten eine externe Health-Probe byte-exakt sauber. Die Restore-Engine erzeugte das bootfähige Image in fünf bis sechs Minuten; der Rest war das Verschieben des Images, das Booten und eine manuelle Netzwerkkorrektur. End-to-End war das Bare-Metal-Restore-to-VM ein mehrstufiges manuelles Verfahren von 15 bis 25 Minuten, 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 Inkrementen per Changed Block Tracking, kein kontinuierlicher Datenschutz.
Failback und Reprotect
Manuelle vollständige Wiederherstellung zurück zur Quelle, keine Delta-Synchronisierung, kein automatisiertes 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 setzten.
DR-Zielabdeckung
Physische Festplatte, Hyper-V, VMware vSphere und VirtualBox sowie alle drei Public Clouds über native Optionen des Wiederherstellungsassistenten: Restore to Amazon EC2, Restore to Azure VM und Restore to Google Cloud Instance (Image-Export zu AWS VM Import ist der indirekte Ausweichweg). 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 ihm lediglich die vom Anbieter verwaltete DR-Cloud, über die es gar nicht verfügt. Die GPT-to-BIOS/MBR-Konvertierung, die das Bare-Metal-Restore auf einem BIOS-Host bootfähig machte, ist ein nützlicher Teil dieser Breite.
Die Linux-Lücke ist die entscheidende Einschränkung. Der Linux-Agent von MSP360 führt nur dateibasiertes Backup ohne Disk-Image durch, daher gibt es kein bootfähiges Systemabbild und kein 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
Integrationen von Drittanbietern und Wiederherstellungsziele
Die Wiederherstellungsreichweite der drei Produkte ist ähnlich, aber unterschiedlich zusammengesetzt. Acronis stellt in die eigene Cloud, nach Azure, auf lokale VMware- und Hyper-V-Hosts sowie in die AWS-EC2-Umgebung eines Kunden über eine dokumentierte Restore-to-EC2-Migration wieder her; es fehlt nur Google Compute Engine. MSP360 hat keine verwaltete Cloud, unterstützt aber alle drei Public Clouds nativ (der Wiederherstellungsassistent bietet Restore to 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 der Produkte verfügt über eine integrierte DNS-Failover-Integration von Drittanbietern, etwa eine automatische Record-Umleitung nach Cloudflare-Art; Acronis bietet benutzerdefiniertes DNS und VPN-Modi, und bei den manuellen Produkten wird das Netzwerk der wiederhergestellten Maschine von Hand konfiguriert.
Netzwerk und Failback
Erkenntnisse aus den Disaster-Recovery-Tests
Netzwerk-Neukonfiguration nach einer manuellen Wiederherstellung
Bei beiden manuellen Produkten startete der wiederhergestellte Server mit der statischen IP der Quellmaschine, nicht mit der des Wiederherstellungshosts, und war im Netzwerk nicht erreichbar, bis ein Bediener dies behob. Die Adresse befindet sich im Disk-Image 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 setzten die statische IP von Hand. Ein DRaaS erledigt dies als Teil des Failovers; eine manuelle Wiederherstellung tut es nicht.
Qualität der Wiederherstellungspunkte und Failover-Zuverlässigkeit
Die End-to-End-Geschäfts-RTO betrug in der ersten Linux-Failover-Übung 94 Sekunden, bei einem etwa 3 Minuten alten Wiederherstellungspunkt. Das Windows-Failover ergab über zwei Läufe 73 Sekunden ohne Abweichung. Übung 1 und der nicht disruptive Test-Failover bestanden jeweils eine byte-exakte T6-Integritätsprüfung, ohne dass Ransomware in das wiederhergestellte System gelangte.
Die zwei Punkte, die in der zweiten Linux-Übung auftauchten, waren ein mitten im Reset erfasster Wiederherstellungspunkt, der in einen Journal-Recovery-Hänger startete, und ein automatisch fortgesetztes Quell-Backup, das einen weiterhin verschlüsselten Punkt in die Wiederholung brachte; beides waren Probleme des Wiederherstellungspunkts und des Betriebs, nicht der Wiederherstellungs-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 beide 0 Punkte beim Test-Failover erzielten.
UEFI-to-BIOS-Konvertierung bei der Wiederherstellung
Der MSP360-Wiederherstellungshost startete im BIOS-Modus, während die Quelle UEFI/GPT nutzte. Die Wiederherstellung von MSP360 enthält eine Option „GPT zu BIOS/MBR konvertieren“, die das Partitionslayout und die Startkonfiguration für das BIOS-Ziel neu aufbaut; dadurch kann das wiederhergestellte Windows auf abweichender Firmware booten. Ohne diese Konvertierung wäre die Festplatte auf dem Wiederherstellungshost nicht bootfähig gewesen. Der Restore-to-File-Pfad von Comet stieß auf eine andere mechanische Grenze: Das Image wird auf die volle Datenträgergröße aufgebläht, sodass nur der Pfad von Bare Metal auf die Zielfestplatte 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 gegangen ist; gemessen wird, wie schnell der Dienst zurückkehrt (RTO) und wie viele Daten verloren gehen (RPO).
Der Benchmark zeigt den Unterschied. Alle drei Produkte erzeugten ein korrektes Backup und eine byte-exakte Wiederherstellung. Eines der drei, Acronis, verwandelte dieses Backup mit einem Klick in 73 Sekunden in einen laufenden Dienst auf einem frischen Server. Die anderen beiden 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 erhielten null Punkte. Ein Produkt kann ein ausgezeichnetes Backup-Tool sein und dennoch 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 aufbauen zu müssen. Acronis erfüllt diese Definition. Ein Wiederherstellungsserver startet in seiner Cloud per Runbook.
Comet, MSP360 und ähnliche Backup-Produkte verwenden auf ihren Marketingseiten Disaster-Recovery-Labels – MSP360 geht bis zu „DRaaS“ und „Cloud DR“ – um etwas anderes zu beschreiben: eine manuelle Wiederherstellung eines Disk-Images auf eine virtuelle Maschine oder Cloud-Instanz, die der Kunde bereitstellt und betreibt. Die Fähigkeit ist real und die Zielliste breit, aber die Orchestrierung übernimmt der Bediener. Wer „DRaaS“ liest, sollte prüfen, ob das Produkt eine Failover-Engine (Wiederherstellungsserver, Runbook, Test-Failover) enthält oder ob „DR“ nur die Wiederherstellungsfunktion des Backup-Produkts unter einem Marketing-Label ist.
Als bevorzugte Quelle hinzufügenMethodik des Disaster-Recovery-Benchmarks
Der Benchmark misst Disaster Recovery und nicht den Backup-Durchsatz; daher durchlief jedes Produkt denselben Wiederherstellungslebenszyklus: Agent installieren, ein sauberes Image eines laufenden Servers erstellen, einen Vorfall auf diesem Server auslösen, ihn auf einer separaten Maschine wiederherstellen und den wiederhergestellten Zustand anhand einer bekannten Baseline verifizieren. Die Zeiten der 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 großen Festplatte. 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 überprüft werden konnte. Die Workload bestand aus einem kleinen Webservice, der /health mit HTTP 200 beantwortete, einer Datenbanktabelle mit 10.000 Zeilen und bekannter fester Prüfsumme, 50 deterministischen Dateien sowie einem SHA-256-Baseline-Manifest aller Dateien. Da die Workload bei jedem Lauf identisch ist, handelt es sich bei der Frage, ob der exakte Zustand vor dem Vorfall zurückgekehrt ist, um eine Ja/Nein-Prüfung und nicht um eine Ermessensentscheidung.
Protokoll für Vorfall und Wiederherstellung
Der Vorfall war eine kontrollierte, umkehrbare Ransomware-Simulation, keine echte Malware. Zum Zeitpunkt T0 kodierte er die Workload-Dateien mit Base64 in Der Vorfall war eine kontrollierte, umkehrbare Ransomware-Simulation, keine echte Malware. Zum Zeitpunkt T0 kodierte er die Workload-Dateien mit Base64 in .locked-Kopien um und löschte die Originale, überschrieb jede Datenbankzeile mit einem ENCRYPTED_BY_RANSOMWARE_SIM-Marker und legte eine Lösegeldforderung ab. Das Betriebssystem blieb absichtlich aktiv, und die Daten waren beschädigt, sodass die Wiederherstellung vom Wiederherstellungspunkt des Anbieters aus erfolgen konnte und nicht von einem abgestürzten Host.
Die Wiederherstellung folgte einem festen Zeitstempel-Protokoll:
- T0, Vorfall ausgerufen (die Uhr startet hier).
- 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-Status 200).
- T5, der wiederhergestellte Dienst ist von einem externen Client erreichbar; dies ist die maßgebliche Geschäfts-RTO: RTO = T5 – T1.
- T6, die Datenintegrität wird bestätigt, indem das SHA-256-Manifest und die Datenbankprüfsumme mit der Baseline neu berechnet und bestätigt wird, dass keine
.locked-Dateien oder Lösegeldforderung verbleiben.
Die Zeiten stammen aus zwei Quellen und nicht von einer Stoppuhr. Die Anbieterkonsole liefert T1 bis T4 (das Aktivitäten- oder Auftragsprotokoll), und eine externe Prüfung von einer separaten Maschine liefert T5.
Die Wiederherstellungszeiten werden absichtlich mit unterschiedlicher Genauigkeit angegeben. Acronis stellt mit einer einzigen automatisierten Runbook-Aktion wieder her, sodass die End-to-End-Zeit ein sauberes, wiederholbares Zeitfenster ist; es führte zwei aufeinanderfolgende Failover-Übungen durch, und die Tabelle gibt den Durchschnitt an. Die manuellen Restore-to-VM-Wiederherstellungen (Comet und MSP360) sind mehrstufige Verfahren, bei denen der Bediener ein Ziel bereitstellt, das Image wiederherstellt und das Netzwerk von Hand neu konfiguriert; daher hängt die End-to-End-Zeit vom Bediener ab und wird als Spanne statt als Einzelwert angegeben. Die rein maschinellen Teile dieser Wiederherstellungen sind präzise (das Schreiben des Disk-Images von Comet dauerte etwa zwei Minuten, und die Restore-Engine von MSP360 erzeugte das bootfähige Image in fünf bis sechs Minuten), aber das gesamte Verfahren ist bedienergebunden.
Bewertungsmethodik
Sieben Dimensionen werden von 0 bis 100 bewertet und gewichtet. Die Automatisierungstiefe des Failovers 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 ein informatorischer Wert, auf die nächste Zehn gerundet.
Windows und Linux werden als getrennte Teilwerte bewertet und gemittelt. Ein Produkt, das Disaster Recovery auf einem Betriebssystem nicht unterstützt, erhält für diesen Teilwert null Punkte; die Lücke wird als Befund angeführt und nicht leer gelassen. Deshalb ergibt die nur unter Windows mögliche Wiederherstellung von MSP360 im Durchschnitt etwa die Hälfte seines Windows-Teilwerts.
Fehlende Fähigkeiten werden anhand ihrer Abwesenheit bewertet und angeführt (zum Beispiel setzt das Fehlen einer Failover-Engine bei Comet und MSP360 ihre Automatisierungs- und Test-Failover-Dimensionen auf null). „Durch Abwesenheit“ bedeutet, dass die Funktion nicht existiert, was am Produkt bestätigt wurde, und nicht, dass eine Dimension nicht getestet wurde.
Kategoriebewertungen
Die Punktzahlen sind der Durchschnitt der Windows- und Linux-Teilwerte. Acronis und Comet unterstützen Disaster Recovery auf beiden Betriebssystemen, daher entspricht ihr Durchschnitt dem Wert je Betriebssystem. MSP360 unterstützt imagebasierte Wiederherstellung unter Windows, nicht unter Linux; daher ist sein Linux-Teilwert 0 und jede Dimension halbiert sich.
Der Abstand zwischen Acronis und den beiden anderen konzentriert sich auf drei Dimensionen: Failover-Automatisierung (DR1), Test-Failover (DR2) und Konnektivität (DR6). Dies 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.
Bei der Zielabdeckung trennen sich die Produkte nicht. 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-to-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 dem stärksten bei der reinen Zielabdeckung; das ist der Punkt: Der entscheidende Unterschied im Benchmark ist Automatisierung, nicht Breite.
Die halbierte Spalte von MSP360 ist ein Artefakt der Betriebssystemabdeckung und keine schwächere Windows-Wiederherstellung. Unter Windows allein erzielt MSP360 bei der End-to-End-RTO dieselben 70 Punkte wie Comet unter Linux, da beide dieselbe Klasse manueller Restore-to-VM ausführen. Der betriebssystemü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 virtuellen Cloud-Maschinen ohne verschachtelte Virtualisierung getestet; daher wurden Funktionen, die einen lokalen Hypervisor benötigen (die Hyper-V-Wiederherstellungsprüfung von MSP360, lokale Replikationsziele), anhand der Dokumentation und der Produkt-UI bewertet statt praktisch ausgeführt. Die Konnektivitätsdimension wurde im Cloud-only-Modus praktisch geprüft; die VPN- und IPsec-Modi wurden anhand der Konsole und der 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 = sep,
howpublished = {\url{https://aimultiple.com/disaster-recovery-solutions}},
note = {AIMultiple. Abgerufen am 10. September 2026}
}Ergebnisse und Zeitstempel von 25 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 5 CSV-Dateien enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
1 AktualisierungenErsetzte Gewichtungen der Bewertungsdimensionen in der Disaster-Recovery-Benchmark-Methodik.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.