Benchmark sul 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 acquisito l'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 recuperato l'intera macchina su un server separato dopo che un disastro in stile ransomware ha cifrato i dati.

Risultati del benchmark sul disaster recovery

Cosa significa ogni colonna:

• Punteggio ponderato: il totale della rubrica sulle sette dimensioni, riportato come riferimento; il benchmark valuta ogni dimensione singolarmente.
• Tempo di ripristino: il tempo di recupero end-to-end (RTO), dalla dichiarazione del failover alla risposta del servizio ripristinato a un probe esterno.
• Rilevamento del failover: indica se il prodotto può eseguire un failover di test e confermare che la macchina ripristinata si è avviata, da un controllo automatico dello screenshot al nulla assoluto.
• 3rd-party integrations: 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: indica se il prodotto orchestra il failover (un server di ripristino e un runbook) o si limita a ripristinare manualmente un backup.

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

I risultati chiave:

• Acronis ha recuperato il server cifrato in 73 secondi su Windows e circa 108 secondi su Linux con un singolo clic sul runbook. Il carico di lavoro si è avviato su un nuovo server nel cloud del fornitore, ha ricevuto automaticamente un IP pubblico ed è tornato pulito byte per byte.
• Comet e MSP360 non hanno un motore di failover. Il ripristino è un restore manuale verso VM che ha richiesto decine di minuti e un operatore a ogni passaggio: provisioning di un target, scrittura dell'immagine disco, riconfigurazione della rete, riavvio.
• Tutti e tre hanno prodotto un ripristino esatto 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 confrontati

Acronis Cyber Protect Cloud

Acronis è l'unico prodotto del test con 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 failover di test automatici. Ottiene il suo punteggio su automazione, velocità di ripristino e copertura delle destinazioni, mentre il suo limite principale è il failback basato su agente.

Profondità dell'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, varchi di approvazione manuale e runbook annidati. Il dashboard di conformità monitora gli obiettivi RPO, i dispositivi idonei e la quota di punti di calcolo. Nessun altro prodotto del 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 dello screenshot tramite intelligenza artificiale. Ha funzionato in entrambe le direzioni, dando un verdetto di errore reale su un server Linux bloccato nel ripristino del journal 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 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 esatto byte per byte rispetto alla baseline pre-disastro.

RPO

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

Failback e riprotezione

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

Connettività e flessibilità di rete

La modalità solo cloud non richiede alcun appliance VPN. OpenVPN site-to-site, IPsec multi-sito, VPN point-to-site, IP pubblico per server e DNS personalizzato sono tutti disponibili. Non è presente alcun reindirizzamento integrato dei record A DNS pubblici.

Copertura dei target DR

Sei delle sette destinazioni. Un sito DR gestito in Acronis Cloud o Azure, Instant Restore verso VMware e Hyper-V on-premises, ripristino su hardware fisico diverso e una migrazione documentata restore-to-EC2 verso l'account AWS del cliente. Il failover orchestrato stesso viene eseguito in Acronis Cloud 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 di affidabilità. Il ripristino pulito ed esatto byte per byte è stato dimostrato due volte, nella prima esercitazione (un RTO di 94 secondi con controllo di integrità superato) e nel failover di test non distruttivo. La seconda esercitazione ha evidenziato due insidie relative al punto di ripristino, nessuna delle quali è colpa del motore di ripristino. Un punto catturato mentre la sorgente era a metà di un reset si è avviato in uno stato bloccato di ripristino del journal e ha dovuto essere rifatto. L'interruzione di quel failover ha auto-ripreso il backup della sorgente, che ha catturato la sorgente 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 sta dietro, quindi sospendere il backup durante un incidente ed eseguire il failover da un punto noto come 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, perché non dispone di nessuno dei due, e ha guadagnato punti sul percorso di restore manuale verso VM e sull'ampiezza dei target di ripristino. Il ripristino dell'immagine disco funziona. Nel benchmark, ha riportato indietro un server Ubuntu colpito da ransomware, esatto byte per byte e raggiungibile dall'esterno, su un host nuovo.

Profondità dell'automazione del failover

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

Capacità di failover di test

Nessuna. L'opzione “Simula solo ripristino” 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 su dispositivo fisico, riscrittura della rete, riavvio) è durata da 15 a 25 minuti. Il server ripristinato corrispondeva al checksum pre-disastro e serviva la sua applicazione su un nuovo IP.

