Backup su larga scala: dagli indicatori di stato “verde” alla reale capacità di ripristino

Si considera spesso il backup come un controllo secondario fino a quando non diventa l’ultima risorsa disponibile.

In caso di attacco ransomware, interruzioni operative o cancellazioni accidentali, ciò che conta davvero è disporre di backup recenti e utilizzabili. L’analisi della telemetria globale di Acronis Cyber Protect relativa agli ultimi mesi del 2025 evidenzia come l’aver completato correttamente un backup non garantisce automaticamente la reale capacità di recovery.

Backup, perché non è garanzia di recovery

Da un lato, i job possono terminare oltre la finestra pianificata, riducendo l’efficacia dell’RPO, aumentando anche la pressione sugli ambienti di produzione; dall’altro, gerarchie negli ambienti MSP aumentano significativamente la complessità e il rischio di errore.

Nella settimana peggiore del periodo analizzato,l’1% dei backup più lenti ha richiesto fino a 185 minuti, mentre il5% dei backup più complessi ha impiegato tempi da 26,5 a 30,5 volte superiori rispetto a un tipico backup. Inoltre, al dodicesimo livello delle directory, il tasso di errore sale al 39,78%, rispetto al 9,5% registrato al livello precedente.

Per assicurare una reale prontezza al ripristino, le organizzazioni dovrebbero definire obiettivi misurabili, progettare pianificazioni che tengano conto dei casi più critici e ridurre la complessità operativa, rafforzando monitoraggio, governance e capacità di risposta.

I 3 fattori che rendono questo problema importante oggi

Tre fattori hanno ampliato il divario tra lo stato percepito dei backup e l’effettiva prontezza al ripristino.

Gli autori degli attacchi ransomware spesso tentano di eliminare o crittografare i backup accessibili per impedirne il ripristino.

La Cyber sercurity and Infrastructure Security Agency (CISA) statunitense raccomanda di conservare backup offline e crittografati e di testare regolarmente la disponibilità e l’integrità dei backup in scenari di ripristino di emergenza.

Anche lelinee guida di Microsoft sottolineano che gli attacchi ransomware prendono di mira i dati, i backup e la documentazione necessaria per il ripristino, fornendo indicazioni su come proteggere e verificare i backup.

Le piccole e medie imprese (PMI) e le aziende di medie dimensioni ricorrono sempre più spesso al backup come servizio gestito.

Il modello multitenancy migliora l’efficienza operativa, ma aggiunge complessità strutturale in termini di autorizzazione, isolamento, ereditarietà e osservabilità.

L’Azure Architecture Center e le linee guida AWS sul SaaS multitenant descrivono questi compromessi.

Cosa imfluenza i backup su larga scala

I sistemi su larga scala sono influenzati dal comportamento delle cosiddette ‘code’ (tail): eventi rari e lenti possono modificare i risultati complessivi. Jeffrey Dean e Luiz André Barroso hanno spiegato come episodi temporanei di elevata latenza influenzino le prestazioni su larga scala.

Le operazioni di backup mostrano dinamiche simili: anche se la maggior parte dei processi è veloce, in un parco sistemi di grandi dimensioni alcuni saranno inevitabilmente lenti ogni notte.

L’illusione della finestra di backup

Questa si verifica quando i team danno per scontato che la pianificazione all’interno di una cornice temporale implichi il completamento entro tale periodo.

Un processo può comunque essere contrassegnato come riuscito anche se termina dopo l’inizio della giornata lavorativa.

Ciò crea un rischio nascosto: contese a livello di produzione e un punto di protezione più datato del previsto.

La “trappola della profondità” dell’MSP

Questa descrive un aumento non lineare dei tassi di errore man mano che le gerarchie degli utenti diventano sempre più numerose.

La complessità della gerarchia è un indicatore della complessità amministrativa: un numero maggiore di livelli di controllo comporta un numero maggiore di confini RBAC (Role-Based Access Contro) e una maggiore complessità nell’instradamento degli alert e nella gestione delle eccezioni.

Perché la complessità diventa un moltiplicatore di errori

Le gerarchie molto strutturate possono aumentare il rischio di errore perché rendono più complessa la gestione operativa.

Con l’ingresso di nuovi client e configurazioni non standard, le eccezioni alle policy tendono ad accumularsi, creando possibili disallineamenti tra pianificazioni, credenziali e regole di conservazione.

Inoltre, gli alert possono essere inviati ai team che non dispongono delle autorizzazioni necessarie per intervenire rapidamente, con il rischio di prolungare i tempi di risoluzione e far ripetere gli stessi problemi.

La crescente eterogeneità degli ambienti, delle reti e delle destinazioni di backup rende più difficile standardizzare le configurazioni, mentre pianificazioni simili tra diversi sub-tenant possono generare picchi di carico e accentuare ritardi e sovrapposizioni.

Per l’utente finale, questo rende fondamentali report specifici sul proprio ambiente, indicatori come il completamento entro la finestra prevista, l’età effettiva dell’ultimo punto di ripristino e i risultati dei test di restore.

Sono inoltre necessari SLA di escalation chiari, responsabilità definite, policy standardizzate con eccezioni documentate e verifiche periodiche delle impostazioni ereditate, oltre a una pianificazione della capacità che consideri i picchi di utilizzo e i comportamenti più critici.

Effetto combinato: come le flotte “verdi” accumulano rischi

I due fenomeni si rafforzano a vicenda: i backup con tempi di esecuzione più lunghi superano la finestra prevista, mentre le gerarchie amministrative complesse rendono più difficile individuare e risolvere rapidamente i problemi.

Il risultato può essere un sistema apparentemente stabile, con dashboard prevalentemente positive, che però accumula nel tempo un rischio crescente per la capacità di ripristino.

Le pianificazioni vengono spesso definite sulla base dei tempi di esecuzione tipici, ma una parte dei job richiede tempi più lunghi e termina in ritardo pur risultando tecnicamente riuscita.

I ritardi possono sovrapporsi ai cicli successivi o alle attività dell’inizio della giornata, aumentando il carico e generando un effetto a catena che rende più probabili ulteriori rallentamenti.

Di conseguenza, l’ultimo punto di ripristino realmente disponibile può essere più vecchio di quanto previsto, anche se il backup risulta completato con successo. Le gerarchie profonde aggravano il problema perché policy, eccezioni, alert e responsabilità sono distribuiti su più livelli.

Questo può rallentare la remediation, rendere meno chiara la responsabilità degli interventi e far sì che errori intermittenti si ripetano senza essere risolti in modo tempestivo.

In caso di ransomware, outage o modifiche errate, l’effetto combinato diventa evidente: i recovery point sono meno recenti del previsto, i restore richiedono più tempo e quelli che sembravano piccoli problemi operativi notturni possono trasformarsi in un impatto concreto sul business.

Alcune raccomandazioni

Le raccomandazioni si rivolgono sia alle aziende che gestiscono direttamente i backup sia a quelle che si affidano a un provider.

Il primo passo è definire risultati di recovery chiari e misurabili per ciascuna tipologia di carico di lavoro, stabilendo entro quale orario il backup debba essere completato per risultare realmente utile al business.

Un job concluso oltre tale soglia dovrebbe essere considerato un problema operativo, anche se tecnicamente riuscito.

È quindi importante monitorare il completamento entro la finestra prevista, i tempi dei job più lenti, l’età effettiva dell’ultimo punto di ripristino disponibile e l’esito dei test di restore.

Le pianificazioni e la capacità devono essere progettate considerando i picchi e i casi più critici, non solo le prestazioni medie.

Scaglionare gli avvii, separare i workload più pesanti e prevedere risorse adeguate per notti caratterizzate da aggiornamenti, grandi variazioni di dati o attività di fine mese riduce il rischio di code e rallentamenti a catena.

Nei servizi gestiti, la governance deve essere parte integrante dell’offerta: report dettagliati sul singolo ambiente, SLA di escalation concreti, responsabilità chiare e verifiche periodiche delle policy aiutano ad intercettare eccezioni, configurazioni incoerenti e problemi derivanti da gerarchie complesse.

È inoltre utile introdurre controlli immediati al termine della finestra di backup, affinché si analizzino anche i job completati in ritardo.

Un sistema di alert differenziato per criticità e una breve revisione quotidiana delle anomalie notturne consentono di individuare i problemi prima che si accumulino.

Le capacità di ripristino

Occorre verificare la capacità di ripristino in modo continuativo. I test di restore dovrebbero essere eseguiti con regolarità su workload critici, registrando non solo l’esito ma anche i tempi di recupero e la correttezza dei dati ripristinati.

Documentazione, credenziali e procedure operative devono restare aggiornate e disponibili anche in condizioni di degrado.

Quando appropriato, è infine consigliabile mantenere copie di backup offline o logicamente isolate e testarne periodicamente l’effettiva recuperabilità.

I rischi della gestione dei backup su larga scala

Alcuni dati di telemetria analizzati confermano che il backup deve essere considerato un sistema operativo continuo e non una semplice attività notturna.

Pianificare i processi sulla base dei tempi medi può infatti sottostimare il reale fabbisogno operativo, poiché una parte dei job richiede tempi molto più lunghi e può terminare oltre le tempistiche utili per il business.

Inoltre, la gestione dei backup su larga scala introduce rischi di complessità non lineari: gerarchie molto profonde aumentano sensibilmente la probabilità di errore, anche se questa complessità resta spesso invisibile al cliente finale.

Di conseguenza, un servizio può apparire regolare dall’esterno, mentre le condizioni interne riducono progressivamente l’effettiva capacità di recovery.