Il backup non è un file copiato in una cartella. È un restore che hai già fatto funzionare, su un altro disco, prima del disastro.
Un backup che non hai mai ripristinato è una scommessa, non una strategia. Il file copiato in una cartella, lo snapshot che "fa il pannello", il disco in RAID: nessuno di questi oggetti, da solo, ti riporta in produzione. Ti riporta in produzione un restore che hai già fatto funzionare, su un supporto diverso, con una procedura scritta, prima che servisse.
In breve: tieni almeno tre copie, su due tipi di supporto, una fuori sede (il classico 3-2-1). Distingui il backup dalla ritenzione e dal RAID. Prova il ripristino a intervalli, non il giorno dell'incidente. Se non sai quanto indietro puoi tornare e cosa perdi in mezzo, non hai un backup. Hai un file.
Cosa trovi in questo articolo
Cosa stai davvero proteggendo
Un sito non è "i file della webroot". È codice, configurazione, dati applicativi, upload degli utenti, certificati, eventuali code e cron. Se ripristini i PHP e perdi il database, hai una facciata. Se ripristini il database e perdi i media, hai le schede prodotto senza foto. Se tieni tutto sullo stesso volume, un errore di cancellazione o un ransomware ti prende il pezzo e la copia insieme.
La domanda operativa è secca: dopo un fermo, cosa deve tornare, in che ordine, e quanto puoi perdere. Quella quantità ha un nome, RPO, recovery point objective: quanto indietro accetti di tornare. Il tempo per tornare in servizio è RTO. Non servono numeri inventati da brochure. Servono numeri tuoi, anche grezzi. Un catalogo che può perdere un'ora di ordini e un catalogo che non può perderne nessuno non si copiano allo stesso modo.
CISA, nella guida sul ransomware, insiste su un punto che vale anche senza ransomware: copie offline o comunque non raggiungibili in scrittura dall'ambiente di produzione, e verifica periodica che il ripristino funzioni. Il testo è pubblico, nella Ransomware Guide di CISA e MS-ISAC. Non è un manuale di hosting. È il minimo che un incidente grave dà per scontato tu abbia già fatto.
La regola 3-2-1, senza folklore
Il 3-2-1 è un pattern operativo citato da anni, non una legge di natura e non un prodotto. Tre copie dei dati (la produzione più due backup). Due tipi di supporto diversi, perché lo stesso disco, lo stesso array, la stessa cloud bucket con le stesse credenziali falliscono insieme. Una copia fuori sede, perché incendio, furto, errore di datacenter e ransomware che cifra anche le share di rete non sono ipotesi da film.
Fuori sede non significa "un'altra cartella sullo stesso server". Significa un dominio di guasto diverso: altro disco in altro luogo, altro account, meglio se immutabile o a freddo. Lo snapshot sullo stesso hypervisor è comodo per tornare indietro di un'ora dopo un deploy storto. Non è la copia che ti salva se l'hypervisor, il pannello o le chiavi API finiscono in mano a qualcuno che non doveva averle.
Il 3-2-1 non dice quale software usare. Dice dove possono stare le copie perché un singolo incidente non le prenda tutte. Se le tre copie vivono nello stesso account cloud, con la stessa identity, hai rispettato il numero e tradito il senso. Tre è il conteggio. Due e uno sono isolamento.
RAID non è backup
Il RAID tiene su un volume quando un disco muore. È disponibilità locale, non storia. Un file cancellato si cancella su tutti i dischi del mirror. Un filesystem corrotto si corrompe sull'array. Un cryptolocker cifra i blocchi che il sistema operativo vede, e il RAID fa il suo mestiere: replica il danno con alta affidabilità.
Lo spieghiamo per esteso in RAID non è backup, perché la confusione torna in ogni post-mortem. Qui basta la conseguenza pratica: un array sano il lunedì non ti restituisce il database di domenica. Se il fornitore scrive "backup RAID" in scheda tecnica, leggi "dischi in ridondanza". Poi chiedi dove sta la copia, da quanto, e come si ripristina su una macchina pulita.
Stesso discorso, in scala minore, per "ce l'ho nel Time Machine del portatile del titolare" o "ce l'ho nella mail che mi sono mandato". Sono gesti. Non sono un sistema. Un sistema ha un owner, una cadenza, un supporto, un test.
Il test che nessuno vuole fare
Il backup si misura sul restore. Non sui gigabyte scritti stanotte, non sul semaforo verde del cron, non sulla ricevuta dello storage. Si misura così: prendi una macchina che non è quella di produzione, ripristina, accendi, verifica che l'applicazione risponda, che i dati ci siano, che le password e i certificati tornino, che gli upload ci siano. Cronometra. Annota cosa hai dovuto fare a mano. Quella lista è la procedura. Se non esiste, il giorno dell'incidente la inventerai sotto pressione, e sbaglierai.
Non servono cifre da vendor su "quanto è veloce il nostro restore". Servono le tue: quanto pesa il dataset, dove sta, che rete hai, chi ha le chiavi. Un dump da pochi gigabyte e un volume di media da terabyte non si comportano allo stesso modo. Lo scopri provando, non stimando a voce.
Quanto spesso. Abbastanza da fidarti, non così spesso da diventare teatro. Dopo ogni cambio sostanziale di stack (nuovo CMS, nuovo storage, nuovo modo di fare il dump) il test non è opzionale. In regime, una cadenza fissa batte il "quando capita". Il monitoring ti dice se il sito è su; il restore ti dice se sai tornare. Sono due mestieri diversi, e il primo sta in monitoring del sito web. Non sostituisce il secondo.
Ritenzione non è backup
Tenere i backup per trenta giorni non è "avere più backup". È una finestra sul passato. Serve perché certi danni si notano tardi: una cancellazione silenziosa, una tabella corrotta, un contenuto defacciato che nessuno ha visto per una settimana. Se la ritenzione è di 48 ore e te ne accorgi il quinto giorno, hai una storia breve e un buco lungo.
La ritenzione si decide su due vincoli, non su un numero tondo. Primo: quanto indietro ti è già capitato di dover tornare, o quanto indietro un incidente tipico del tuo mestiere ti costringe a guardare. Secondo: vincoli di legge e di contratto sui dati personali. Tenere tutto per sempre non è prudenza. È superficie, costo, e spesso un problema di privacy. CISA, sul ransomware, ricorda anche questo: copie isolate, sì; archivio infinito e raggiungibile, no.
Un'altra distinzione noiosa e utile: backup e patch sono vicini solo nel calendario dell'operatività. Prima di un aggiornamento critico conviene una copia fresca e un'idea di rollback. La patch resta obbligatoria. Il backup non è una scusa per non aggiornare, e l'aggiornamento non è una scusa per non avere una copia. Il ritmo delle correzioni sta in patch di sicurezza.
Ha senso quando. Non serve quando
Ha senso un 3-2-1 con restore provato su qualsiasi sito che tenga dati non ricostruibili a mano: ordini, contenuti, upload, configurazioni, identità. Il blog con tre pagine statiche e un repo Git può vivere con meno cerimonia, se il repo è altrove e sai pubblicare di nuovo. Il giorno in cui quel sito diventa un catalogo, le regole cambiano. Non il mese dopo. Quel giorno.
Non serve un prodotto da enterprise, con console e slide, per un volume che entra in un dump notturno e una copia offsite. Serve che il dump esista, che non stia sullo stesso disco, che qualcuno lo abbia aperto. La complessità si aggiunge quando i dati crescono, quando hai più ambienti, quando l'RPO si stringe. Prima di quella soglia, un sistema semplice che ripristini batte un sistema sofisticato che non hai mai visto ripartire.
Non serve nemmeno "backup continuo" come slogan se poi l'unica copia è nello stesso account di produzione. Continuo e raggiungibile dall'attaccante è un diario aggiornato del disastro. Immutabilità, disconnessione, privilegi stretti: quelli spostano l'ago. La frequenza, da sola, no.
Errori da evitare
Fidarsi del semaforo verde. Il job può scrivere un file vuoto, un dump troncato, una copia dell'ambiente sbagliato. Si verifica il contenuto, non l'exit code.
Tenere backup e produzione con le stesse credenziali. Chi cifra l'uno arriva all'altro. Account distinti, privilegi minimi, meglio una copia che in produzione non si può cancellare.
Chiamare backup lo snapshot locale. Utile per un rollback rapido. Insufficiente come unica linea.
Non documentare il restore. La procedura nella testa di una persona è un singolo punto di guasto, esattamente come un disco solo.
Provare il restore sulla macchina di produzione. Il test deve poter fallire senza portare giù il sito. Altrimenti non lo farai.
Confondere ritenzione lunga e copia sicura. Trenta giorni sullo stesso NAS in ufficio sono storia locale, non fuori sede.
In sintesi
Il backup è un restore che hai già visto riuscire. Il 3-2-1 ti dice quante copie, su che tipi di supporto, e che una stia fuori dal raggio del guasto. Il RAID tiene i dischi, non il passato. La ritenzione è la profondità della storia, non la qualità della copia. CISA, sul ransomware, chiede copie isolate e prove di ripristino: è lo stesso standard che serve per un rm sbagliato o per un disco morto. Il resto, cartelle sparse e fiducia nel pannello, è folklore.
Se non l'hai ripristinato, non ce l'hai. Punto.
Fonti
CISA / MS-ISAC, #StopRansomware Guide (copie offline o immutabili, verifica del ripristino).
CISA, StopRansomware.
NIST, SP 800-34 Rev. 1 (contingency planning: backup e recovery come processo, non come file).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