RPO

Backup pianificati di immagini 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 ottenere un'immagine pulita.

Failback e riprotezione

Il failback è lo stesso ripristino manuale al contrario, senza sincronizzazione delta e senza riprotezione automatica.

Connettività e flessibilità di rete

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

Copertura dei target DR

Bare metal, Hyper-V, VMware vSphere e Proxmox nativamente; AWS e Azure tramite esportazione VMDK e VHDX. Qui è emersa un'avvertenza: un'immagine di restore su file si espande fino alla dimensione completa del disco, quindi un disco sorgente della stessa dimensione 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 manuale verso VM 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 agente Linux dispone solo di backup a livello di file, senza immagine disco, quindi metà del benchmark (il ripristino Linux) vale zero. I sottopunteggi seguenti si riferiscono a Windows; il totale cross-OS è la media dei numeri di Windows con uno zero per Linux.

Profondità dell'automazione del failover

Nessun motore, nessun runbook, nessun server di ripristino. I termini “DRaaS” e “Cloud DR” sulle pagine prodotto si risolvono in un restore manuale verso VM.

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 su 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 un probe di salute esterno pulito byte per byte. Il motore di ripristino ha prodotto l'immagine avviabile in cinque o sei minuti; il resto è stato lo spostamento dell'immagine, il suo avvio e una correzione manuale della rete. End-to-end, il restore bare-metal verso VM è stata una procedura manuale multi-passaggio da 15 a 25 minuti, la stessa classe del ripristino Linux di Comet. Un ripristino 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 changed-block-tracking, nessuna protezione continua dei dati.

Failback e riprotezione

Ripristino completo manuale verso la sorgente, nessuna sincronizzazione delta, nessuna riprotezione automatica.

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 dei target DR

Disco fisico, Hyper-V, VMware vSphere e VirtualBox, più tutti e tre i cloud pubblici tramite le 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 verso AWS VM Import è il fallback indiretto). Il ripristino nativo su Google Cloud rende MSP360 l'unico prodotto del test a raggiungere Google Compute Engine, quindi sul conteggio grezzo dei target è pari a Acronis e supera Comet. Gli 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 ripristino bare-metal su un host BIOS è un elemento utile di questa 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 e nessun restore verso VM su Linux. Per un MSP con un parco Linux, il disaster recovery con MSP360 copre solo metà dell'infrastruttura.

Confronto delle funzionalità

Failover e orchestrazione

Integrazioni di terze parti e target di ripristino

La copertura di ripristino è simile tra i tre, ma composta in modo diverso. Acronis esegue il ripristino nel proprio cloud, Azure, su host VMware e Hyper-V on-premises e su EC2 AWS del cliente tramite una migrazione documentata restore-to-EC2, mancando solo Google Compute Engine. MSP360 non ha un 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), il che lo rende l'unico prodotto qui a supportare Google Compute Engine.

Comet raggiunge AWS e Azure esportando un VMDK o VHDX e importandolo, senza cloud gestito e senza percorso verso Google Cloud. Acronis e MSP360 raggiungono ciascuno sei dei sette tipi di destinazione e Comet cinque. Nessuno include un'integrazione di failover DNS di terze parti integrata come un reindirizzamento 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 finché un operatore non lo ha corretto. L'indirizzo vive 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 questa operazione 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 in due esecuzioni con varianza zero. L'esercitazione 1 e il failover di test non distruttivo hanno superato ciascuno un controllo di integrità T6 esatto byte per byte senza ransomware trasportato nel sistema ripristinato.

I due elementi emersi nella seconda esercitazione Linux sono stati un punto di ripristino catturato a metà reset che si è avviato in un blocco del ripristino del journal e un backup della sorgente auto-ripreso che ha inserito un punto ancora cifrato nel rifacimento, entrambi dovuti al punto di ripristino e alle operazioni piuttosto che al motore di ripristino. L'Automated Test Failover di Acronis ha rilevato autonomamente la stessa condizione di ripristino del journal in un test non distruttivo e ha restituito un verdetto di errore, un passaggio di convalida assente in Comet e MSP360, che hanno entrambi totalizzato 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 il target BIOS, consentendo a Windows ripristinato di avviarsi su firmware diverso. 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 verso il disco di destinazione era l'unico praticabile.

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 un'infrastruttura diversa dopo la perdita dell'originale, misurato in base alla rapidità con cui il servizio torna attivo (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 esatto 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 il failover, l'avvio e la rete a un essere 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 comunque 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ì il cliente recupera 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, e MSP360 arriva a parlare di “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 dei target è 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 funzione di ripristino 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 sul disaster recovery

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

Ambiente di test

Le sorgenti 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).

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

