Benchmark di disaster recovery: Acronis vs Comet vs MSP360

Abbiamo confrontato Acronis Cyber Protect Cloud, Comet Backup e MSP360 Managed Backup in termini di disaster recovery. Ogni fornitore ha acquisito un'immagine di un server Windows Server 2022 attivo e di un server Ubuntu 24.04 attivo con lo stesso carico di lavoro deterministico, un servizio web, un database da 10.000 righe e 50 file, quindi ha ripristinato l'intera macchina su un server separato dopo che un disastro in stile ransomware ha crittografato i dati.

Risultati del benchmark di disaster recovery

Cosa significa ogni colonna:

• Punteggio ponderato: il totale della rubrica nelle sette dimensioni, riportato come riferimento; il benchmark valuta ogni dimensione singolarmente.
• Tempo di ripristino: il tempo di ripristino end-to-end (RTO), dalla dichiarazione del failover alla risposta del servizio ripristinato a una sonda esterna.
• Rilevamento failover: se il prodotto può eseguire un failover di test e confermare l'avvio della macchina ripristinata, da un controllo automatico tramite screenshot fino a nulla.
• Integrazioni di 3rd parti: quante delle sette destinazioni di ripristino (cloud del fornitore, AWS, Azure, Google Cloud, hypervisor on-premises, cross-region, cross-cloud) il prodotto può raggiungere per il ripristino.
• Motore DR: se il prodotto orchestra il failover (un server di ripristino e un runbook) o si limita a ripristinare manualmente un backup.

Consulta la metodologia del benchmark di disaster recovery per la griglia di valutazione e il protocollo di temporizzazione T0-T6.

I principali risultati:

• Acronis ha ripristinato il server crittografato in 73 secondi su Windows e circa 108 secondi su Linux con un solo clic su un runbook. Il carico di lavoro si è avviato su un nuovo server all'interno del cloud del fornitore, ha ricevuto automaticamente un IP pubblico ed è tornato pulito e identico byte per byte.
• Comet e MSP360 non hanno un motore di failover. Il ripristino è un restore-to-VM manuale che ha richiesto decine di minuti e un operatore in ogni fase: provisioning di una destinazione, scrittura dell'immagine disco, riconfigurazione della rete, riavvio.
• Tutti e tre hanno prodotto un ripristino identico byte per byte. Il manifest SHA-256 dei 50 file e il checksum del database corrispondevano alla baseline pre-disastro in ogni caso, quindi la differenza è la velocità e l'impegno dell'operatore, non l'integrità dei dati.

Prodotti di disaster recovery messi a confronto

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Acronis Backup Cloud for Service Providers

Comet Backup

Comet Backup

Comet Backup

Comet Backup

Comet Backup

Comet Backup

MSP360

MSP360

MSP360

MSP360

MSP360

MSP360

MSP360

1/21

Acronis Cyber Protect Cloud

Acronis è l'unico prodotto nel test con un motore di failover di disaster recovery-as-a-service. Esegue un server di ripristino nel cloud Acronis, esegue il failover da un runbook e convalida il risultato con un failover di test automatico. Ottiene il proprio punteggio per automazione, velocità di ripristino e copertura delle destinazioni, mentre il suo limite principale è il failback basato su agente.

Profondità di automazione del failover

I runbook orchestrano il failover tramite passaggi ordinati, azioni parallele all'interno di un passaggio, controlli di completamento su ping e porta, approvazioni manuali e runbook annidati. La dashboard di conformità monitora gli obiettivi RPO, i dispositivi idonei e la quota di punti di calcolo. Nessun altro prodotto nel test codifica il ripristino invece di lasciarlo a un operatore.

Capacità di failover di test

Il failover di test non distruttivo avvia il server di ripristino su una rete isolata e l'Automated Test Failover convalida un avvio pianificato con un controllo tramite screenshot IA. Ha funzionato in entrambe le direzioni, emettendo un verdetto di errore reale su un server Linux bloccato nel journal recovery e un successo reale su un avvio Windows pulito.

RTO end-to-end

73 secondi su Windows, circa 108 secondi su Linux (94 e 121 in due esercitazioni). Un clic sul runbook avvia il server di ripristino, assegna un IP pubblico e serve l'applicazione ripristinata. Lo stato ripristinato era identico byte per byte rispetto alla baseline pre-disastro.

RPO

