Quasi tutte le storie del tipo "ho perso tutto" non sono perché qualcuno non aveva backup. Sono perché il backup era sulla stessa macchina che si è rotta, o sullo stesso provider che ha bloccato l'account, o sullo stesso disco che il ransomware ha cifrato. La regola 3-2-1 è il framework più semplice che previene tutti questi casi.

La regola

Tre copie dei dati, su due tipi di supporto diversi, una copia off-site.

Tutto qui. Memorizzarla richiede 10 secondi. Tutto l'articolo qui sotto è solo lo srotolamento di ogni numero.

"Tre copie"

L'originale conta come una. I due backup contano come due e tre. Quindi:

  • I dati in produzione sul tuo server (copia 1)
  • Un backup da qualche parte sullo stesso server o sullo stesso provider (copia 2)
  • Un backup da qualche parte completamente separata (copia 3)

Perché tre e non due: quando il primario fallisce e vai a fare il restore, anche il backup potrebbe fallire. Disco corrotto, snapshot a metà, retention scaduta. Con due copie di backup la probabilità che entrambe siano inutilizzabili nel momento in cui servono è abbastanza piccola da poter essere ignorata.

"Su due tipi di supporto diversi"

La regola fu scritta quando "supporto" significava nastro vs disco vs CD. Oggi si traduce in "due tecnologie che falliscono per ragioni diverse". Una lettura moderna utile:

  • Uno snapshot a livello blocchi dell'host (snapshot Hetzner, snapshot DigitalOcean) e un archivio a livello file da un'altra parte (tarball, restic, Borg, BackBlaze B2). Falliscono per ragioni diverse. Lo snapshot sopravvive a un file cancellato ma muore col disco. L'archivio file sopravvive al disco ma è più lento da ripristinare.
  • Un dump del database (mysqldump, pg_dump) e uno snapshot del filesystem. Il dump è leggibile e portabile. Lo snapshot è veloce ma legato allo strato di storage.
  • Hot storage (un backup che puoi accedere subito) e cold storage (un backup che richiede ore per essere recuperato). Il cold è economico, immune al ransomware che mira alle copie calde, e utile per retention lunghe.

Il punto non è il letterale "due supporti". Il punto è: "se la mia intera categoria di backup fallisce, ho una categoria che sopravvive indipendentemente?".

"Una copia off-site"

Off-site significa luogo fisico diverso, idealmente provider diverso. La ragione non è solo incendio o terremoto. È il disastro a livello di account:

  • Il tuo provider blocca l'account per un problema di pagamento.
  • Il root user di AWS viene compromesso e qualcuno cancella tutto, backup compresi nello stesso account.
  • Il tuo provider fallisce e il data center viene sigillato per sei mesi.
  • Il ransomware sul tuo laptop raggiunge il target di backup connesso e cifra anche quello.

Se l'unico backup è sullo stesso provider dei dati live, nessuno di questi scenari è recuperabile.

Off-site non deve essere costoso. Un bucket BackBlaze B2 da 100 GB è circa 0,50 euro al mese. Una Hetzner Storage Box in una location diversa dal tuo VPS sono 3 euro al mese per 1 TB. L'obiezione del costo è raramente reale.

Setup concreti

La regola è astratta, ecco come si traduce in tre casi comuni.

WordPress singolo su un VPS. Database e file in produzione su un Hetzner CX22 a Helsinki (copia 1). Snapshot giornaliero dal pannello Hetzner, 7 mantenuti (copia 2, stesso provider). Archivio restic notturno di /var/www e un mysqldump pushato su BackBlaze B2 in EU-Central, 30 giorni di retention (copia 3, provider diverso, regione diversa). Circa 1 euro al mese in totale per l'off-site, configurato in 30 minuti una volta, poi mai più toccato.

Agenzia con 20 siti su un VPS. Stessa logica ma l'off-site è un repository Borg su una Hetzner Storage Box in un DC diverso dal VPS. Borg fa deduplicazione, quindi 20 installazioni WordPress costano circa lo storage di una grossa. Più verifica settimanale: un piccolo script che esegue borg check e ti manda una email se qualcosa non va.

E-commerce, soldi veri che girano. Lo stesso più: backup point-in-time del database notturno con binary log (così puoi recuperare a un timestamp qualsiasi, non solo agli snapshot notturni), prova mensile di restore completo su un box di staging (l'unico modo per sapere che i tuoi backup funzionano davvero), una copia in cold storage al trimestre pushata su un provider completamente diverso (AWS Glacier o Wasabi), retention di almeno 1 anno.

La parte che tutti saltano: testare il restore

Un backup che non è mai stato ripristinato è una speranza, non un backup. La prima volta che ti serve davvero è il momento peggiore per scoprire che non funziona.

Una volta a trimestre fai così:

  1. Crea un VPS vuoto o una VM locale.
  2. Tira giù il backup off-site più recente.
  3. Ripristina il database, ripristina i file, punta un DNS temporaneo.
  4. Apri il sito nel browser. Si carica? Ci sono i post della settimana scorsa? Il check di integrità del database passa?

Se sì, il backup è vero. Se no, sistemi la pipeline rotta ora, quando niente è in fiamme.

Fallo una volta e sei nel 10% migliore dei piccoli operatori per disciplina dei backup. Non farlo mai e ti unisci alla maggioranza che pensa di avere i backup.

Cosa non considero un backup

  • Un array RAID. RAID sopravvive al guasto di un disco, non a un file cancellato, non al ransomware, non a "ho sovrascritto la riga sbagliata". RAID è uptime, non backup.
  • Solo uno snapshot sullo stesso provider. Utile per il rollback rapido. Non è un backup contro la perdita dell'account.
  • Una copia su una chiavetta USB accanto al laptop. Off-site significa luogo diverso, non cassetto diverso.
  • "Il provider ce l'ha". Se non testi il restore tu, non sai cosa tengono, per quanto, in che formato e qual è l'SLA per riavere indietro i dati. Il giorno che chiedi è il giorno peggiore per scoprirlo.

Un punto di partenza pratico

Se stai leggendo e oggi non hai niente di strutturato, parti dalla versione più piccola:

  1. Scrivi uno script di 10 righe che lancia mysqldump | gzip > /tmp/db_$(date +%Y%m%d).sql.gz e un tar di /var/www.
  2. Pusha entrambi su un provider diverso (BackBlaze B2 con b2-cli è il più semplice, va bene anche rclone su qualunque target compatibile S3).
  3. Mettilo in cron notturno.
  4. Imposta un promemoria nel calendario fra 30 giorni per fare un test di restore.

Costo totale: 30 minuti di setup, 0,50-2 euro al mese. Passi da "nessun backup" a "in regola con la 3-2-1" in una serata. Il resto è raffinatura.