Protocollo di disastro e ripristino

Il disastro era una simulazione ransomware controllata e reversibile, non malware reale. All'istante T0 ha codificato in base64 i file del carico di lavoro in Il disastro era una simulazione ransomware controllata e reversibile, non malware reale. All'istante T0 ha codificato in base64 i file del carico di lavoro in copie .locked ed ha eliminato gli originali, ha sovrascritto ogni riga del database con un marcatore ENCRYPTED_BY_RANSOMWARE_SIM e ha rilasciato una nota di riscatto. Il sistema operativo è rimasto attivo di proposito e i dati sono stati corrotti, così il ripristino poteva essere guidato dal punto di ripristino del fornitore anziché da un host in crash.

Il ripristino ha seguito un protocollo a timestamp fissi:

• T0, disastro dichiarato (il cronometro parte qui).
• T1, l'operatore attiva 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, stato di salute 200).
• T5, il servizio ripristinato è raggiungibile da un client esterno, che rappresenta l'RTO aziendale principale: RTO = T5 – T1.
• T6, l'integrità dei dati viene confermata ricalcolando il manifest SHA-256 e il checksum del database rispetto alla baseline e confermando che non rimangano file .locked o note di riscatto.

I tempi provengono da due fonti, non da un cronometro. La console del fornitore fornisce T1 fino a T4 (il registro attività o processi), mentre un probe esterno da una macchina separata fornisce T5.

I tempi di ripristino sono riportati con precisioni diverse di proposito. Acronis esegue il ripristino con una singola azione automatizzata del 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 multi-passaggio in cui l'operatore provisioning un target, ripristina l'immagine e riconfigura la rete a mano, quindi il tempo end-to-end dipende dall'operatore e viene riportato come intervallo anziché come singola cifra. Le parti solo macchina di questi 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 la procedura completa è vincolata all'operatore.

Metodologia di punteggio

Sette dimensioni sono valutate da 0 a 100 e ponderate. La profondità dell'automazione del failover vale 20%, la capacità di failover di test 10%, l'RTO end-to-end 20%, l'RPO 10%, il failback e la riprotezione 10%, la connettività e la flessibilità di rete 10% e la copertura dei target DR 20%. Ogni dimensione è riportata separatamente; il totale ponderato è una cifra informativa arrotondata alla decina più vicina.

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

Le funzionalità che un prodotto non possiede vengono 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 funzione non esiste, confermata 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 è uguale al punteggio per singolo OS. MSP360 supporta il ripristino basato su immagini su Windows, non su Linux, quindi il suo sottopunteggio 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 un prodotto di backup no. Solo queste tre colonne rappresentano 38 punti del vantaggio di Acronis su Comet.

La copertura dei target non è il punto in cui i prodotti si distinguono. Acronis e MSP360 raggiungono ciascuno sei dei sette tipi di destinazione e Comet cinque, ma gli insiemi differiscono: Acronis dispone del cloud gestito, di AWS EC2 (migrazione documentata restore-to-EC2), di Azure, degli hypervisor on-premises, della cross-region e del cross-cloud, mancando solo Google Compute Engine; MSP360 non ha cloud gestito ma raggiunge nativamente tutti e tre i cloud pubblici, AWS, Azure e Google Compute Engine, più gli hypervisor on-premises. Il prodotto più debole sull'automazione eguaglia quindi il più forte sulla copertura grezza, e questo è 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. Sul solo Windows, MSP360 ottiene lo stesso 70 sull'RTO end-to-end di Comet su Linux, perché entrambi eseguono la stessa classe di restore manuale verso VM. La media cross-OS scende a 21 perché MSP360 non può eseguire il ripristino basato su immagini su Linux.

Limiti 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 ripristino Hyper-V di MSP360, i target di replica on-premises) è stata valutata in base alla documentazione e all'interfaccia del prodotto anziché essere eseguita. La dimensione connettività è stata provata praticamente in modalità solo cloud; 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 migliori 7 soluzioni di backup SaaS
• Google Workspace backup: 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 sul disaster recovery: Acronis vs Comet vs MSP360}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Consultato il 4 Agosto 2026}
}

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