Il ripristino ha utilizzato un backup vecchio di tre o quattro minuti, entro la soglia di conformità RPO. La soglia è configurabile da 15 minuti a 14 giorni.

Failback e reprotect

Failback delta in quattro fasi (pianificazione, trasferimento dati, switchover, validazione) con il server cloud che rimane attivo durante il trasferimento. Il ritorno all'hardware originale richiede supporto avviabile e un reprotect manuale.

Connettività e flessibilità di rete

La modalità solo cloud non richiede alcun appliance VPN. Sono disponibili OpenVPN site-to-site, IPsec multi-sito, VPN point-to-site, IP pubblico per server e DNS personalizzato. Non esiste un reroute integrato dei record A DNS pubblici.

Copertura delle destinazioni DR

Sei delle sette destinazioni. Un sito DR gestito nel cloud Acronis o in Azure, Instant Restore su VMware e Hyper-V on-premises, ripristino su hardware fisico diverso e una migrazione documentata restore-to-EC2 nell'account AWS del cliente. Il failover orchestrato stesso viene eseguito nel cloud Acronis o Azure, quindi EC2 viene raggiunto tramite ripristino manuale anziché failover automatico. Solo Google Compute Engine non ha un percorso documentato.

Dalle esercitazioni è emersa una nota sull'affidabilità. Il ripristino pulito e identico byte per byte è stato dimostrato due volte, nella prima esercitazione (un RTO di 94 secondi con un controllo di integrità superato) e nel failover di test non distruttivo. La seconda esercitazione ha evidenziato due criticità relative al punto di ripristino, nessuna delle quali imputabile al motore di ripristino. Un punto acquisito mentre la sorgente era a metà reset si è avviato in uno stato bloccato di journal recovery ed è stato necessario rifarlo. L'interruzione di quel failover ha auto-ripristinato il backup della sorgente, che ha acquisito la sorgente ancora crittografata, cosicché il nuovo tentativo si è avviato in tempo ma è atterrato su quel punto crittografato più recente. Il server di ripristino non è migliore del punto di ripristino alle spalle, quindi sospendere il backup durante un incidente ed eseguire il failover da un punto noto pulito è la sequenza più sicura.

Comet Backup

Comet è un prodotto di backup senza motore di disaster recovery. Ha ottenuto 0 su automazione del failover e failover di test, poiché non dispone di nessuno dei due, e ha guadagnato punti sul percorso manuale restore-to-VM e sull'ampiezza delle destinazioni di ripristino. Il ripristino dell'immagine disco funziona. Nel benchmark, ha riportato indietro un server Ubuntu colpito da ransomware, identico byte per byte e raggiungibile esternamente, su un host nuovo.

Profondità di automazione del failover

Nessuna. Nessun server di ripristino, nessun runbook, nessun failover con un clic. Il ripristino è una procedura end-to-end manuale. La guida di disaster recovery di Comet non descrive un failover del carico di lavoro; copre la protezione della console di Comet tramite replica e la nuova registrazione di un agente nuovo dopo la perdita di un dispositivo client.

Capacità di failover di test

Nessuna. L'opzione “Simulate restore only” della procedura guidata di ripristino è una prova a secco che non avvia una macchina, quindi non c'è alcun failover di test da valutare.

RTO end-to-end

