La regola del backup 3-2-1 spiegata (e perché funziona) - init.d
EN

# La regola del backup 3-2-1 spiegata (e perché funziona)

Alessandro Corbelli~7 min
Table of Contents

Prima o poi capita a tutti: un disco che smette di girare, un file cancellato per sbaglio, un telefono caduto in acqua, un’azienda bloccata da un attacco informatico. In quei momenti la domanda è sempre la stessa: «C’è una copia da qualche parte?». La regola 3-2-1 è la risposta più semplice e collaudata a questa domanda. Non è un prodotto né una tecnologia: è un modo di ragionare sui backup che vale per un fotografo con le sue foto quanto per un’azienda con i suoi gestionali.

Il punto di partenza è un’idea scomoda ma sana: prima o poi qualcosa andrà perso. Non è pessimismo, è statistica. I dischi si guastano, le persone sbagliano, i programmi hanno difetti, i ladri esistono. Un backup non serve a evitare che succeda: serve a fare in modo che, quando succede, non sia un disastro.

Cosa dice la regola 3-2-1

La regola si riassume in tre numeri.

  • 3 copie dei dati. L’originale più altre due copie. Non basta «avere un backup»: ne servono almeno due, oltre ai dati che si usano ogni giorno.
  • 2 supporti diversi. Le copie non vanno tenute tutte sullo stesso tipo di dispositivo. Per esempio: il disco del computer e un disco esterno, oppure un disco locale e un servizio in cloud.
  • 1 copia fuori sede. Almeno una copia deve stare in un luogo fisicamente diverso: un altro edificio, un data center, il cloud. Lontano dai rischi che minacciano l’originale.

Detta così sembra ovvia. Il valore sta nel perché ognuno di quei numeri è lì.

Perché tre copie e non una

Un backup solo, tenuto accanto all’originale, protegge da pochissime cose. Se cancello un file per errore e me ne accorgo subito, va bene. Ma se il backup è sullo stesso disco dell’originale, un guasto del disco porta via entrambi in una volta sola. Se è nella stessa stanza, un furto o un allagamento fanno lo stesso.

Tre copie servono a rendere improbabile che un singolo evento le colpisca tutte. È lo stesso principio per cui non si tengono tutti i contanti nello stesso posto. Più le copie sono indipendenti tra loro - è quella che i tecnici chiamano ridondanza - meno probabile è perderle insieme.

Perché due supporti diversi

Ogni tipo di supporto ha i suoi punti deboli. Un disco meccanico si può rompere per usura. Una chiavetta USB si può smarrire. Un servizio online può avere un disservizio o un problema con l’account. Usare due tipi diversi di supporto evita che lo stesso difetto colpisca tutte le copie.

Un esempio classico: una copia su un disco esterno in ufficio e una copia in un servizio cloud. I due supporti non condividono quasi nessun rischio. Il fulmine che frigge l’elettronica in ufficio non tocca il cloud; il problema di connessione che blocca il cloud non impedisce di leggere il disco esterno.

Perché una copia fuori sede

Le prime due regole proteggono dai guasti. La terza protegge dai disastri che colpiscono un intero luogo: un incendio, un allagamento, un furto, ma anche un attacco informatico che cifra o cancella tutto quello che riesce a raggiungere in rete.

Il «fuori sede» (in inglese offsite) significa proprio questo: una copia che non si trova nello stesso posto degli altri dati e, idealmente, non è raggiungibile con le stesse credenziali, un requisito che rientra a pieno titolo tra le misure di sicurezza richieste anche dal GDPR sul lato infrastrutturale. Se un incendio distrugge l’ufficio, la copia nel data center dall’altra parte del Paese è ancora lì. Se un attacco riesce a entrare nei sistemi, una copia isolata e non modificabile resta l’ultima difesa, sullo stesso principio delle chiavi di cifratura che nemmeno il fornitore cloud può leggere senza il consenso del cliente.

Il backup che nessuno testa

C’è un errore che si ripete spesso: fare backup per anni e non provare mai a rimetterli in funzione. Un backup che non è mai stato ripristinato non è un backup: è una speranza.

