Un RAID 1 non ti salva da un file cancellato, da un ransomware, da un incendio. Confondere i tre livelli è il modo più rapido per scoprirlo tardi.
RAID non è un backup. Un backup non è un piano di disaster recovery. I tre risolvono guasti diversi: un disco che muore, una copia da cui ripartire, una procedura per tornare in produzione entro un tempo deciso. Confonderli è il modo più rapido per scoprire, il giorno sbagliato, che si aveva solo ridondanza locale.
In breve: RAID 1, 5, 6 e 10 tengono su i dischi se uno (o due, nel caso del 6) si rompe. Non proteggono da cancellazione, ransomware, errore umano, incendio del chassis. Il backup è una copia, meglio se altrove e provata. Il disaster recovery è la procedura, con un RTO e un RPO. Disco, copia, procedura. Non sono sinonimi.
Cosa trovi in questo articolo
Cosa fa RAID, e cosa non fa
RAID (Redundant Array of Independent Disks) mette insieme più dischi perché il volume resti disponibile se un disco fallisce, o perché si aggreghi banda. Red Hat, nella documentazione di gestione storage, lo descrive in questi termini: un array con ridondanza, non un sistema di copie. Il kernel Linux, via md, fa lo stesso mestiere a livello di blocco.
Ciò che RAID vede è un settore. Se il filesystem riceve un "cancella questo file", RAID lo cancella su tutti i membri che tengono quei dati. Se un ransomware cifra i file, RAID replica la cifra. Se un amministratore lancia un rm sulla directory sbagliata, RAID è allineato in millisecondi: allineato al disastro. Se il cabinet va a fuoco, i membri bruciano insieme. La ridondanza è locale, sullo stesso controller, spesso nello stesso rack. Non è una copia. Non è un altro sito.
Serve. Un disco che muore è un evento ordinario, non un'ipotesi. RAID evita che quel disco solo sia un fermo. Non evita il resto. Il resto sta nel cluster Infrastruttura accanto a host e rete, e nell'articolo sul backup, dove la copia si prova, non si presume.
RAID 1, 5, 6, 10: quattro mestieri diversi
I livelli standard esistono da decenni. Non sono equivalenti.
RAID 1 (mirror): due (o più) dischi con gli stessi dati. Sopravvive al guasto di un membro. Letture spesso più veloci. Scritture limitate dal più lento. Capacità utile pari a un disco. Semplice da capire, semplice da ricostruire.
RAID 5: striping con un disco di parità distribuita. Sopravvive a un disco. Capacità utile N-1. Le scritture piccole pagano un penalty (lettura-modifica-scrittura della parità). Il rebuild dopo un guasto legge tutto l'array: su dischi grandi è lungo, e in quella finestra un secondo guasto è fatale.
RAID 6: come il 5, con doppia parità. Sopravvive a due dischi. Penalty di scrittura più alto. Ha senso quando i dischi sono grandi e il rebuild è lungo: il secondo paracadute esiste proprio per quella finestra.
RAID 10 (1+0): stripe di mirror. Sopravvive a un disco per coppia. Scritture casuali in genere migliori del RAID 5. Capacità utile la metà. Costa dischi, restituisce I/O. È la forma più frequente quando il carico è database o VM, non archivio freddo.
RAID 0 (solo striping) esiste ed è l'opposto della protezione: un disco perso, volume perso. Non va confuso con "avere RAID". Avere uno 0 è avere banda, non ridondanza.
Nessuno di questi livelli sa distinguere un file buono da un file cifrato. Nessuno tiene una versione di ieri. Nessuno vive in un altro edificio. Per quello servono gli altri due piani.
Backup: una copia, non un mirror
Un backup è una copia dei dati, indipendente dall'array di produzione, da cui si può ripristinare. Indipendente vuol dire: altro disco, altro account, altro sito, meglio se non montato in scrittura sulla stessa macchina. CISA, nella guida sul ransomware, insiste su copie offline o immutabili proprio perché il mirror locale non sopravvive a un attacco che cifra "tutto ciò che il sistema vede".
La copia non basta se non si è mai fatto un restore. Un file .tar in una cartella "backup" che nessuno ha riprovato è una scommessa. Si prova su un volume diverso, si misura quanto impiega, si annota cosa manca (media, segreti, cron). La regola pratica 3-2-1 (tre copie, due supporti, una fuori sede) è un'igiene, non un certificato. Il test di restore è il certificato.
In hosting la distinzione si chiede esplicita. Lo snapshot del hypervisor, il RAID del nodo, la copia notturna su un altro storage: tre oggetti. Chi prende un VPS o un dedicato, anche tra i servizi hosting di Servereasy, deve sapere quale di questi tre è incluso, dove sta la copia, chi la può cancellare insieme alla macchina. Il RAID del nodo protegge il disco del nodo. Non protegge dal tenant che cancella il sito. Il confronto tra forme di host, isolamento e disco, sta in VPS o server dedicato.
Disaster recovery: RTO e RPO
Il disaster recovery è la procedura con cui si torna a erogare il servizio dopo un disastro: non un file, un sistema. NIST, in SP 800-34 Rev. 1, definisce due grandezze che bastano come contratto:
RTO (Recovery Time Objective): quanto tempo massimo può restare fermo il servizio. È una scelta di business, non un numero del vendor. Un sito vetrina e un checkout non hanno lo stesso RTO, e non devono.
RPO (Recovery Point Objective): quanta perdita di dati, misurata in tempo, si accetta. Un RPO di 24 ore vuol dire: si può perdere fino all'ultima giornata. Un RPO vicino a zero vuol dire replica continua, non un tar notturno.
Senza RTO e RPO, "abbiamo il DR" è una frase. Con RTO e RPO si decide frequenza del backup, replica, runbook, chi chiama chi, su quale DNS si punta l'origine alternativa. Il RAID non ha un RTO: o l'array resta su, o il volume è perso fino al restore. Il backup ha un RPO implicito (l'età della copia) e un RTO che si scopre solo se si è provato il restore. Il DR tiene insieme persone, DNS, certificati, database e il pezzo di rete che deve tornare a rispondere.
Non si inventano soglie per "il sito medio". Si scrivono le proprie, si prova il runbook, si aggiorna quando cambia il prodotto. Un piano non esercitato è un documento. Un documento non alza un sito.
Ha senso quando. Non serve quando
Ha senso RAID su ogni origine che deve sopravvivere al disco rotto: database, dischi delle VM, storage del CMS. È igiene. Costa dischi, restituisce continuità sul guasto meccanico.
Ha senso un backup su ogni dato che non si accetta di perdere. Sempre. Con restore provato. Con una copia che un ransomware non possa cifrare insieme all'origine.
Ha senso un DR quando il fermo ha un costo di business e un owner. Non per ogni brochure. Sì per il negozio, per il SaaS, per il sito che è il canale.
Non serve chiamare "backup" il RAID, né "DR" uno script di rsync mai lanciato da altri. Non serve un RTO da grande impresa su un sito che può restare fermo due giorni. Serve coerenza tra ciò che si dichiara e ciò che si è provato.
Errori da evitare
Dire "siamo in RAID, siamo al sicuro". Si è al sicuro dal disco rotto. Punto.
Tenere il backup sullo stesso array, nello stesso account, montato in scrittura. Si ha una seconda cartella, non una copia indipendente.
Non provare il restore. L'unico backup che conta è quello che è già tornato su un altro disco.
Confondere snapshot e backup. Lo snapshot è veloce da fare e veloce da perdere insieme all'infrastruttura che lo ospita.
Scrivere RTO e RPO e non esercitare il runbook. I numeri senza prova sono marketing interno.
In sintesi
RAID tiene su i dischi. Il backup tiene una copia da cui si è già ripartiti almeno una volta. Il disaster recovery è la procedura, con un RTO e un RPO, per far rispondere di nuovo il servizio. Tre piani, tre guasti. Si dimensionano in quest'ordine: disco, copia, procedura. Chi li chiama con lo stesso nome scoprirà la differenza nel momento in cui servirà solo uno dei tre, e avrà l'altro.
Fonti
Red Hat, Getting started with RAID (RHEL 9).
Linux RAID wiki, Linux RAID.
NIST, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (definizioni di RTO e RPO).
CISA, #StopRansomware Guide (backup offline, immutabili, isolati).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