La scrittura dell'immagine disco sul disco di un nuovo server ha richiesto circa due minuti, ma l'intera procedura (avvio di ripristino, installazione dell'agente, restore-to-physical-device, riscrittura della rete, riavvio) è durata da 15 a 25 minuti. Il server ripristinato corrispondeva al checksum pre-disastro e serviva la propria applicazione a un nuovo IP.

RPO

Backup pianificati dell'immagine disco con incrementali, nessuna protezione continua dei dati. Il primo backup del volume root attivo ha riempito lo storage differenziale e ha richiesto la quiescenza del carico di lavoro per un'immagine pulita.

Failback e reprotect

Il failback è lo stesso ripristino manuale al contrario, senza delta-sync e senza reprotect automatico.

Connettività e flessibilità di rete

Nessuna rete DR. La macchina ripristinata conservava il netplan statico corrispondente al MAC della sorgente, che abbiamo riscritto manualmente con l'indirizzo dell'host di ripristino prima che potesse avviarsi.

Copertura delle destinazioni DR

Bare metal, Hyper-V, VMware vSphere e Proxmox in modo nativo; AWS e Azure tramite esportazione VMDK e VHDX. È emersa una limitazione: un'immagine restore-to-file si espande fino alla dimensione completa del disco, quindi il disco sorgente delle stesse dimensioni non può contenere il file intermedio, il che ha imposto il percorso di ripristino bare-metal.

MSP360 Managed Backup

MSP360 è un prodotto di backup il cui disaster recovery è un restore-to-VM manuale e il cui ripristino funziona su Windows, non su Linux. Su Windows ha eguagliato la classe di ripristino di Comet e ha avviato un server ripristinato su hardware separato. Il punteggio cross-OS è basso perché l'agente Linux non dispone di backup dell'immagine, quindi metà del benchmark (ripristino Linux) ottiene zero. I sotto-punteggi seguenti si riferiscono a Windows; il totale cross-OS è la media dei valori Windows con uno zero per Linux.

Profondità di automazione del failover

Nessun motore, nessun runbook, nessun server di ripristino. Le voci “DRaaS” e “Cloud DR” sulle pagine prodotto si risolvono in un restore-to-VM manuale.

Capacità di failover di test

La funzione Run Restore Verification avvia l'immagine come macchina virtuale Hyper-V e verifica un accesso riuscito, il che è più di una prova a secco, ma richiede Hyper-V locale (assente sugli host di test cloud) e convalida un backup invece di eseguire il failover verso un sito di ripristino.

RTO end-to-end

Abbiamo ripristinato un'immagine disco completa con conversione GPT-to-BIOS/MBR, l'abbiamo scritta su un server cloud separato, abbiamo avviato Windows sul nuovo host e abbiamo raggiunto una sonda di salute esterna identica byte per byte. Il motore di ripristino ha prodotto l'immagine avviabile in cinque-sei minuti; il resto è stato lo spostamento dell'immagine, l'avvio e una correzione manuale della rete. End-to-end, il restore-to-VM bare-metal è stato una procedura manuale in più fasi da 15 a 25 minuti, la stessa classe del ripristino Linux di Comet. Un ripristino in-place più semplice dei soli dati crittografati, con il server ancora in esecuzione, ha richiesto circa 10 minuti.

RPO

Backup pianificati dell'immagine con incrementali changed-block-tracking, nessuna protezione continua dei dati.

Failback e reprotect

Ripristino completo manuale verso la sorgente, nessun delta-sync, nessun reprotect automatico.

Connettività e flessibilità di rete

Nessuna rete DR. Il server ripristinato si è avviato con l'IP statico della macchina sorgente ed era irraggiungibile finché non abbiamo impostato l'indirizzo corretto tramite la console out-of-band.

Copertura delle destinazioni DR

Disco fisico, Hyper-V, VMware vSphere e VirtualBox, oltre a tutti e tre i cloud pubblici tramite opzioni native della procedura guidata di ripristino: Restore to Amazon EC2, Restore to Azure VM e Restore to Google Cloud Instance (l'esportazione dell'immagine in AWS VM Import è l'alternativa indiretta). Il ripristino nativo su Google Cloud rende MSP360 l'unico prodotto nel test che raggiunge Google Compute Engine, quindi per numero grezzo di destinazioni è pari ad Acronis e supera Comet. Gli manca solo il cloud DR gestito dal fornitore, di cui non dispone affatto. La conversione GPT-to-BIOS/MBR che ha consentito l'avvio del ripristino bare-metal su un host BIOS è un elemento utile dell'ampiezza.

La lacuna Linux è la limitazione decisiva. L'agente Linux di MSP360 esegue solo backup a livello di file, senza immagine disco, quindi non esiste un'immagine di sistema avviabile né un restore-to-VM su Linux. Per un MSP con qualsiasi flotta Linux, il disaster recovery con MSP360 copre solo metà del parco macchine.

Confronto delle funzionalità

Failover e orchestrazione

Integrazioni di terze parti e destinazioni di ripristino

La copertura di ripristino è simile tra i tre, ma composta in modo diverso. Acronis ripristina nel proprio cloud, in Azure, su host VMware e Hyper-V on-premises e su EC2 AWS del cliente tramite una migrazione documentata restore-to-EC2, mancando solo di Google Compute Engine. MSP360 non dispone di cloud gestito ma supporta nativamente tutti e tre i cloud pubblici (la procedura guidata di ripristino offre Restore to EC2, Azure VM e Google Cloud Instance), rendendolo l'unico prodotto qui che supporta Google Compute Engine.

Comet raggiunge AWS e Azure esportando e importando un VMDK o VHDX, senza cloud gestito e senza percorso Google Cloud. Acronis e MSP360 arrivano ciascuno a sei tipi di destinazione su sette e Comet a cinque. Nessuno integra un failover DNS di terze parti integrato come un reroute automatico dei record in stile Cloudflare; Acronis offre DNS personalizzato e modalità VPN, mentre sui prodotti manuali la rete della macchina ripristinata viene configurata a mano.

Rete e failback

Risultati dei test di disaster recovery

Riconfigurazione della rete dopo un ripristino manuale

Su entrambi i prodotti manuali, il server ripristinato si è avviato con l'IP statico della macchina sorgente, non con quello dell'host di ripristino, ed era irraggiungibile sulla rete fino a quando un operatore non lo ha corretto. L'indirizzo risiede all'interno dell'immagine disco, quindi viaggia con il ripristino. Su Comet (Linux) abbiamo riscritto la configurazione netplan nell'ambiente di ripristino; su MSP360 (Windows) abbiamo effettuato l'accesso al server avviato tramite la console cloud e impostato manualmente l'IP statico. Un DRaaS gestisce questo come parte del failover; un ripristino manuale no.

Qualità del punto di ripristino e affidabilità del failover

L'RTO aziendale end-to-end ha misurato 94 secondi nella prima esercitazione di failover Linux, con un punto di ripristino vecchio di circa 3 minuti. Il failover Windows ha restituito 73 secondi su due esecuzioni con varianza zero. L'esercitazione 1 e il failover di test non distruttivo hanno entrambi superato un controllo di integrità T6 identico byte per byte senza ransomware trasferito nel sistema ripristinato.

I due elementi emersi nella seconda esercitazione Linux sono stati un punto di ripristino acquisito a metà reset che si è avviato in un blocco del journal recovery e un backup sorgente auto-ripristinato che ha inserito un punto ancora crittografato nel nuovo tentativo, entrambi problemi di punto di ripristino e operativi piuttosto che guasti del motore di ripristino. L'Automated Test Failover di Acronis ha rilevato in modo indipendente la stessa condizione di journal recovery in un test non distruttivo e ha restituito un verdetto di errore, un passaggio di validazione assente in Comet e MSP360, che hanno entrambi ottenuto 0 nel failover di test.

Conversione da UEFI a BIOS durante il ripristino

L'host di ripristino MSP360 si è avviato in modalità BIOS mentre la sorgente era UEFI/GPT. Il ripristino di MSP360 include un'opzione “Convert GPT to BIOS/MBR” che ricostruisce il layout delle partizioni e la configurazione di avvio per la destinazione BIOS, consentendo l'avvio del Windows ripristinato su firmware diverso. Senza tale conversione, il disco non sarebbe stato avviabile sull'host di ripristino. Il percorso restore-to-file di Comet ha incontrato un ostacolo meccanico diverso: l'immagine si espande fino alla dimensione completa del disco, quindi il percorso bare-metal verso il disco di destinazione era l'unico adatto.

Backup e disaster recovery a confronto

Un backup è una copia di dati che può essere ripristinata. Il disaster recovery è il processo orchestrato di riportare in servizio un carico di lavoro su infrastrutture diverse dopo la perdita dell'originale, misurato in base alla rapidità con cui il servizio torna disponibile (RTO) e alla quantità di dati persi (RPO).

Il benchmark mostra il divario. Tutti e tre i prodotti hanno prodotto un backup corretto e un ripristino identico byte per byte. Uno dei tre, Acronis, ha trasformato quel backup in un servizio in esecuzione su un nuovo server con un clic in 73 secondi. Gli altri due hanno ripristinato correttamente gli stessi dati ma hanno lasciato failover, avvio e rete a un operatore umano, motivo per cui il loro ripristino ha richiesto decine di minuti e le dimensioni di automazione hanno ottenuto zero. Un prodotto può essere un eccellente strumento di backup e tuttavia non essere uno strumento di disaster recovery.

Cosa significa disaster-recovery-as-a-service (DRaaS) means?

Disaster-recovery-as-a-service significa che il fornitore ospita l'ambiente di ripristino e orchestra il failover, cosicché il cliente può ripristinare in un'infrastruttura gestita senza doverla costruire. Acronis rientra in questa definizione. Un server di ripristino si avvia nel suo cloud da un runbook.

Comet, MSP360 e prodotti di backup simili usano etichette di disaster recovery sulle loro pagine marketing, MSP360 spingendosi fino a “DRaaS” e “Cloud DR”, per descrivere una cosa diversa: un ripristino manuale di un'immagine disco su una macchina virtuale o un'istanza cloud che il cliente provisioning e gestisce. La capacità è reale e l'elenco delle destinazioni è ampio, ma l'orchestrazione è l'operatore. Un acquirente che legge “DRaaS” dovrebbe verificare se il prodotto include un motore di failover (un server di ripristino, un runbook, un failover di test) o se “DR” è solo la funzione di ripristino del prodotto di backup sotto un'etichetta marketing.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Metodologia del benchmark di disaster recovery

Il benchmark misura il disaster recovery, non la velocità del backup, quindi ogni prodotto ha eseguito lo stesso ciclo di ripristino: installazione dell'agente, acquisizione di un'immagine pulita di un server attivo, simulazione di un disastro su quel server, ripristino su una macchina separata e verifica dello stato ripristinato rispetto a una baseline nota. I tempi del backup dell'immagine sono riportati come tempo trascorso, non come throughput.

Ambiente di test

Le sorgenti erano due server cloud, uno Windows Server 2022 e uno Ubuntu 24.04, ciascuno un VPS cloud con un disco da 75 GB. Le destinazioni di ripristino erano server cloud separati della stessa classe (e, per Acronis, il cloud del fornitore).

Ogni sorgente eseguiva un carico di lavoro deterministico in modo che il ripristino potesse essere verificato byte per byte. Il carico di lavoro era un piccolo servizio web che rispondeva /health con HTTP 200, una tabella database di 10.000 righe con un checksum fisso noto, 50 file deterministici e un manifest della baseline SHA-256 di tutti i file. Poiché il carico di lavoro è identico a ogni esecuzione, “è tornato esattamente lo stato pre-disastro” è un controllo sì o no, non una valutazione soggettiva.

Protocollo di disastro e ripristino

Il disastro è stato una simulazione di ransomware controllata e reversibile, non malware reale. Al T0 ha codificato in base64 i file del carico di lavoro in Il disastro è stato una simulazione di ransomware controllata e reversibile, non malware reale. Al T0 ha codificato in base64 i file del carico di lavoro in .locked copie ed ha eliminato gli originali, sovrascritto ogni riga del database con un marcatore ENCRYPTED_BY_RANSOMWARE_SIM e rilasciato una nota di riscatto. Il sistema operativo è rimasto attivo per progettazione e i dati erano corrotti, quindi il ripristino poteva essere guidato dal punto di ripristino del fornitore piuttosto che da un host bloccato.

Il ripristino ha seguito un protocollo temporale fisso:

• T0, disastro dichiarato (il cronometro parte qui).
• T1, l'operatore avvia il failover (un clic sul runbook per Acronis, la prima azione di ripristino manuale per gli altri).
• T3, la VM ripristinata raggiunge il login.
• T4, l'applicazione risponde (porta aperta, health 200).
• T5, il servizio ripristinato è raggiungibile da un client esterno, ovvero l'RTO aziendale principale: RTO = T5 – T1.
• T6, l'integrità dei dati è confermata ricalcolando il manifest SHA-256 e il checksum del database rispetto alla baseline e confermando che non rimangono file .locked o note di riscatto.

I tempi provengono da due fonti, non da un cronometro. La console del fornitore fornisce da T1 a T4 (attività o registro job) e una sonda esterna da una macchina separata fornisce T5.

I tempi di ripristino sono riportati volutamente con precisioni diverse. Acronis esegue il ripristino con una singola azione automatica su runbook, quindi il suo tempo end-to-end è una finestra pulita e ripetibile; ha eseguito due esercitazioni di failover consecutive e la tabella riporta la media. I ripristini manuali restore-to-VM (Comet e MSP360) sono procedure in più fasi in cui l'operatore provisioning una destinazione, ripristina l'immagine e riconfigura la rete a mano, quindi il tempo end-to-end dipende dall'operatore ed è riportato come intervallo anziché come cifra singola. Le parti solo macchina di tali ripristini sono precise (la scrittura dell'immagine disco di Comet ha richiesto circa due minuti e il motore di ripristino di MSP360 ha prodotto l'immagine avviabile in cinque-sei minuti), ma l'intera procedura è vincolata all'operatore.

Metodologia di valutazione

Sette dimensioni ricevono un punteggio da 0 a 100 e vengono ponderate. La profondità di automazione del failover è 20%, la capacità di failover di test 10%, l'RTO end-to-end 20%, l'RPO 10%, failback e reprotect 10%, connettività e flessibilità di rete 10% e copertura delle destinazioni DR 20%. Ogni dimensione è riportata separatamente; il totale ponderato è una cifra informativa arrotondata alla decina più vicina.

Windows e Linux ricevono sottopunteggi separati e vengono mediati. Un prodotto che non supporta il disaster recovery su un sistema operativo ottiene zero in quel sottopunteggio, con la lacuna citata come risultato anziché lasciata vuota, motivo per cui il ripristino solo Windows di MSP360 si media a circa la metà del suo sottopunteggio Windows.

Le funzionalità che un prodotto non possiede sono valutate per assenza e citate (per esempio, la mancanza di un motore di failover in Comet e MSP360 azzera le loro dimensioni di automazione e failover di test). “Per assenza” significa che la funzione non esiste, confermato rispetto al prodotto, piuttosto che una dimensione non testata.

Punteggi per categoria

I punteggi sono la media dei sottopunteggi Windows e Linux. Acronis e Comet supportano il disaster recovery su entrambi i sistemi operativi, quindi la loro media equivale al punteggio per singolo OS. MSP360 supporta il ripristino basato su immagine su Windows, non su Linux, quindi il suo sottopunteggio Linux è 0 e ogni dimensione viene dimezzata.

Il divario tra Acronis e gli altri due è concentrato in tre dimensioni: automazione del failover (DR1), failover di test (DR2) e connettività (DR6). Sono le dimensioni fornite da un vero motore DRaaS e non da un prodotto di backup. Queste tre colonne da sole rappresentano 38 punti del vantaggio di Acronis su Comet.

La copertura delle destinazioni non è l'elemento che separa i prodotti. Acronis e MSP360 raggiungono ciascuno sei tipi di destinazione su sette, Comet cinque, ma gli insiemi differiscono: Acronis include il proprio cloud gestito, AWS EC2 (migrazione documentata restore-to-EC2), Azure, hypervisor on-premises, cross-region e cross-cloud, mancando solo di Google Compute Engine; MSP360 non ha un cloud gestito ma raggiunge nativamente tutti e tre i cloud pubblici, AWS, Azure e Google Compute Engine, oltre agli hypervisor on-premises. Il prodotto più debole sull'automazione eguaglia quindi il più forte sulla copertura grezza, che è il punto: la differenza che decide il benchmark è l'automazione, non l'ampiezza.

La colonna dimezzata di MSP360 è un artefatto della copertura del sistema operativo, non di un ripristino Windows più debole. Solo su Windows, MSP360 ottiene lo stesso 70 nell'RTO end-to-end di Comet su Linux, perché entrambi eseguono la stessa classe di restore-to-VM manuale. La media cross-OS scende a 21 perché MSP360 non può affatto eseguire il ripristino basato su immagine su Linux.

Limitazioni e ambito

L'aspetto di disaster recovery è stato testato su macchine virtuali cloud senza virtualizzazione annidata, quindi qualsiasi funzione che richieda un hypervisor locale (la verifica del ripristino Hyper-V di MSP360, le destinazioni di replica on-premises) è stata valutata dalla documentazione e dall'interfaccia del prodotto piuttosto che eseguita. La dimensione connettività è stata provata praticamente in modalità solo cloud; le modalità VPN e IPsec sono state valutate da console e documentazione.

Ulteriori letture

• Benchmark dei software di backup: Acronis vs NinjaOne vs Comet vs MSP360
• Le migliori 7 soluzioni di backup SaaS
• Backup di Google Workspace: NinjaOne vs Acronis vs CloudAlly

Cita questa ricerca

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark di disaster recovery: Acronis vs Comet vs MSP360}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Consultato il 10 settembre 2026}
}

Registro delle modifiche

1 aggiornamenti

2026

1. 3 lug

   Sostituito i pesi delle dimensioni di punteggio nella metodologia del benchmark di disaster recovery.

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento