Come testare che i tuoi backup si ripristinino davvero

La domanda che conta davvero sui tuoi backup non è «vengono eseguiti?». È «quand’è stata l’ultima volta che ne hai ripristinato uno per davvero?». Negli audit alla prima si risponde con un sì tranquillo e alla seconda con un silenzio imbarazzato. Quel silenzio è il buco: un backup che gira ogni notte senza dare errore sembra un backup che funziona, e non sempre lo è. Lo sai solo quando lo ripristini.

Questo articolo parla della parte che quasi nessuno fa: testare il ripristino dei backup. Preparare la prova, cronometrarla e trovare ciò che si rompe a freddo, non il giorno dell’incendio. Perché la copia che non è mai stata ripristinata non è una copia: è una promessa non verificata.

La copia che non è mai stata ripristinata non è una copia

Un job di backup che termina in verde ti dice una cosa sola: che alcuni dati sono stati letti e scritti da un’altra parte. Non dice che siano completi, che il file non sia corrotto, che il database sia coerente né che tu possa avviare un sistema con quei dati. Il «verde» misura la scrittura, non la tua capacità di recuperare. Confonderli è il falso senso di sicurezza più costoso che esista nell’IT.

Il giorno in cui devi ripristinare non è mai un martedì tranquillo. È alle tre di notte, con il ransomware già dentro o il server che non si avvia e la direzione che chiede quando si torna a fatturare. Il momento peggiore per scoprire che la copia del database era a metà, che mancava una cartella o che ripristinare 2 TB sulla tua linea richiede tre giorni. Il test di ripristino esiste perché queste scoperte avvengano oggi, a freddo e senza costi, e non allora.

Nessuno ha un problema di backup. Tutti hanno un problema di ripristini. Solo che la maggior parte non lo sa ancora.

Cos’è un test di ripristino e ogni quanto farlo

Un test di ripristino è recuperare per finta per sapere che il giorno vero puoi davvero: prendi una copia, la avvii in un ambiente controllato e verifichi che i dati ci siano, siano coerenti e il sistema funzioni. Non è guardare il report né controllare che il file pesi quanto previsto; è toccare i dati recuperati e confermare che servano. E non sono tutti uguali: ogni livello prova una cosa diversa e ha la sua frequenza sensata.

• Ripristinare un file o una cartella (mensile). La prova più economica e la più frequente nella vita reale: qualcuno ha cancellato qualcosa. Recupera un file di una settimana fa e uno di un mese fa e controlla che si apra. Valida la retention, non solo la copia di ieri notte.
• Ripristinare una casella o un account di posta (trimestrale). Prova a recuperare una casella completa o messaggi specifici, soprattutto con Microsoft 365 o Google Workspace, dove in molti credono — erroneamente — che il fornitore faccia già il backup al posto loro.
• Ripristinare un server o un’applicazione completa (trimestrale o semestrale). Avviare il file server, l’ERP o il database in isolamento e verificare che si avvii e sia coerente. Qui compaiono le dipendenze dimenticate: servizi che non si avviano, licenze, connessioni ad altre macchine.
• Recupero bare-metal o dell’intero ambiente (annuale). Ricostruire da zero, come se non fosse rimasto nulla. La vera simulazione di disastro: qui si misura davvero il tuo RTO e vengono fuori i tempi che nessuno aveva cronometrato.

La regola pratica: più è critico e difficile da ricostruire, più spesso si prova. E ogni volta che cambia qualcosa di rilevante — un server nuovo, una migrazione — bisogna ripetere la prova. Un backup che funzionava a gennaio può essere rotto dalla migrazione di marzo senza che nessuno se ne accorga.

Come impostare un test di ripristino serio

Una prova fatta male dà una tranquillità ancora peggiore che non provare. «Ho aperto un PDF della copia e si vedeva» non dimostra nulla. Una prova seria si fa in un ambiente isolato, segue un copione e produce un numero misurato, non una sensazione. Questa è la nostra checklist:

• Ambiente isolato, mai produzione. Si ripristina su una rete o una macchina separata, senza toccare i sistemi vivi. Ripristinare sulla produzione «per vedere se va» è il modo migliore per trasformare una prova in un incidente reale.
• Partire dallo scenario, non dal file. Definisci quale disastro simuli: cancellazione accidentale, server perso, ransomware che ha cifrato la produzione e le copie accessibili. Ripristina come faresti in quel giorno reale.
• Verificare il dato, non che «esiste». Che il database si apra e sia coerente, che i numeri tornino, che la data della copia sia quella prevista. Un file ripristinato che non si apre è un file perso con più passaggi.
• Cronometrare l’RTO per davvero. Misura da «decidiamo di ripristinare» a «il servizio è utilizzabile», includendo ciò che nessuno conta: scaricare la copia dall’esterno, decifrare, reinstallare, riconfigurare. Quell’orologio è il tuo RTO reale, non quello del volantino.
• Confermare l’RPO reale. Controlla quante ore di lavoro perdi con la copia che hai usato. Se copi una volta al giorno, il caso peggiore è di 24 ore. Che quel numero lo conosca e lo accetti la direzione, per iscritto.
• Documentare e confrontare con quanto concordato. Lascia traccia del risultato e confrontalo con l’RTO/RPO che l’azienda ha detto di poter sopportare. Se il piano dice otto ore e la prova ne dice ventisei, hai un problema da risolvere oggi, con calma.

Quest’ultimo punto è ciò che rende l’esercizio utile. Senza un RTO e un RPO concordati con la direzione, la prova non ha nulla con cui misurarsi e resta un aneddoto tecnico. Con essi, ogni prova ti dice se sei dentro o fuori dal margine che la tua attività sopporta.

Errori tipici che si vedono solo al ripristino

Ci sono guasti che nessun report di backup rileva, perché non avvengono durante la copia ma durante il recupero. Restano invisibili fino al giorno in cui ripristini; per questo la prova li tira fuori prima che facciano danni.

• Backup incompleti. La copia viene fatta, ma non include tutto: manca un database, una cartella condivisa o il server aggiunto otto mesi fa che nessuno ha inserito nel job. In verde da sempre; recuperi e manca proprio ciò che contava.
• Dipendenze dimenticate. Ripristini l’applicazione e non si avvia perché le manca un servizio, una versione, un certificato o la macchina vicina con cui dialogava. Recuperare un sistema quasi mai è recuperare un solo server.
• Cifratura e chiavi perse. La copia è cifrata — bene — ma la chiave era sullo stesso server che è andato perso, o nessuno sa dove si trovi. Una copia che non puoi decifrare è rumore perfettamente inutile.
• Dati incoerenti. La copia è stata presa con il database in esecuzione e senza un dump coerente: il file c’è, ma corrotto o a metà di una transazione. Lo scopri solo quando provi a montarlo.
• RTO reale insostenibile. C’è tutto ed è tutto corretto, ma ripristinarlo sulla tua linea internet richiede quattro giorni e l’attività ne regge uno. Avevi la copia; non avevi il tempo.

Nessuno si risolve comprando più dischi. Si risolvono provando: solo la prova li rende visibili mentre puoi ancora correggerli senza fretta né perdite.

Come lo fa MagicBoxDesk

Testare i ripristini a mano, con criterio e in modo periodico, è proprio il tipo di attività che un’azienda occupata nel proprio lavoro non finisce mai per fare: importante, non urgente, fino al giorno in cui è urgentissima. Per questo in MagicBoxDesk ce ne occupiamo noi. Il nostro backup gestito include ripristini testati periodicamente: non ti consegniamo un software augurandoti buona fortuna, ma un servizio che risponde del risultato. Avviamo le tue copie in un ambiente isolato in base alla loro criticità, verifichiamo che i dati siano coerenti, cronometriamo l’RTO reale e ti consegniamo un report con ciò che funziona e ciò che va sistemato prima che diventi un problema.

Tutto questo si integra con il nostro monitoraggio 24/7, che sorveglia ogni job di copia e avvisa se qualcosa fallisce — lo sai da noi, non da un disastro —, e con il resto dei servizi IT gestiti che compongono il tuo IT esternalizzato. La differenza è concreta: passi dal credere di essere protetto all’avere la prova, con data e tempi misurati.

Smetti di fidarti che la tua copia ripristini e verificalo. Richiedi un preventivo senza impegno e prepariamo i test di ripristino della tua azienda affinché nel giorno brutto tu recuperi davvero, non per fede.