Disaster-Recovery-Benchmark: Acronis vs Comet vs MSP360

Wir haben Acronis Cyber Protect Cloud, Comet Backup und MSP360 Managed Backup im Bereich Disaster Recovery einem Benchmark unterzogen. Jeder Anbieter erstellte ein Image eines laufenden Windows Server 2022 und eines laufenden Ubuntu 24.04-Servers mit derselben deterministischen Arbeitslast, einem Webdienst, einer Datenbank mit 10.000 Zeilen und 50 Dateien und stellte dann die gesamte Maschine auf einem separaten Server wieder her, nachdem eine Ransomware-artige Katastrophe die Daten verschlüsselt hatte.

Ergebnisse des Disaster-Recovery-Benchmarks

Was jede Spalte bedeutet:

• Gewichtete Punktzahl: die Gesamtbewertung über die sieben Dimensionen hinweg, als Referenz angegeben; der Benchmark bewertet jede Dimension für sich.

• Wiederherstellungszeit: die End-to-End-Wiederherstellungszeit (RTO), von der Auslösung des Failovers bis zur Antwort des wiederhergestellten Dienstes auf eine externe Prüfung.

• Failover-Erkennung: ob das Produkt einen Test-Failover durchführen und bestätigen kann, dass die wiederhergestellte Maschine gebootet hat, von einer automatisierten Screenshot-Prüfung bis hin zu gar nichts.

• 3rd-Party-Integrationen: wie viele von sieben Wiederherstellungszielen (Anbieter-Cloud, AWS, Azure, Google Cloud, On-Premises-Hypervisor, Cross-Region, Cross-Cloud) das Produkt wiederherstellen kann.

• DR-Engine: ob das Produkt das Failover orchestriert (einen Wiederherstellungsserver und ein Runbook) oder nur 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 etwa 108 Sekunden unter Linux wieder her. Die Arbeitslast bootete auf einem frischen Server innerhalb 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 Wiederherstellung-zu-VM, die Dutzende Minuten dauerte und bei jedem Schritt einen Bediener erforderte: ein Ziel bereitstellen, das Disk-Image schreiben, das Netzwerk neu konfigurieren, neu booten.

• Alle drei erzielten eine bytegenaue Wiederherstellung. Das SHA-256-Manifest der 50 Dateien und die Datenbank-Prüfsumme stimmten in jedem Fall mit der Baseline vor der Katastrophe überein, sodass der Unterschied in Geschwindigkeit und Bedieneraufwand liegt, nicht in 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 ein Failover aus einem Runbook durch und validiert das Ergebnis mit einem automatisierten Test-Failover. Es erzielt seine Punktzahl durch Automatisierung, Wiederherstellungsgeschwindigkeit und Zielreichweite, und seine Hauptbeschränkung ist das agentenbasierte Failback.

Failover-Automatisierungstiefe

Runbooks orchestrieren das Failover durch 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, berechtigte Geräte und das Compute-Point-Kontingent. Kein anderes Produkt im Test kodifiziert die Wiederherstellung, anstatt sie einem Bediener zu überlassen.

Test-Failover-Fähigkeit

Der nicht-störende Test-Failover bootet den Wiederherstellungsserver in einem isolierten Netzwerk, und der automatisierte Test-Failover validiert einen geplanten Boot mit einer KI-Screenshot-Prüfung. Es funktionierte in beide Richtungen und lieferte ein echtes Fehlerurteil bei einem Linux-Server, der in der Journal-Wiederherstellung hing, und einen echten Erfolg bei einem sauberen Windows-Boot.

End-to-End-RTO

73 Sekunden unter Windows, etwa 108 Sekunden unter Linux (94 und 121 über zwei Drills hinweg). Ein Runbook-Klick bringt den Wiederherstellungsserver hoch, weist eine öffentliche IP zu und stellt die wiederhergestellte Anwendung bereit. Der wiederhergestellte Zustand war bytegenau gegenüber der Baseline vor der Katastrophe.

RPO

