Articolo aggiornato a settembre 2026.
La diffusione di SaaS, Microsoft 365, ambienti virtuali e workload su cloud pubblici ha reso la protezione dei dati un problema di cyber resilience, non più soltanto di backup.
In un ambiente multi-cloud, una strategia efficace deve garantire separazione dal piano di produzione, retention coerente, copie immutabili, obiettivi RPO/RTO misurabili e restore realmente testati. Druva affronta questo modello con una piattaforma SaaS di Data Resiliency, mentre Nexsys integra la tecnologia all’interno di servizi gestiti di Data Protection, backup e recovery.
Quando questo articolo è stato scritto la priorità era spostare rapidamente applicazioni e dati nel cloud. Oggi la domanda è diversa: non basta sapere dove sono i dati, bisogna poterli recuperare in modo affidabile anche dopo un attacco.
Perché il multi-cloud cambia il modo di progettare il backup
In molte aziende i dati non stanno più in un unico data center: la posta e i documenti sono in Microsoft 365 o in altre applicazioni SaaS, i server girano come macchine virtuali on-premises o in cloud, i database e le applicazioni sono distribuiti su più provider. Ogni ambiente ha console, regole di retention e responsabilità diverse.
Il modello di responsabilità condivisa è il punto da cui partire: il provider garantisce la disponibilità del servizio, ma la protezione e il recupero dei dati restano in capo all’azienda. Una cancellazione accidentale, una sincronizzazione che propaga dati cifrati o una configurazione errata diventano un problema del cliente, non del fornitore.
Il rischio più sottovalutato riguarda le identità amministrative. Se un attaccante compromette un account con privilegi elevati sul tenant o sulla console di virtualizzazione, può cancellare o cifrare sia i dati di produzione sia i backup gestiti con le stesse credenziali. Per questo il sistema di protezione deve essere separato dal piano di produzione: credenziali, ruoli e infrastruttura distinti.
5 principi per una strategia multi-cloud resiliente
I cinque principi che seguono aggiornano l’impostazione originale dell’articolo, che ragionava soprattutto in termini di consolidamento dei fornitori e automazione, alla luce delle minacce attuali.
1. Centralizzare policy e visibilità
Usare un fornitore di backup diverso per ogni piattaforma produce una visione frammentata: policy disallineate, report separati e nessuna certezza su cosa sia realmente protetto. Una piattaforma unica per SaaS, endpoint, virtual machine e workload cloud consente di applicare le stesse regole di retention, vedere lo stato dei backup da un’unica console e individuare subito i dati esclusi.
È l’approccio della piattaforma SaaS di Druva, nata come Druva Data Resiliency Cloud e oggi proposta come Druva Data Security Cloud, che protegge da un unico punto Microsoft 365, Google Workspace, endpoint e workload infrastrutturali.
2. Rendere i backup immutabili e separati dalla produzione
Un backup che l’attaccante può raggiungere non è un backup affidabile. Le copie devono essere immutabili per tutto il periodo di retention, conservate in un ambiente separato da quello di produzione e amministrate con identità dedicate, protette da autenticazione a più fattori e da ruoli con privilegi minimi.
La regola 3-2-1 resta valida come base, ma in un contesto multi-cloud va letta così: almeno una copia fuori dal perimetro del provider che ospita i dati e fuori dal controllo degli account amministrativi di produzione.
3. Definire RPO/RTO e testare realmente il restore
Ogni workload deve avere obiettivi espliciti: quanti dati si possono perdere (RPO) e in quanto tempo il servizio deve tornare disponibile (RTO). Senza questi numeri non è possibile scegliere frequenza di backup, retention e architettura di ripristino.
Gli obiettivi valgono solo se sono verificati. I test di restore vanno pianificati e documentati: ripristino di singoli file e caselle di posta, di intere macchine virtuali, di un tenant dopo una compromissione. L’automazione delle attività ripetitive, dalla schedulazione dei job alla reportistica, libera tempo proprio per queste verifiche.
4. Integrare backup, compliance e cyber recovery
Il backup è anche uno strumento di governance: retention legali, legal hold, ricerche per eDiscovery e requisiti normativi come NIS2 e GDPR dipendono dalla capacità di conservare e ritrovare i dati. Le stesse copie diventano la base del piano di cyber recovery.
In caso di ransomware servono punti di ripristino puliti, la possibilità di analizzare i backup prima di reintrodurli in produzione e un processo di recupero già provato. È il tema dei servizi di Ransomware Recovery, che collegano la tecnologia di backup alla gestione dell’incidente.
5. Passare dalla piattaforma al servizio gestito
Una piattaforma cloud-native elimina hardware, aggiornamenti e capacity planning, ma non elimina il lavoro operativo: controllo quotidiano dei job, gestione delle eccezioni, test di ripristino, aggiornamento delle policy quando cambiano applicazioni e utenti. Molte aziende non hanno le competenze o il tempo per farlo con continuità.
Un modello di Data Protection as a Service affida queste attività a un team specializzato con livelli di servizio definiti, mentre per le esigenze più operative un servizio di backup aziendale gestito garantisce monitoraggio e verifica costante delle copie.
Vuoi verificare se il tuo backup è realmente recuperabile?
Nexsys può analizzare workload, retention, RPO/RTO, isolamento delle copie e procedure di restore per definire una strategia di Data Protection coerente con il rischio aziendale.
Valuta il servizio Data Protection as a Service
Scopri il backup aziendale gestito
Conclusione
Una strategia multi-cloud di successo non si misura sul numero di piattaforme adottate, ma sulla capacità di recuperare i dati quando serve. Centralizzare le policy, isolare le copie, verificare il restore, integrare backup e compliance e affidare l’operatività a un servizio gestito sono i passaggi che trasformano il backup in cyber resilience.