Benchmark di disaster recovery: Acronis vs Comet vs MSP360

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

Risultati del benchmark di disaster recovery

Cosa significa ciascuna colonna:

• Punteggio ponderato: il totale della rubrica su sette dimensioni, riportato per riferimento; il benchmark assegna un punteggio a ciascuna dimensione separatamente.

• 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 failover: se il prodotto può eseguire un failover di test e confermare l'avvio della macchina ripristinata, da un controllo automatico con screenshot fino all'assenza totale.

• Integrazioni di 3ª parte: su sette destinazioni di recupero (cloud del fornitore, AWS, Azure, Google Cloud, hypervisor on-premises, cross-region, cross-cloud) a quante può eseguire il recupero.

• 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 completa per la rubrica di punteggio e il protocollo di temporizzazione T0-T6.

Le informazioni chiave:

• Acronis ha ripristinato il server crittografato in 73 secondi su Windows e circa 108 secondi su Linux con un solo clic sul runbook. Il carico di lavoro si è avviato su un server nuovo all'interno del 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-to-VM manuale che ha richiesto decine di minuti e ha comportato l'intervento dell'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 al riferimento pre-disastro in ogni caso, quindi la differenza è nella velocità e nell'impegno dell'operatore, non nell'integrità dei dati.

Prodotti di disaster recovery testati

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, esegue il failover da un runbook e convalida il risultato con failover di test automatizzato. Ottiene il suo punteggio in automazione, velocità di ripristino e copertura dei target, e il suo principale limite è il failback basato su agent.

Profondità dell'automazione del failover

I runbook orchestrano il failover attraverso passaggi ordinati, azioni parallele all'interno di un passaggio, controlli di completamento tramite ping e porta, gate 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 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 il Test Failover Automatizzato convalida un avvio pianificato con un controllo screenshot basato su IA. Ha funzionato in entrambe le direzioni, restituendo un verdetto di fallimento reale su un server Linux che si bloccava nel ripristino del journal e un vero successo 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 solo 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 al riferimento 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 reprotect

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

Connettività e flessibilità di rete

La modalità solo cloud non necessita di appliance VPN. Sono disponibili OpenVPN site-to-site, IPsec multi-sito, VPN point-to-site, IP pubblico per server e DNS personalizzato. Non è presente il reindirizzamento automatico del record A DNS pubblico.

Copertura dei target DR

Sei target su sette. Un sito DR gestito in Acronis Cloud o Azure, Instant Restore su VMware on-premises e Hyper-V, 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.

Un'annotazione sull'affidabilità è emersa dalle esercitazioni. Il ripristino pulito byte per byte è stato dimostrato due volte, nella prima esercitazione (un RTO di 94 secondi con un controllo di integrità positivo) e nel failover di test non distruttivo. La seconda esercitazione ha evidenziato due criticità legate al punto di ripristino, nessuna delle quali imputabile al motore di ripristino. Un punto catturato mentre la sorgente era in fase di riavvio ha avviato uno stato di ripristino del journal bloccato e si è dovuto rifare. L'interruzione di quel failover ha auto-ripreso il backup della sorgente, che ha catturato la sorgente ancora crittografata, quindi il rifacimento si è avviato in tempo ma è arrivato su quel nuovo punto crittografato. Il server di ripristino non è migliore del punto di ripristino dietro di esso, quindi mettere in pausa 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 un motore di disaster recovery. Ha ottenuto 0 nell'automazione del failover e nel failover di test, perché non ne ha, e ha guadagnato i suoi punti sul percorso manuale restore-to-VM e sull'ampiezza dei target di ripristino. Il suo ripristino dell'immagine disco funziona. Nel benchmark, ha riportato un server Ubuntu colpito da ransomware, esatto byte per byte e raggiungibile esternamente, 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 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 ripristino" della procedura guidata di ripristino è un'esecuzione a secco che non avvia una macchina, quindi non c'è un failover di test da valutare.

RTO end-to-end

La scrittura dell'immagine disco su un disco di un server nuovo ha richiesto circa due minuti, ma la procedura completa (avvio di ripristino, installazione agent, restore-to-physical-device, riscrittura rete, riavvio) ha richiesto da 15 a 25 minuti. Il server ripristinato corrispondeva al checksum pre-disastro e ha servito la sua 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 che il carico di lavoro venisse quiesciuto per ottenere un'immagine pulita.

Failback e reprotect

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

Connettività e flessibilità di rete

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

Copertura dei target DR

Bare metal, Hyper-V, VMware vSphere e Proxmox in modo nativo; AWS e Azure tramite esportazione VMDK e VHDX. Una limitazione è emersa qui: un ripristino su file dell'immagine si espande fino alla dimensione completa del disco, quindi il 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-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 ha backup di immagine, quindi metà del benchmark (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à dell'automazione del failover

Nessun motore, nessun runbook, nessun server di ripristino. Le diciture "DRaaS" e "Cloud DR" sulle sue pagine prodotto si traducono 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 un'esecuzione a secco, ma richiede Hyper-V locale (assente sugli host di test cloud) e convalida un backup anziché 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, avviato Windows sul nuovo host e raggiunto un probe di integrità 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, l'avvio e una correzione manuale della rete. End-to-end, il restore-to-VM bare-metal è stata una procedura manuale multi-step di 15-25 minuti, la stessa classe del ripristino Linux di Comet. Un ripristino più semplice sul posto dei soli dati crittografati, con il server ancora in esecuzione, ha richiesto circa 10 minuti.

RPO