I motivi per cui un ripristino può fallire sono tanti e banali. Il file di backup è corrotto. La procedura, magari pianificata con un timer, salvava la cartella sbagliata. La password per aprire l’archivio cifrato è andata persa. Il formato non è più leggibile. Tutte cose che si scoprono solo provando - e il momento peggiore per scoprirle è durante un’emergenza vera.

Per questo il test del ripristino (in inglese restore) è parte della regola, non un extra. Ripristinare ogni tanto una copia in un ambiente separato e controllare che i dati ci siano davvero è l’unico modo per sapere che il backup funziona. Se non è stato testato, non si sa se funziona: si spera. Ed è il primo requisito di ogni intervento grosso sull’infrastruttura, come l’aggiornamento di un hypervisor Proxmox a fine supporto: prima di toccare il server si verifica che il rientro esista davvero.

RPO e RTO spiegati facile

Quando si parla di backup seri compaiono due sigle: RPO e RTO. Sembrano complicate, ma dietro ci sono due domande molto concrete.

RPO sta per Recovery Point Objective. Risponde alla domanda: «Quanti dati posso permettermi di perdere?». In termini pratici è ogni quanto si fa un backup. Se salvo una volta al giorno, nel peggiore dei casi posso perdere fino a un giorno di lavoro: tutto ciò che è cambiato dall’ultimo backup. Se è troppo, la risposta è fare backup più spesso. Il NIST, l’ente statunitense che pubblica standard tecnici, lo definisce come il punto nel tempo a cui i dati devono essere riportati dopo un’interruzione.

RTO sta per Recovery Time Objective. Risponde all’altra domanda: «Quanto tempo posso restare fermo?». È quanto può passare tra il guasto e il ritorno alla normalità. Un sito personale può stare fermo qualche ora senza grossi danni; un e-commerce nel fine settimana degli sconti no, un ragionamento non troppo diverso da quello che porta a scegliere un database ad alta disponibilità per i servizi più critici. Il NIST lo descrive come la durata complessiva entro cui i sistemi devono tornare operativi prima che l’impatto sull’attività diventi inaccettabile.

Le due sigle misurano due perdite diverse: RPO misura i dati persi, RTO il tempo perso. Definirle in anticipo aiuta a scegliere: ogni quanto fare i backup e quanto in fretta serve poterli ripristinare. Da lì discende il resto.

Da dove viene la regola

La formula «3-2-1» è stata resa popolare dal fotografo Peter Krogh a metà degli anni 2000, nel libro The DAM Book dedicato alla gestione degli archivi digitali. Krogh non ha inventato l’idea delle copie multiple e della copia fuori sede - esisteva già - ma l’ha condensata in tre numeri facili da ricordare. Da allora è diventata un riferimento comune, ripresa anche da enti pubblici che si occupano di sicurezza informatica.

Non è un dogma

La 3-2-1 è un buon punto di partenza, non un traguardo. Negli ultimi anni, con la diffusione degli attacchi ransomware - i programmi che cifrano i dati e chiedono un riscatto - si sono aggiunte varianti che insistono su due punti: avere almeno una copia immutabile o isolata dalla rete, che un attaccante non possa cancellare, e verificare che i ripristini funzionino senza errori. Sono raffinamenti, non stravolgimenti: il cuore resta quello di sempre.

Vale anche il contrario. Per i dati di casa non serve un piano aziendale: due copie su supporti diversi e una nel cloud coprono già gran parte dei rischi. La regola scala verso l’alto e verso il basso.

In sintesi

La regola 3-2-1 funziona perché attacca il problema giusto: non «come evitare i guasti», ma «come sopravvivere quando succedono». Tre copie rendono improbabile perderle tutte insieme; due supporti diversi evitano che lo stesso difetto le colpisca tutte; una copia fuori sede resiste ai disastri che cancellano un intero luogo. E niente di tutto questo vale se non si prova ogni tanto a ripristinare. Definire quanto si può perdere (RPO) e quanto si può stare fermi (RTO) trasforma una buona abitudine in un piano. Non serve essere esperti: serve solo prendere sul serio l’idea che, prima o poi, una copia servirà davvero.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent’anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli