Backup che si possono davvero ripristinare: come verificarlo prima del guasto

Una copia non è un ripristino

Quasi tutte le aziende hanno un backup. Molte meno sanno dire, con precisione, quanto tempo servirebbe per rimettere in funzione il gestionale se il server smettesse di rispondere domani mattina. Sono due cose diverse: la copia è un file o un insieme di file da qualche parte, il ripristino è una procedura che coinvolge sistemi, persone, accessi e tempo. La prima si può automatizzare e dimenticare. La seconda si scopre solo quando la si prova.

Il guaio è che il backup dà una sensazione di sicurezza sproporzionata rispetto a quello che garantisce davvero. Il software segnala completato, nessuno riceve errori, il pensiero si sposta altrove. Poi arriva il giorno in cui serve, e vengono a galla i dettagli: la copia contiene i dati ma non le configurazioni, oppure include il database ma in uno stato incoerente, oppure è integra ma nessuno ricorda dove sono le credenziali per accedere all'archivio.

Prima degli strumenti, tre domande

Cosa deve essere protetto, e cosa no

Fare la copia di tutto sembra la scelta prudente, ma di solito produce archivi enormi, lenti da scrivere e ancora più lenti da recuperare. Conviene partire dall'elenco dei servizi che sostengono il lavoro: il gestionale, la posta, i file condivisi, il sito, l'applicazione che usa il reparto produzione. Per ciascuno si scrive cosa serve concretamente per farlo ripartire.

• I dati applicativi, cioè database e archivi documentali, che sono la parte non ricostruibile.
• Le configurazioni: regole del web server, parametri dei servizi, certificati, voci DNS, impostazioni di rete. Sono piccole e vengono dimenticate quasi sempre.
• Le dipendenze: versioni di sistema operativo e di runtime, pacchetti, immagini dei container, chiavi e segreti necessari all'avvio.
• La documentazione che spiega dove sta ogni cosa, e che va conservata dove resta leggibile anche se il server principale non c'è più.

Quanto lavoro puoi permetterti di perdere

Se le copie vengono fatte una volta al giorno alle due di notte e il guasto capita alle sei del pomeriggio, si perde una giornata di inserimenti. Per un archivio documentale può essere accettabile, per la fatturazione o per un magazzino spesso non lo è. La frequenza dei backup non è una scelta tecnica, è una scelta di business: qualcuno deve dire quanto lavoro l'azienda è disposta a rifare a mano. È una domanda scomoda, ma è meglio farla in una riunione tranquilla che in una mattinata di emergenza.

Quanto tempo puoi restare fermo

L'altra faccia della stessa medaglia è la durata dell'interruzione. Recuperare centinaia di gigabyte da un archivio remoto richiede tempo, e a quel tempo vanno sommate la reinstallazione dell'ambiente, la riconfigurazione dei servizi e le verifiche prima di riaprire agli utenti. Se il risultato è un'intera giornata di fermo e l'azienda non può permettersela, non serve un backup diverso: serve una strategia diversa, con copie più vicine ai sistemi o un ambiente già pronto ad accogliere il ripristino.

Gli inciampi che si scoprono sempre troppo tardi

• Il database copiato a caldo senza dump coerente. I file esistono, ma non ripartono. Vale per PostgreSQL, MySQL e SQL Server allo stesso modo: ognuno ha il suo modo corretto di produrre una copia consistente.
• La copia che vive accanto all'originale. Se sta sullo stesso server, o sullo stesso sistema di archiviazione, condivide anche i suoi guasti. Serve almeno una copia separata, su un supporto o un servizio diverso.
• I volumi dei container non inclusi. L'immagine si ricostruisce, i dati che ci stanno dentro no.
• Le notifiche che nessuno guarda. Un lavoro fallito da settimane in una casella di posta piena vale quanto un backup mai configurato.
• Le credenziali dell'archivio custodite solo nel sistema da ripristinare. Un cerchio che si chiude nel momento peggiore.

Come si organizza una prova di ripristino

Provare non significa mettere a rischio la produzione. Significa scegliere un servizio, prendere una copia recente e ricostruirlo altrove, in un ambiente separato, seguendo la procedura scritta e non la memoria di chi lo ha configurato.

1. Si sceglie il servizio da provare e si fissa una data, come per qualsiasi altra attività pianificata.
2. Si recupera la copia dall'archivio, misurando quanto tempo serve davvero a scaricarla.
3. Si ricostruisce l'ambiente su un sistema di prova, annotando ogni passaggio che la procedura non prevedeva.
4. Si verifica il contenuto con qualcuno che conosce i dati: non basta che il servizio si avvii, devono esserci i documenti giusti e le ultime registrazioni.
5. Si scrive il tempo complessivo impiegato e si aggiorna la procedura con quello che è emerso.

Il valore della prova non sta nel successo, sta in ciò che non ha funzionato. Ogni passaggio mancante trovato in una simulazione è un passaggio che non dovrai improvvisare durante un fermo reale.

Scriverlo, altrimenti resta nella testa di una persona

Una procedura di ripristino utile indica dove sono le copie, come si accede all'archivio, in che ordine vanno riavviati i servizi, chi va avvisato e chi dichiara chiuso l'intervento. Deve essere comprensibile a un tecnico che non ha costruito quel sistema, perché nel giorno del guasto la persona che lo conosce meglio potrebbe essere in ferie o al telefono con un fornitore. Va conservata fuori dall'infrastruttura che descrive e riletta dopo ogni cambiamento importante.

Da dove partire, se oggi non c'è niente di tutto questo

Non serve un progetto lungo mesi. Si prende il servizio più critico, si verifica che la copia esista e sia leggibile, si prova a ripristinarlo altrove una volta sola. Quella singola prova dice più di qualsiasi report: dove sono i buchi, quanto tempo serve, chi sa fare cosa. Poi si ripete con il secondo servizio, e si trasforma la verifica in un appuntamento periodico invece che in una reazione allo spavento.

Definire quali dati proteggere, come rimettere in funzione i servizi e con quale frequenza verificare i recuperi è parte della gestione ordinaria di un'infrastruttura, non un'attività straordinaria. Se vuoi capire a che punto sei, puoi confrontarti con noi di Forgiant partendo da un'analisi dei sistemi che hai già.