Benchmark di Disaster Recovery: Acronis vs Comet vs MSP360

Abbiamo confrontato Acronis Cyber Protect Cloud, Comet Backup e MSP360 Managed Backup sul disaster recovery. Ogni fornitore ha creato un'immagine di un Windows Server 2022 in esecuzione e di un server Ubuntu 24.04 in esecuzione con lo stesso carico di lavoro deterministico, un servizio web, un database da 10.000 righe e 50 file, per poi recuperare l'intera macchina su un server separato dopo che un disastro di tipo ransomware aveva cifrato i dati.

Risultati del benchmark di disaster recovery

Cosa significa ciascuna colonna:

• Punteggio ponderato: il totale della griglia di valutazione sulle sette dimensioni, riportato come riferimento; il benchmark valuta ciascuna dimensione separatamente.

• Tempo di ripristino: il tempo di ripristino end-to-end (RTO), dalla dichiarazione del failover fino al servizio ripristinato che risponde a una sonda esterna.

• Rilevamento failover: se il prodotto può eseguire un failover di test e confermare che la macchina ripristinata si è avviata, da un controllo automatico con screenshot fino alla totale assenza di verifica.

• Integrazioni di terze parti: su quante delle sette destinazioni di ripristino (cloud del fornitore, AWS, Azure, Google Cloud, hypervisor on-premises, cross-region, cross-cloud) il prodotto può effettuare il ripristino.

• Motore DR: se il prodotto orchestra il failover (un server di ripristino e un runbook) oppure si limita a ripristinare un backup manualmente.

Consulta la metodologia completa del benchmark di disaster recovery per la griglia di punteggio e il protocollo di cronometraggio T0-T6.

Le informazioni chiave:

• Acronis ha ripristinato il server cifrato in 73 secondi su Windows e in circa 108 secondi su Linux con un solo clic sul 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 integro al byte.

• Comet e MSP360 non hanno un motore di failover. Il ripristino è un restore-to-VM manuale che ha richiesto decine di minuti e ha necessitato di un operatore a ogni passaggio: provisioning di un target, scrittura dell'immagine disco, riconfigurazione della rete, riavvio.

• Tutti e tre hanno prodotto un ripristino integro al byte. Il manifesto SHA-256 dei 50 file e il checksum del database corrispondevano al riferimento pre-disastro in ogni caso, quindi la differenza sta nella velocità e nello sforzo dell'operatore, non nell'integrità dei dati.

Prodotti di disaster recovery sottoposti a benchmark

Acronis Cyber Protect Cloud

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

Profondità di automazione del failover

I runbook orchestrano il failover attraverso passaggi ordinati, azioni parallele all'interno di un passaggio, controlli di completamento su ping e porta, cancelli di approvazione manuale e runbook annidati. Il dashboard di conformità tiene traccia degli obiettivi RPO, dei dispositivi idonei e della quota di punti di calcolo. Nessun altro prodotto nel test codifica il ripristino anziché lasciarlo a un operatore.

Capacità di failover di test

Il failover di test non dirompente avvia il server di ripristino su una rete isolata e il Test Failover Automatizzato convalida un avvio programmato con un controllo IA basato su screenshot. Ha funzionato in entrambe le direzioni, restituendo un verdetto di fallimento reale su un server Linux bloccato nel journal recovery e un successo reale su un avvio pulito di Windows.

RTO end-to-end

73 secondi su Windows, circa 108 secondi su Linux (94 e 121 nelle due esercitazioni). Un clic sul runbook avvia il server di ripristino, assegna un IP pubblico e rende disponibile l'applicazione ripristinata. Lo stato ripristinato era integro al byte rispetto al riferimento 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, commutazione, convalida) con il server cloud che rimane attivo durante il trasferimento. Il ritorno all'hardware originale richiede un supporto avviabile e un reprotect manuale.

Connettività e flessibilità di rete

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

Copertura delle destinazioni DR

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

