Backup aziendale: cosa deve contenere oltre ai documenti
Le cartelle condivise sono la parte facile. Ciò che manca, il giorno del guasto, sta quasi sempre altrove: database, configurazioni, certificati, accessi.
Backup aziendale: cosa c'è oltre ai documenti
Oltre ai documenti, un backup aziendale deve contenere ciò che serve per rimettere in piedi i servizi: database, configurazioni di server e rete, certificati e chiavi, zone DNS, macchine virtuali, volumi dei container, utenti e permessi. Senza questi pezzi si recupera il materiale, ma non il sistema che lo usa.
Il caso tipico è questo. Il server si rompe, si ripristina la cartella con i file, e il gestionale continua a non partire. I dati ci sono, ma l'applicazione non sa più a quale database collegarsi, il certificato è scaduto o perso, il nome del servizio non punta più all'indirizzo giusto. Nessuno ha sbagliato a copiare i documenti: si è solo dimenticato che sono la parte più visibile e meno fragile.
I database: la copia che sembra buona e non lo è
Un database in funzione scrive di continuo. Se si copiano i suoi file come si copia un foglio di calcolo, si può ottenere un insieme incoerente: una parte della tabella com'era prima, una parte com'era pochi istanti dopo. Il file esiste, ha una dimensione plausibile, e al ripristino il servizio si rifiuta di avviarsi o, peggio, parte con dati incoerenti.
Per PostgreSQL, MySQL e SQL Server esistono strumenti propri per produrre una copia coerente: esportazioni logiche, copie fisiche pensate per il motore, archiviazione dei registri delle transazioni. Quale usare dipende dalla dimensione del database e da quanto lavoro ci si può permettere di perdere. Una decisione da prendere una volta, per iscritto, non da scoprire durante il guasto.
Un dettaglio che si trascura: il database ha anche utenti, ruoli e permessi propri. Se la copia contiene solo le tabelle, l'applicazione si ritrova con i dati ma senza il suo accesso.
Configurazioni, certificati e DNS: i file piccoli che pesano di più
Occupano pochissimo spazio e rappresentano mesi di aggiustamenti. Il file di configurazione di Nginx o Apache con siti, reindirizzamenti e limiti. Le regole del firewall. Le impostazioni della VPN. Le attività pianificate sul server, e gli script che qualcuno ha scritto anni fa e che ogni notte fanno qualcosa di indispensabile.
Poi ci sono i certificati TLS e le relative chiavi private. Un certificato in genere si può riemettere, ma se un dispositivo o un'integrazione di un fornitore si aspetta proprio quello, riemetterlo significa coordinare più persone. Le chiavi vanno copiate, e quella copia va protetta più delle altre, perché chi la ottiene può spacciarsi per il vostro servizio.
Il DNS merita una riga a parte. Le zone, gestite da voi o da un fornitore, sono un elenco di record che nessuno ricorda a memoria: posta, sottodomini, verifiche di dominio, indirizzi dei servizi interni. Un'esportazione periodica costa pochi minuti e toglie un'incognita.
Macchine virtuali e container: copiare l'immagine o ricostruirla?
Con la virtualizzazione si può copiare l'intera macchina: sistema, programmi, impostazioni. Il ripristino è lineare, ma la copia è pesante e va fatta in modo da non catturare la macchina nel mezzo di una scrittura. Per i server che contano conviene tenere sia la copia della macchina sia quella dei dati applicativi, perché servono a scopi diversi: la prima per rialzare tutto, la seconda per tornare a un momento preciso.
Con Docker il ragionamento cambia. I container sono usa e getta per natura, e questo porta a un errore frequente: si pensa al container e si dimenticano i volumi, dove stanno davvero i dati. Si dimentica anche il file che descrive come i container si avviano (il compose, le variabili d'ambiente, i segreti). Senza quello, ricostruire l'ambiente vuol dire indovinarlo.
La lista di controllo del backup aziendale, servizio per servizio
Non si parte dagli strumenti, si parte da una domanda: se domani questo servizio sparisse, cosa mi serve per rimetterlo in funzione, e in che ordine? Il punto di partenza è l'inventario che viene prima degli strumenti: senza l'elenco di sistemi e dipendenze, qualunque lista di backup ha buchi che non si vedono.
Per ogni servizio essenziale:
- Dati applicativi e database, con un metodo di copia coerente.
- Configurazioni del servizio e dei suoi componenti (web server, firewall, VPN).
- Certificati e chiavi, conservati in modo protetto.
- Zone DNS e altri registri di nomi.
- Utenti, ruoli e permessi, sia del sistema sia dell'applicazione.
- Macchina virtuale o descrizione dell'ambiente a container, con i volumi.
- Licenze, versioni installate e script di rilascio.
- La procedura scritta per il ripristino, con l'ordine delle operazioni.
L'ultima voce sorprende, ma separa un recupero in un pomeriggio da uno in una settimana. Se la procedura sta solo nella testa di una persona, e quella persona è in ferie o non lavora più con voi, la copia perfetta serve a poco. Se scrivendo questa lista scoprite che nessuno in azienda sa rispondere a metà delle righe, è il segnale che gestire da soli server e copie non sta più in piedi.
Dove tenere le copie e per quanto
Una copia che sta sullo stesso server, o raggiungibile con le stesse credenziali, si perde con lui. Con un attacco che cifra i dati, può andare perduta anche la copia collegata in rete. Conviene quindi almeno una copia separata dall'ambiente principale, in un luogo diverso e non modificabile dagli stessi accessi. Non serve moltiplicarle: serve che una sopravviva al peggio. Il legame fra copie e protezione generale è trattato in sicurezza informatica aziendale: cosa protegge davvero una PMI.
Sulla conservazione la regola è pratica: tenete indietro abbastanza da accorgervi di un errore tardivo. Un file cancellato o un database corrotto spesso emergono giorni dopo, e se la copia più vecchia è di ieri, contiene già il danno. Quanto tenere indietro dipende dal servizio e dallo spazio, e va concordato, non lasciato al valore predefinito del programma.
Alcune cose si possono lasciare fuori senza rimorsi: il sistema operativo ricostruibile da un'installazione pulita, le cache, i file temporanei, gli installatori scaricabili di nuovo. Escludere è lecito se è una scelta scritta; è un problema se è una dimenticanza.
Da dove cominciare
Prendete il servizio da cui dipende di più il lavoro quotidiano, di solito il gestionale, e rispondete per iscritto a ciascuna delle otto voci. Dove la risposta è «non so», avete trovato il primo intervento. Poi fate una prova di ripristino su una macchina separata, come descritto in backup che si possono davvero ripristinare. Se vi serve un confronto sul perimetro o sul metodo, Forgiant può rivedere la lista con voi.
Domande frequenti
Il backup dei soli documenti basta per un'azienda?
Di solito no. Permette di recuperare i file, ma non di far ripartire gestionale, sito o servizi interni, che dipendono da database, configurazioni, certificati e accessi. Questi elementi vanno inclusi e provati.
Il backup di un container Docker comprende i dati?
Non necessariamente. I dati stanno nei volumi, che vanno copiati a parte, insieme ai file che descrivono come i container si avviano. Copiare solo il container lascia fuori l'essenziale.
Quanto indietro conviene conservare le copie?
Abbastanza da accorgersi di un errore scoperto in ritardo, come un database corrotto o una cancellazione notata dopo giorni. Il periodo esatto dipende dal servizio e dallo spazio disponibile, e va concordato per iscritto.