Backup pianificati di immagini con incrementali che tracciano i blocchi modificati, nessuna protezione continua dei dati.

Failback e reprotect

Ripristino completo manuale verso la sorgente, 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 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 opzioni native della procedura guidata di ripristino: Restore to Amazon EC2, Restore to Azure VM e Restore to Google Cloud Instance (l'esportazione di immagini verso 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 conteggio grezzo dei target pareggia con Acronis e supera Comet. Manca solo il cloud DR gestito dal fornitore, che non possiede affatto. La conversione da GPT a BIOS/MBR che ha permesso 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à dell'infrastruttura.

Confronto delle funzionalità

Failover e orchestrazione

Integrazioni di terze parti e target di ripristino

La copertura del 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 AWS EC2 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 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 un VMDK o VHDX e importandolo, senza cloud gestito e senza percorso verso Google Cloud. Acronis e MSP360 raggiungono ciascuno sei tipi di destinazione su sette e Comet cinque. Nessuno include un'integrazione di terze parti per il failover DNS integrata come un reindirizzamento 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 ripristino manuale

Su entrambi i prodotti manuali, il server ripristinato si è avviato con l'IP statico della macchina sorgente, non quello dell'host di ripristino, ed era irraggiungibile sulla rete finché 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 questa operazione come parte del failover; un ripristino manuale no.

Qualità del punto di ripristino e affidabilità del failover

L'RTO di business end-to-end ha misurato 94 secondi nella prima esercitazione di failover Linux, con un punto di ripristino 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 ciascuno superato un controllo di integrità T6 byte per byte senza ransomware portato nel sistema ripristinato.

I due elementi emersi nella seconda esercitazione Linux erano un punto di ripristino catturato durante un riavvio che si è avviato in un blocco del ripristino del journal e un backup della sorgente auto-ripreso che ha inserito un punto ancora crittografato nel rifacimento, entrambi problemi di punto di ripristino e operativi piuttosto che del motore di ripristino. Acronis Automated Test Failover ha rilevato indipendentemente la stessa condizione di ripristino del journal in un test non distruttivo 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 ripristino

L'host di ripristino MSP360 si è avviato in modalità BIOS mentre la sorgente era UEFI/GPT. Il ripristino 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 del sistema Windows ripristinato su firmware dissimile. Senza tale 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-to-target-disk era l'unico che si adattava.

Backup vs disaster recovery

Un backup è una copia dei 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 velocità di ritorno del servizio (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 funzionante su un server nuovo 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 ma non essere ancora 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, in modo 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 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 fornisce un motore di failover (un server di ripristino, un runbook, un failover di test) o se "DR" è la funzionalità 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 di disaster recovery

Il benchmark misura il disaster recovery, non il throughput del 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, 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 vengono 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. I target di ripristino erano server cloud separati della stessa classe (e, per Acronis, il cloud del fornitore stesso).

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 con /health HTTP 200, una tabella di database di 10.000 righe con un checksum fisso noto, 50 file deterministici e un manifest di riferimento SHA-256 di tutti questi. Poiché il carico di lavoro è identico a ogni esecuzione, "lo stato esatto pre-disastro è tornato" è un controllo sì o no, non un giudizio.

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 copie .locked ed 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 di proposito e i dati sono stati corrotti, in modo che il ripristino potesse essere guidato dal punto di ripristino del fornitore anziché da un host in crash.

Il ripristino ha seguito un protocollo a timestamp fissi:

• T0, il disastro viene 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, integrità 200).
• T5, il servizio ripristinato è raggiungibile da un client esterno, che è l'RTO di business principale: RTO = T5 – T1.
• T6, l'integrità dei dati viene confermata ricalcolando il manifest SHA-256 e il checksum del database rispetto al riferimento 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 da T1 a T4 (il log delle attività o dei processi), e un probe esterno da una macchina separata fornisce T5.

I tempi di ripristino sono riportati con precisioni diverse di proposito. Acronis ripristina 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 restore-to-VM manuali (Comet e MSP360) sono procedure multi-step 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 ed è riportato come un intervallo piuttosto che come una cifra singola. 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 o sei minuti), ma la procedura completa dipende dall'operatore.

Metodologia di punteggio

Sette dimensioni sono valutate da 0 a 100 e ponderate. La profondità dell'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 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 sotto-punteggi separati e poi 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 in bianco, motivo per cui il ripristino solo Windows di MSP360 si attesta in media circa alla metà del suo sotto-punteggio Windows.

Le capacità che un prodotto non ha 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 funzionalità non esiste, confermata rispetto al prodotto, piuttosto che una dimensione non testata.

Punteggi di 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 è uguale al 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 si concentra 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 è dove i prodotti si differenziano. Acronis e MSP360 raggiungono ciascuno sei tipi di destinazione su sette, 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, più hypervisor on-premises. Il prodotto più debole nell'automazione eguaglia quindi il più forte nella 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 del sistema operativo, non di un ripristino Windows più debole. Solo su Windows, MSP360 ottiene lo stesso 70 in 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ò eseguire affatto il ripristino basato su immagini su Linux.

Limitazioni e ambito

Il lato del 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 dalla documentazione e dall'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 software di backup: Acronis vs NinjaOne vs Comet vs MSP360
• Le 7 migliori soluzioni di backup SaaS
• Backup 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  = aug,
  howpublished    = {\url{https://aimultiple.com/disaster-recovery-solutions}},
  note   = {AIMultiple. Consultato il 4 Agosto 2026}
}

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è un Ricercatore AI e Analista di Dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI 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