Una nota sull'affidabilità è emersa dalle esercitazioni. Il ripristino pulito e integro al 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 dirompente. La seconda esercitazione ha fatto emergere due inconvenienti relativi al punto di ripristino, nessuno dei quali imputabile al motore di ripristino. Un punto catturato mentre l'origine era a metà riavvio si è avviato in uno stato di journal recovery bloccato e ha dovuto essere rifatto. L'arresto di quel failover ha riavviato automaticamente il backup dell'origine, che ha catturato l'origine ancora cifrata, quindi il rifacimento si è avviato in tempo ma è atterrato su quel nuovo punto cifrato. Il server di ripristino non è migliore del punto di ripristino che lo alimenta, quindi mettere in pausa il backup durante un incidente ed eseguire il failover da un punto notoriamente pulito è la sequenza più sicura.

Comet Backup

Comet è un prodotto di backup senza un motore di disaster recovery. Ha ottenuto 0 su automazione del failover e failover di test, perché non ha né l'uno né l'altro, e ha guadagnato i suoi punti sul percorso manuale di restore-to-VM e sull'ampiezza delle destinazioni di ripristino. Il suo restore dell'immagine disco funziona. Nel benchmark, ha riportato in vita un server Ubuntu colpito da ransomware, integro al byte e raggiungibile esternamente, su un nuovo host.

Profondità di automazione del failover

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

Capacità di failover di test

Nessuna. L'opzione "Simula solo il restore" 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 rescue, installazione dell'agent, restore su dispositivo fisico, riscrittura della rete, riavvio) ha richiesto da 15 a 25 minuti. Il server ripristinato corrispondeva al checksum pre-disastro e ha reso disponibile la sua applicazione a un nuovo IP.

RPO

Backup pianificati di immagini disco con incrementali, nessuna protezione continua dei dati. Il primo backup del volume radice in esecuzione ha riempito lo storage differenziale e ha richiesto il quiescing del carico di lavoro per un'immagine pulita.

Failback e reprotect

Il failback è lo stesso restore manuale al contrario, senza sincronizzazione delta e senza reprotect automatizzato.

Connettività e flessibilità di rete

Nessuna rete DR. La macchina ripristinata conservava il netplan statico con MAC dell'origine, che abbiamo riscritto a mano con l'indirizzo dell'host di ripristino prima che potesse diventare raggiungibile.

Copertura delle destinazioni DR

Bare metal, Hyper-V, VMware vSphere e Proxmox in modo nativo; AWS e Azure tramite esportazione VMDK e VHDX. Qui è emersa una limitazione: un'immagine restore-to-file si espande fino alla dimensione completa del disco, quindi il disco di origine della stessa dimensione non può contenere il file intermedio, il che ha reso obbligatorio il percorso di restore 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 suo punteggio cross-OS è basso perché il suo agent Linux non dispone di backup di immagini, quindi metà del benchmark (il ripristino Linux) ottiene zero. I sotto-punteggi seguenti sono per 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. I termini "DRaaS" e "Cloud DR" sulle sue 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, che è più di una prova a secco, ma richiede Hyper-V locale (assente sugli host di test cloud) e convalida un backup anziché eseguire il failover verso un sito di ripristino.

RTO end-to-end

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

RPO

Backup pianificati di immagini con incrementali a changed-block-tracking, nessuna protezione continua dei dati.

Failback e reprotect

Restore completo manuale verso l'origine, nessuna sincronizzazione delta, nessun reprotect automatizzato.

Connettività e flessibilità di rete

Nessuna rete DR. Il server ripristinato si è avviato con l'IP statico della macchina di origine ed è rimasto 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 restore: Restore su Amazon EC2, Restore su VM Azure e Restore su istanza Google Cloud (l'esportazione di immagini verso AWS VM Import è l'alternativa indiretta). Il restore nativo su Google Cloud rende MSP360 l'unico prodotto nel test a raggiungere Google Compute Engine, quindi per conteggio grezzo delle destinazioni eguaglia Acronis e supera Comet. Manca solo il cloud DR gestito dal fornitore, di cui non dispone affatto. La conversione da GPT a BIOS/MBR che ha permesso l'avvio del restore bare metal su un host BIOS è un elemento utile di questa ampiezza.