Die Wiederherstellung verwendete ein Backup, das drei bis vier Minuten alt war, innerhalb der RPO-Compliance-Schwelle. Die Schwelle ist konfigurierbar von 15 Minuten bis zu 14 Tagen.

Failback und Reprotect

Vierphasiges Delta-Failback (Planung, Datentransfer, Umschaltung, Validierung), wobei der Cloud-Server während des Transfers live bleibt. Die Rückkehr zur ursprünglichen Hardware erfordert bootfähige Medien und ein manuelles Reprotect.

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 öffentliche DNS-A-Record-Weiterleitung.

DR-Zielreichweite

Sechs von sieben Zielen. Ein verwalteter DR-Standort in der Acronis-Cloud oder Azure, Instant Restore auf On-Premises-VMware und Hyper-V, Wiederherstellung auf abweichender physischer Hardware und eine dokumentierte Restore-to-EC2-Migration in das eigene AWS-Konto des Kunden. Das orchestrierte Failover selbst läuft in der Acronis-Cloud oder Azure, sodass EC2 durch manuelle Wiederherstellung statt automatisiertes Failover erreicht wird. Nur Google Compute Engine hat keinen dokumentierten Pfad.

Ein Zuverlässigkeitshinweis ergab sich aus den Drills. Die saubere, bytegenaue Wiederherstellung wurde zweimal bewiesen, im ersten Drill (eine RTO von 94 Sekunden mit bestandener Integritätsprüfung) und im nicht-störenden Test-Failover. Der zweite Drill brachte zwei Wiederherstellungspunkt-Fallstricke zutage, beides keine Fehler der Wiederherstellungs-Engine. Ein Wiederherstellungspunkt, der während eines laufenden Resets erfasst wurde, bootete in einen hängenden Journal-Recovery-Zustand und musste wiederholt werden. Das Stoppen dieses Failovers setzte das Quell-Backup automatisch fort, das die noch verschlüsselte Quelle erfasste, sodass die Wiederholung pünktlich bootete, aber auf diesem neueren verschlüsselten Punkt landete. Der Wiederherstellungsserver ist nicht besser als der Wiederherstellungspunkt dahinter, daher ist das Anhalten 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 bei Failover-Automatisierung und Test-Failover, weil es beides nicht hat, und verdiente seine Punkte durch den manuellen Wiederherstellung-zu-VM-Pfad und die Breite der Wiederherstellungsziele. Seine Disk-Image-Wiederherstellung funktioniert. Im Benchmark brachte es einen von Ransomware betroffenen Ubuntu-Server bytegenau und extern erreichbar auf einem frischen Host zurück.

Failover-Automatisierungstiefe

Keine. Kein Wiederherstellungsserver, kein Runbook, kein One-Click-Failover. Die Wiederherstellung ist ein manuelles End-to-End-Verfahren. Comets eigener Disaster-Recovery-Leitfaden beschreibt kein Workload-Failover; er behandelt den Schutz der eigenen Comet-Konsole durch Replikation und die Neuregistrierung eines frischen Agenten nach Verlust eines Client-Geräts.

Test-Failover-Fähigkeit

Keine. Die Option „Nur Wiederherstellung simulieren“ des Wiederherstellungsassistenten ist ein Probelauf, der keine Maschine bootet, sodass es keinen bewertbaren Test-Failover gibt.

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, Agenteninstallation, Wiederherstellung auf physisches Gerät, Netzwerk-Neuschreibung, Neustart) dauerte 15 bis 25 Minuten. Der wiederhergestellte Server stimmte mit der Prüfsumme vor der Katastrophe überein und stellte seine Anwendung unter einer neuen IP bereit.

RPO

Geplante Disk-Image-Backups mit Inkrementen, kein Continuous Data Protection. Das erste Live-Root-Volume-Backup füllte den differenziellen Speicher und erforderte, dass die Arbeitslast für ein sauberes Image stillgelegt wurde.

Failback und Reprotect

Failback ist dieselbe manuelle Wiederherstellung in umgekehrter Richtung, ohne Delta-Sync und ohne automatisiertes Reprotect.

Konnektivität und Netzwerkflexibilität

Kein DR-Netzwerk. Die wiederhergestellte Maschine übernahm das MAC-abgestimmte statische Netplan der Quelle, das wir von Hand auf die Adresse des Wiederherstellungs-Hosts umschrieben, bevor sie hochkam.

DR-Zielreichweite

Bare Metal, Hyper-V, VMware vSphere und Proxmox nativ; AWS und Azure über VMDK- und VHDX-Export. Ein Vorbehalt tauchte hier auf: Ein Restore-to-File-Image wird auf die volle Festplattengröße aufgebläht, sodass die gleich große Quellfestplatte die Zwischendatei nicht aufnehmen kann, was den Bare-Metal-Wiederherstellungspfad erzwang.

MSP360 Managed Backup

MSP360 ist ein Backup-Produkt, dessen Disaster Recovery eine manuelle Wiederherstellung-zu-VM ist und dessen Wiederherstellung unter Windows, nicht unter Linux funktioniert. Unter Windows erreichte es die Wiederherstellungsklasse von Comet und bootete einen wiederhergestellten Server auf separater Hardware. Seine plattformübergreifende Punktzahl ist niedrig, weil sein Linux-Agent kein Image-Backup hat, sodass die Hälfte des Benchmarks (Linux-Wiederherstellung) null Punkte erzielt. Die folgenden Teilpunktzahlen gelten für Windows; die plattformübergreifende Summe ist der Durchschnitt der Windows-Werte mit einer Linux-Null.

Failover-Automatisierungstiefe

Keine Engine, kein Runbook, kein Wiederherstellungsserver. Die Begriffe „DRaaS“ und „Cloud DR“ auf den Produktseiten führen zu einer manuellen Wiederherstellung-zu-VM.

Test-Failover-Fähigkeit

Die Funktion „Run Restore Verification“ bootet das Image als Hyper-V-virtuelle Maschine und prüft auf eine erfolgreiche Anmeldung, was mehr ist als ein Probelauf, aber sie benötigt lokales Hyper-V (auf den Cloud-Test-Hosts nicht vorhanden) und validiert ein Backup, anstatt auf einen Wiederherstellungsstandort überzugehen.

End-to-End-RTO

Wir stellten ein vollständiges 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-Prüfung bytegenau sauber. Die Wiederherstellungs-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 die Bare-Metal-Wiederherstellung-zu-VM ein 15-bis-25-minütiges, mehrschrittiges manuelles Verfahren, dieselbe Klasse wie Comets Linux-Wiederherstellung. Eine einfachere In-Place-Wiederherstellung nur der verschlüsselten Daten, bei laufendem Server, dauerte etwa 10 Minuten.

RPO

Geplante Image-Backups mit Changed-Block-Tracking-Inkrementen, kein Continuous Data Protection.

Failback und Reprotect

Manuelle vollständige Wiederherstellung zurück zur Quelle, kein Delta-Sync, kein automatisiertes Reprotect.

Konnektivität und Netzwerkflexibilität

Kein DR-Netzwerk. Der wiederhergestellte Server bootete mit der statischen IP der Quellmaschine und war nicht erreichbar, bis wir die korrekte Adresse über die Out-of-Band-Konsole setzten.

DR-Zielreichweite

Physische Festplatte, Hyper-V, VMware vSphere und VirtualBox, plus alle drei Public Clouds durch native Wiederherstellungsassistenten-Optionen: Restore to Amazon EC2, Restore to Azure VM und Restore to 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, sodass es bei der reinen Zielanzahl mit Acronis gleichzieht und Comet übertrifft. Es fehlt nur die vom Anbieter verwaltete DR-Cloud, die es gar nicht hat. Die GPT-zu-BIOS/MBR-Konvertierung, die Bare-Metal-Wiederherstellung auf einem BIOS-Host bootfähig machte, ist ein nützlicher Teil der Breite.

Die Linux-Lücke ist die entscheidende Einschränkung. Der Linux-Agent von MSP360 führt nur Dateiebene-Backups durch, ohne Disk-Image, sodass es kein bootfähiges Systemabbild und keine Wiederherstellung-zu-VM unter Linux gibt. 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, aber unterschiedlich zusammengesetzt. Acronis stellt in seine eigene Cloud, Azure, On-Premises-VMware- und Hyper-V-Hosts sowie das AWS EC2 eines Kunden über eine dokumentierte Restore-to-EC2-Migration wieder her, wobei nur Google Compute Engine fehlt. MSP360 hat keine verwaltete Cloud, unterstützt aber alle drei Public Clouds nativ (sein 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 durch Export einer VMDK oder VHDX und deren Import, ohne verwaltete Cloud und ohne Google Cloud-Pfad. Acronis und MSP360 erreichen jeweils sechs von sieben Zieltypen und Comet fünf. Keines bietet eine integrierte Drittanbieter-DNS-Failover-Integration wie eine automatische Cloudflare-artige Record-Weiterleitung; 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

Netzwerkneukonfiguration nach einer manuellen Wiederherstellung

Bei beiden manuellen Produkten bootete der wiederhergestellte Server mit der statischen IP der Quellmaschine, nicht der des Wiederherstellungs-Hosts, und war im Netzwerk nicht erreichbar, bis ein Bediener dies behob. 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 gebooteten Server an und setzten die statische IP von Hand. Ein DRaaS erledigt dies als Teil des Failovers; eine manuelle Wiederherstellung nicht.

Qualität des Wiederherstellungspunkts und Failover-Zuverlässigkeit

Die geschäftliche End-to-End-RTO betrug 94 Sekunden im ersten Linux-Failover-Drill, bei einem etwa 3 Minuten alten Wiederherstellungspunkt. Das Windows-Failover lieferte 73 Sekunden über zwei Durchläufe mit null Varianz. Drill 1 und der nicht-störende Test-Failover bestanden jeweils eine bytegenaue T6-Integritätsprüfung, ohne dass Ransomware in das wiederhergestellte System übertragen wurde.

Die beiden Punkte, die im zweiten Linux-Drill auftauchten, waren ein während eines Resets erfasster Wiederherstellungspunkt, der in einem Journal-Recovery-Hang bootete, und ein automatisch fortgesetztes Quell-Backup, das einen noch verschlüsselten Punkt in die Wiederholung einbrachte, beides Wiederherstellungspunkt- und betriebsbedingte, nicht wiederherstellungsenginebedingte Fehler. Der Acronis Automated Test Failover erkannte denselben Journal-Recovery-Zustand unabhängig in einem nicht-störenden Test und gab ein Fehlerurteil zurück, ein Validierungsschritt, der bei Comet und MSP360 fehlt, die beide 0 beim Test-Failover erzielten.

UEFI-zu-BIOS-Konvertierung bei der Wiederherstellung

Der MSP360-Wiederherstellungs-Host bootete im BIOS-Modus, während die Quelle UEFI/GPT war. 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 booten kann. Ohne diese Konvertierung wäre die Festplatte auf dem Wiederherstellungs-Host nicht bootfähig gewesen. Der Restore-to-File-Pfad von Comet stieß auf eine andere mechanische Grenze: Das Image wird auf die volle Festplattengröße aufgebläht, sodass der Bare-Metal-zu-Zielfestplatte-Pfad der einzige war, der passte.

Backup versus Disaster Recovery

Ein Backup ist eine Kopie von Daten, die wiederhergestellt werden können. Disaster Recovery ist der orchestrierte Prozess, eine Arbeitslast auf einer anderen Infrastruktur wieder in Betrieb zu nehmen, nachdem das Original verloren gegangen ist, gemessen daran, wie schnell der Dienst zurückkehrt (RTO) und wie viele Daten verloren gehen (RPO).

Der Benchmark zeigt die Lücke. Alle drei Produkte erstellten 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 anderen beiden stellten dieselben Daten korrekt wieder her, überließen aber das Failover, den Boot und das Netzwerk einem Menschen, weshalb ihre Wiederherstellung Dutzende Minuten dauerte und ihre Automatisierungsdimensionen null Punkte erzielten. 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 aufzubauen. Acronis erfüllt diese Definition. Ein Wiederherstellungsserver bootet in seiner Cloud aus einem Runbook.

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

Entdecken Sie weitere unserer Benchmarks und datengestützten Erkenntnisse in der Google-Suche.

Als bevorzugte Quelle hinzufügen

Disaster-Recovery-Benchmark-Methodik

Der Benchmark misst Disaster Recovery, nicht Backup-Durchsatz, daher durchlief jedes Produkt denselben Wiederherstellungszyklus: Installation des Agenten, Erstellung eines sauberen Images eines laufenden Servers, Auslösung einer Katastrophe auf diesem Server, Wiederherstellung auf einer separaten Maschine und Überprüfung des wiederhergestellten Zustands gegen eine bekannte Baseline. Image-Backup-Zeiten werden als verstrichene Zeit, nicht als Durchsatz angegeben.

Testumgebung

Die Quellen waren zwei Cloud-Server, ein Windows Server 2022 und ein Ubuntu 24.04, jeweils ein 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 Arbeitslast aus, damit die Wiederherstellung Byte für Byte überprüft werden konnte. Die Arbeitslast war ein kleiner Webdienst, der /health mit HTTP 200 beantwortete, eine Datenbanktabelle mit 10.000 Zeilen mit einer bekannten festen Prüfsumme, 50 deterministische Dateien und ein SHA-256-Baseline-Manifest von allen. Da die Arbeitslast bei jedem Durchlauf identisch ist, ist „Kam der exakte Zustand vor der Katastrophe zurück?“ eine Ja-oder-Nein-Prüfung, kein Ermessensspielraum.

Katastrophen- und Wiederherstellungsprotokoll

Die Katastrophe war eine kontrollierte, reversible Ransomware-Simulation, keine echte Malware. Bei T0 kodierte sie die Arbeitslastdateien mit Base64 in .locked-Kopien und löschte die Originale, überschrieb jede Datenbankzeile mit einem ENCRYPTED_BY_RANSOMWARE_SIM-Marker und hinterließ eine Lösegeldforderung. Das Betriebssystem blieb absichtlich in Betrieb, und die Daten waren beschädigt, sodass die Wiederherstellung vom Wiederherstellungspunkt des Anbieters aus gesteuert werden konnte, statt von einem abgestürzten Host.

Die Wiederherstellung folgte einem festen Zeitstempel-Protokoll:

• T0, Katastrophe ausgerufen (die Uhr startet hier).
• T1, Bediener löst das Failover aus (ein Runbook-Klick für Acronis, die erste manuelle Wiederherstellungsaktion für die 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 aus erreichbar, was die geschäftliche RTO-Schlagzeile ist: RTO = T5 – T1.
• T6, die Datenintegrität wird bestätigt, indem das SHA-256-Manifest und die Datenbank-Prüfsumme gegen die Baseline neu berechnet werden und bestätigt wird, dass keine .locked-Dateien oder Lösegeldforderung verbleiben.

Die Zeiten stammen aus zwei Quellen, nicht aus 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 bewusst mit unterschiedlicher Genauigkeit angegeben. Acronis stellt mit einer einzigen automatisierten Runbook-Aktion wieder her, sodass seine End-to-End-Zeit ein sauberes, wiederholbares Fenster ist; es führte zwei aufeinanderfolgende Failover-Drills durch, und die Tabelle zeigt den Durchschnitt. Die manuellen Wiederherstellung-zu-VM-Wiederherstellungen (Comet und MSP360) sind mehrschrittige Verfahren, bei denen der Bediener ein Ziel bereitstellt, das Image wiederherstellt und das Netzwerk von Hand neu konfiguriert, sodass die End-to-End-Zeit vom Bediener abhängt und als Bereich statt als Einzelwert angegeben wird. Die rein maschinellen Teile dieser Wiederherstellungen sind präzise (Comets Disk-Image-Schreiben dauerte etwa zwei Minuten, und die MSP360-Wiederherstellungs-Engine erzeugte das bootfähige Image in fünf bis sechs Minuten), aber das vollständige Verfahren ist bedienergebunden.

Bewertungsmethodik

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

Windows und Linux werden als separate Teilpunktzahlen bewertet und gemittelt. Ein Produkt, das Disaster Recovery auf einem Betriebssystem nicht unterstützt, erzielt null in dieser Teilpunktzahl, wobei die Lücke als Erkenntnis angeführt und nicht leer gelassen wird, weshalb MSP360s reine Windows-Wiederherstellung im Durchschnitt etwa die Hälfte seiner Windows-Teilpunktzahl beträgt.

Fähigkeiten, die ein Produkt nicht hat, werden durch Abwesenheit bewertet und angeführt (zum Beispiel setzt das Fehlen einer Failover-Engine bei Comet und MSP360 deren Automatisierungs- und Test-Failover-Dimensionen auf null). „Durch Abwesenheit“ bedeutet, dass die Funktion nicht existiert, bestätigt am Produkt, und nicht etwa eine nicht getestete Dimension ist.

Kategorie-Punktzahlen

Die Punktzahlen sind der Durchschnitt der Windows- und Linux-Teilpunktzahlen. Acronis und Comet unterstützen Disaster Recovery auf beiden Betriebssystemen, daher entspricht ihr Durchschnitt ihrer jeweiligen betriebssystemspezifischen Punktzahl. MSP360 unterstützt imagebasierte Wiederherstellung unter Windows, nicht unter Linux, daher ist seine Linux-Teilpunktzahl 0 und jede Dimension ist halbiert.

Der Abstand zwischen Acronis und den anderen beiden 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 von Acronis‘ Vorsprung vor Comet aus.

Die Zielreichweite ist nicht das, worin sich die Produkte unterscheiden. Acronis und MSP360 erreichen jeweils sechs von sieben Zieltypen und Comet fünf, aber die Mengen unterscheiden sich: Acronis bringt seine verwaltete Cloud, AWS EC2 (dokumentierte Restore-to-EC2-Migration), Azure, On-Premises-Hypervisoren, Cross-Region und Cross-Cloud mit, wobei nur Google Compute Engine fehlt; MSP360 hat keine verwaltete Cloud, erreicht aber alle drei Public Clouds nativ, AWS, Azure und Google Compute Engine, plus On-Premises-Hypervisoren. Das schwächste Produkt bei der Automatisierung entspricht somit dem stärksten bei der reinen Reichweite, was der Punkt ist: Der Unterschied, der den Benchmark entscheidet, ist Automatisierung, nicht Breite.

MSP360s halbierte Spalte ist ein Artefakt der Betriebssystemabdeckung, nicht einer schwächeren Windows-Wiederherstellung. Unter Windows allein erzielt MSP360 dieselben 70 bei der End-to-End-RTO wie Comet unter Linux, weil beide dieselbe Klasse der manuellen Wiederherstellung-zu-VM ausführen. Der plattformübergreifende Durchschnitt fällt auf 21, weil MSP360 imagebasierte Wiederherstellung unter Linux überhaupt nicht durchführen kann.

Einschränkungen und Umfang

Die Disaster-Recovery-Seite wurde auf Cloud-virtuellen Maschinen ohne verschachtelte Virtualisierung getestet, sodass jede Funktion, die einen lokalen Hypervisor benötigt (MSP360s Hyper-V-Wiederherstellungsverifizierung, On-Premises-Replikationsziele), anhand der Dokumentation und der Produkt-Benutzeroberfläche bewertet und nicht ausgeführt wurde. Die Konnektivitätsdimension wurde im Cloud-Only-Modus praktisch getestet; 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  = jul,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Abgerufen am 20. Juli 2026}
}

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

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