La lacuna Linux è la limitazione decisiva. L'agent Linux di MSP360 esegue solo backup a livello di file, senza immagini 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à dell'infrastruttura.

Confronto delle funzionalità

Failover e orchestrazione

Integrazioni di terze parti e destinazioni di ripristino

La copertura delle destinazioni 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 restore-to-EC2 documentata, mancando solo Google Compute Engine. MSP360 non ha un cloud gestito ma supporta nativamente tutti e tre i cloud pubblici (la sua procedura guidata di restore offre Restore su EC2, VM Azure e istanza Google Cloud), rendendolo l'unico prodotto qui che supporta Google Compute Engine.

Comet raggiunge AWS e Azure esportando un VMDK o VHDX e importandolo, senza cloud gestito e senza un percorso per Google Cloud. Acronis e MSP360 arrivano ciascuno a sei dei sette tipi di destinazione e Comet a cinque. Nessuno include un'integrazione nativa di failover DNS di terze parti come il reroute automatico dei record in stile Cloudflare; Acronis fornisce DNS personalizzato e modalità VPN, e 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 restore manuale

Su entrambi i prodotti manuali, il server ripristinato si è avviato con l'IP statico della macchina di origine, non con quello dell'host di ripristino, ed è rimasto irraggiungibile sulla rete finché un operatore non ha risolto il problema. L'indirizzo risiede all'interno dell'immagine disco, quindi viaggia con il restore. Su Comet (Linux) abbiamo riscritto la configurazione netplan nell'ambiente di rescue; su MSP360 (Windows) abbiamo effettuato l'accesso al server avviato tramite la console cloud e impostato manualmente l'IP statico. Un DRaaS gestisce questo aspetto come parte del failover; un restore 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 in due esecuzioni con varianza zero. L'esercitazione 1 e il failover di test non dirompente hanno ciascuno superato un controllo di integrità T6 byte-esatto senza alcun ransomware trasportato nel sistema ripristinato.

I due elementi emersi nella seconda esercitazione Linux sono stati un punto di ripristino catturato a metà riavvio che si è avviato in un blocco del journal recovery e un backup dell'origine riavviato automaticamente che ha inserito un punto ancora cifrato nel rifacimento, entrambi problemi del punto di ripristino e operativi, non guasti del motore di ripristino. Il Test Failover Automatizzato di Acronis ha rilevato indipendentemente la stessa condizione di journal recovery in un test non dirompente e ha restituito un verdetto di Fallimento, un passaggio di convalida assente in Comet e MSP360, che hanno entrambi ottenuto 0 nel failover di test.

Conversione da UEFI a BIOS durante il restore

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

Backup versus disaster recovery

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 un'infrastruttura diversa dopo che l'originale è andato perso, misurato in base alla velocità con cui il servizio ritorna (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 restore integro al 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 il failover, l'avvio e la rete a un operatore umano, motivo per cui il loro ripristino ha richiesto decine di minuti e le loro 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)?

Disaster-recovery-as-a-service significa che il fornitore ospita l'ambiente di ripristino e orchestra il failover, così che il cliente recuperi 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 utilizzano etichette di disaster recovery sulle loro pagine di marketing, MSP360 spingendosi fino a "DRaaS" e "Cloud DR", per descrivere una cosa diversa, un restore manuale di un'immagine disco su una macchina virtuale o un'istanza cloud che il cliente provisiona 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" è la funzionalità di restore del prodotto di backup sotto un'etichetta di 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à di backup, quindi ogni prodotto ha eseguito lo stesso ciclo di vita di ripristino: installazione dell'agent, acquisizione di un'immagine pulita di un server in esecuzione, attivazione di un disastro su quel server, ripristino su una macchina separata e verifica dello stato ripristinato rispetto a un riferimento noto. I tempi di backup delle immagini sono riportati come tempo trascorso, non come throughput.

Ambiente di test

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

Ciascuna origine eseguiva un carico di lavoro deterministico in modo che il ripristino potesse essere verificato byte per byte. Il carico di lavoro consisteva in un piccolo servizio web che rispondeva con HTTP 200, una tabella di database di 10.000 righe con un checksum fisso noto, 50 file deterministici e un manifesto SHA-256 di riferimento di tutti questi elementi. Poiché il carico di lavoro è identico in ogni esecuzione, "lo stato esatto pre-disastro è tornato" è un controllo sì-o-no, non un giudizio discrezionale.

Protocollo di disastro e ripristino

Il disastro era una simulazione di ransomware controllata e reversibile, non malware reale. A T0 ha codificato in base64 i file del carico di lavoro in Il disastro era una simulazione di ransomware controllata e reversibile, non malware reale. A T0 ha codificato in base64 i file del carico di lavoro in copie e ha eliminato gli originali, ha sovrascritto ogni riga del database con un marcatore , e ha rilasciato una nota di riscatto. Il sistema operativo è rimasto attivo per progettazione, e i dati erano corrotti, così che il ripristino potesse essere guidato dal punto di ripristino del fornitore anziché da un host in crash.

Il ripristino ha seguito un protocollo di timestamp fisso:

• T0, disastro dichiarato (il cronometro parte qui).
• T1, l'operatore attiva il failover (un clic sul runbook per Acronis, la prima azione di restore 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, che costituisce l'RTO aziendale principale: RTO = T5 – T1.
• T6, l'integrità dei dati è confermata ricalcolando il manifesto SHA-256 e il checksum del database rispetto al riferimento e confermando che non rimangono file né la nota di riscatto.

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

I tempi di ripristino sono riportati con precisioni diverse di proposito. Acronis esegue il ripristino con un'unica azione automatizzata di 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 a più passaggi in cui l'operatore provisiona un target, 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 quei ripristini sono precise (la scrittura dell'immagine disco di Comet ha richiesto circa due minuti, e il motore di restore di MSP360 ha prodotto l'immagine avviabile in cinque-sei minuti), ma l'intera procedura è vincolata all'operatore.

Metodologia di punteggio

Sette dimensioni sono valutate da 0 a 100 e ponderate. La profondità di automazione del failover pesa 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 è un dato informativo arrotondato alla decina più vicina.

Windows e Linux sono valutati come sotto-punteggi separati e mediati. Un prodotto che non supporta il disaster recovery su un sistema operativo ottiene zero su quel sotto-punteggio, con la lacuna citata come riscontro anziché lasciata vuota, motivo per cui il ripristino solo Windows di MSP360 ha una media pari a circa la metà del suo sotto-punteggio Windows.

Le capacità che un prodotto non possiede sono valutate per assenza e citate (ad 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 funzionalità non esiste, confermato rispetto al prodotto, piuttosto che una dimensione lasciata non testata.

Punteggi per categoria

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

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

La copertura delle destinazioni non è il punto in cui i prodotti si differenziano. Acronis e MSP360 raggiungono ciascuno sei dei sette tipi di destinazione, e Comet cinque, ma gli insiemi differiscono: Acronis porta il suo cloud gestito, AWS EC2 (migrazione restore-to-EC2 documentata), Azure, hypervisor on-premises, cross-region e cross-cloud, mancando solo 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, il che è il punto: la differenza che decide il benchmark è l'automazione, non l'ampiezza.

La colonna dimezzata di MSP360 è un artefatto della copertura dei sistemi operativi, non di un ripristino Windows più debole. Solo su Windows, MSP360 ottiene lo stesso 70 nell'RTO end-to-end che Comet ottiene 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 immagini su Linux.

Limitazioni e ambito

Il lato disaster recovery è stato testato su macchine virtuali cloud senza virtualizzazione annidata, quindi qualsiasi funzionalità che richieda un hypervisor locale (la verifica del restore Hyper-V di MSP360, i target di replica on-premises) è stata valutata in base alla documentazione e all'interfaccia utente del prodotto anziché eseguita. La dimensione della connettività è stata esercitata in modalità solo cloud in modo pratico; le modalità VPN e IPsec sono state valutate dalla console e dalla documentazione.

Ulteriori letture

• Benchmark dei software di backup: Acronis vs NinjaOne vs Comet vs MSP360
• Le 7 migliori 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  = jul,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Consultato il 20 Luglio 2026}
}

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

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