Backup 3-2-1-1-0: la Regola Spiegata con Esempio Reale

La sopravvivenza di un’azienda in caso di disastro informatico dipende interamente dalla sua strategia di backup. Per anni, la regola aurea è stata la 3-2-1: tre copie dei dati, su due supporti diversi, con una copia offsite. Un principio solido, ma che nell’era dei ransomware e delle minacce persistenti, non è più sufficiente. Oggi, per garantire una resilienza completa, dobbiamo estendere questa regola al 3-2-1-1-0, introducendo l’immutabilità e la verifica costante dei ripristini. Questo approccio esteso è diventato un requisito fondamentale per chiunque gestisca infrastrutture IT critiche.

Versioni di riferimento: restic 0.16.2 · documentazione consultata a novembre 2026

La regola 3-2-1 e perché non basta più

La regola 3-2-1 è un concetto di base della data protection che assicura una buona copertura contro la perdita di dati. Prevede:

3 copie dei dati: l’originale più due backup.
2 supporti diversi: ad esempio, un disco locale e un NAS o nastro.
1 copia offsite: una copia fisica in un luogo geograficamente separato, o su un cloud storage.

Questo approccio è efficace contro guasti hardware, cancellazioni accidentali e disastri locali. Tuttavia, le minacce moderne come i ransomware hanno dimostrato i suoi limiti. Un ransomware può cifrare non solo i dati di produzione, ma anche i backup accessibili in rete, rendendo tutte le copie inutilizzabili. Allo stesso modo, un errore amministrativo può propagarsi a tutte le copie online prima che venga rilevato. È qui che il 3-2-1-1-0 entra in gioco, aggiungendo due strati cruciali di protezione.

Backup 3-2-1-1-0 in 60 secondi

Per chi ha fretta, ecco i concetti chiave della strategia 3-2-1-1-0 applicati con restic:

# 3 copie dei dati (originale, locale, offsite)
# 2 supporti diversi (disco locale, NAS, cloud S3)
# 1 copia offsite (cloud S3)

# Il terzo 1: Esegui il backup su un repository S3 con Object Lock abilitato
restic -r s3:s3.amazonaws.com/your-immutable-bucket backup /path/to/your/data --password-file /path/to/password.txt

# Lo 0: Verifica l'integrità dei dati nel repository (controllo rapido)
restic -r s3:s3.amazonaws.com/your-immutable-bucket check --read-data-subset=5% --password-file /path/to/password.txt

# Lo 0: Esegui un ripristino su una VM di test per validare la recuperabilità
restic -r s3:s3.amazonaws.com/your-immutable-bucket restore latest --target /tmp/test-restore --password-file /path/to/password.txt

# Lo 0: Rimuovi i dati di test dopo la verifica
rm -rf /tmp/test-restore

Intro: La resilienza dei dati nell’era del ransomware

Nel panorama IT attuale, la resilienza dei dati non è più solo una questione di disponibilità, ma di sopravvivenza. Un’azienda su tre subisce un attacco ransomware ogni anno, e il costo medio di un data breach ha raggiunto i 4,45 milioni di dollari nel 2023, secondo il rapporto IBM Cost of a Data Breach. Di fronte a queste statistiche, affidarsi a una strategia di backup tradizionale può essere insufficiente. Un backup ben configurato e regolarmente testato è la tua ultima linea di difesa, ma solo se è immune alle minacce più sofisticate. L’obiettivo di questo articolo è fornire una guida pratica e concreta per implementare la regola del backup 3-2-1-1-0, garantendo che i tuoi dati siano protetti e, soprattutto, recuperabili quando ogni altro sistema fallisce.

Prerequisiti

Per seguire l’esempio pratico, avrai bisogno di:

Un server Linux (es. Ubuntu Server 22.04 LTS o CentOS Stream 9).
Accesso root o un utente con privilegi sudo.
Un NAS (Network Attached Storage) o un server con spazio disponibile via NFS/SMB.
Un account di storage cloud compatibile con S3 (es. AWS S3, MinIO, Wasabi, Scaleway) con la funzionalità Object Lock abilitata per il bucket di destinazione. Leggi anche: ACN Cloud: Leggere il Catalogo Qualificazione Servizi
Lo strumento restic installato sul server Linux. Puoi scaricarlo dal sito ufficiale o installarlo tramite il package manager del tuo sistema operativo. Ad esempio, su Debian/Ubuntu:

    sudo apt update && sudo apt install restic

Conoscenza di base dei comandi Linux e della gestione dello storage.

1. La regola 3-2-1 e perché non basta più

Come accennato, la regola 3-2-1 prevede tre copie dei dati, su due supporti diversi, con una copia offsite. Questa è una base eccellente per la maggior parte degli scenari di perdita dati. Tuttavia, il problema emerge quando i backup stessi diventano target o sono compromessi in modo non tradizionale. Immagina un ransomware che si propaga in rete e cifra non solo i dischi di produzione, ma anche il NAS dove risiedono i backup e, se accessibile, anche il repository offsite. In questo scenario, tutte e tre le copie potrebbero essere contemporaneamente compromesse. Oppure, un errore di configurazione può cancellare o corrompere un intero set di backup prima che tu te ne accorga. La mancanza di un meccanismo di immutabilità e di una verifica proattiva rende il 3-2-1 vulnerabile a minacce che vanno oltre il semplice guasto hardware.

2. Il terzo 1: una copia offline o immutabile

Il “terzo 1” della regola 3-2-1-1-0 si riferisce a una copia dei dati che sia offline o immutabile. Questa è la tua ultima linea di difesa contro attacchi ransomware sofisticati o cancellazioni accidentali di massa.

Copia Offline: Un backup su un supporto fisico (nastro, disco USB esterno) che viene disconnesso dalla rete dopo il completamento del backup. Questo lo rende fisicamente inaccessibile a qualsiasi malware o attacco di rete. È il metodo più sicuro, ma richiede gestione manuale e tempi di ripristino potenzialmente più lunghi.
Copia Immutabile: Un backup su storage che impedisce qualsiasi modifica o cancellazione per un periodo di tempo predefinito (Retention Period). Questa funzionalità è spesso offerta dai servizi di storage cloud (es. AWS S3 Object Lock, Azure Blob Storage Immutability) o da alcuni NAS di fascia enterprise. Anche se il sistema è compromesso, il ransomware non può alterare o eliminare i backup immutabili fino alla scadenza del periodo di retention. Leggi anche: Microsegmentazione Rete: VLAN e Firewall in Produzione

Per l’esempio, useremo un bucket S3 con Object Lock abilitato, che offre un eccellente equilibrio tra sicurezza e automazione. Configura il tuo bucket S3 con Object Lock in modalità “Compliance” o “Governance” per garantire l’immutabilità.

3. Lo 0: zero errori ai test di ripristino

Questo è forse il passaggio più critico e più trascurato: testare regolarmente e con successo il ripristino dei tuoi backup. Un backup che non si ripristina è inutile. Lo “0” nella regola 3-2-1-1-0 significa che i tuoi test di ripristino devono avere zero errori. Questo non è un evento una tantum, ma un processo continuo che dovrebbe essere automatizzato il più possibile.

I test dovrebbero includere:

Verifica dell’integrità dei dati: Controllare che i file di backup non siano corrotti.
Ripristino parziale: Ripristinare singoli file o directory per verificare la granularità.
Ripristino completo: Ripristinare l’intero backup su un ambiente di test (una VM dedicata, una sandbox) per simulare un disastro e misurare il Recovery Time Objective (RTO).

Questo processo ti permette di identificare problemi nelle procedure di backup, nella configurazione dello storage o nella corruzione dei dati prima che si verifichi un’emergenza reale. Leggi anche: pg_restore: Ripristinare Dump PostgreSQL e Errori

4. Esempio reale: server Linux, NAS e cloud

Vediamo come applicare la regola 3-2-1-1-0 in un ambiente tipico:

Scenario: Un server Linux con dati critici in /srv/data.

Strategia 3-2-1-1-0:

Copia 1 (originale): I dati in /srv/data sul server Linux.
Copia 2 (locale): Backup su un NAS locale (supporto diverso dal disco del server).
Copia 3 (offsite/immutabile): Backup su storage cloud S3 con Object Lock abilitato (supporto diverso, offsite, immutabile).

Passo 1: Backup su NAS locale (Copia 2)

Monta una share NFS o SMB dal tuo NAS sul server Linux. Ad esempio, monta /mnt/nas_backup.

sudo mkdir -p /mnt/nas_backup
sudo mount -t nfs nas_ip:/export/backup /mnt/nas_backup

Configura un backup giornaliero usando rsync o restic (se il NAS supporta un repository restic). Useremo rsync per semplicità per il backup locale.

#!/bin/bash
SOURCE_DIR="/srv/data"
TARGET_DIR="/mnt/nas_backup/linux_server_data"
LOG_FILE="/var/log/backup_nas.log"

echo "$(date): Avvio backup su NAS" >> "$LOG_FILE"
rsync -avzh --delete --exclude '*/tmp/*' "$SOURCE_DIR/" "$TARGET_DIR/" >> "$LOG_FILE" 2>&1
if [ $? -eq 0 ]; then
    echo "$(date): Backup su NAS completato con successo" >> "$LOG_FILE"
else
    echo "$(date): ERRORE durante il backup su NAS" >> "$LOG_FILE"
fi

Passo 2: Backup su Cloud S3 Immutabile (Copia 3, Offsite, Immutabile)

Utilizzeremo restic per questo passo. restic è ideale per backup su cloud grazie alla deduplicazione, cifratura e supporto per vari backend, inclusi S3. Assicurati di aver configurato le credenziali AWS (o del tuo provider S3) tramite variabili d’ambiente (es. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) o un file di configurazione.

Inizializza il repository restic sul bucket S3. Sostituisci your-immutable-bucket con il nome del tuo bucket.

export RESTIC_PASSWORD_FILE=/etc/restic/backup_password.txt # Assicurati che questo file sia protetto
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

# Inizializza il repository (solo la prima volta)
restic init -r s3:s3.amazonaws.com/your-immutable-bucket

Esegui il backup dei dati:

restic -r s3:s3.amazonaws.com/your-immutable-bucket backup /srv/data

Questo comando creerà un backup cifrato e deduplicato sul tuo bucket S3. Grazie a Object Lock, questi snapshot saranno immutabili per il periodo di retention configurato, proteggendoti da cancellazioni accidentali o da attacchi ransomware.

5. Come verificare che il backup si ripristini davvero

La fase di verifica è cruciale per lo “0” della regola 3-2-1-1-0. Non basta che il backup termini senza errori; devi essere certo che i dati siano recuperabili.

Verifica dell’integrità dei dati (rapida)

restic offre un comando check che verifica l’integrità del repository. Puoi specificare una percentuale di dati da leggere per un controllo più rapido.

restic -r s3:s3.amazonaws.com/your-immutable-bucket check --read-data-subset=5%

Un output tipico:

using temporary cache in /tmp/restic-check-cache-123456
repository a2b3c4d5 opened successfully, password is correct
checking snapshots
checking logs
checking keys
checking data
[0:00] 100.00%  500 / 500 packs
check finished

Ripristino completo su ambiente di test

Questo è il test definitivo. Configura una VM di test separata, preferibilmente con la stessa distribuzione Linux del server originale. Poi, ripristina l’ultimo snapshot del backup su questa VM.

# Sulla VM di test, installa restic e configura le credenziali S3
# Esegui il ripristino
restic -r s3:s3.amazonaws.com/your-immutable-bucket restore latest --target /tmp/test-restore

Dopo il ripristino, verifica manualmente l’integrità dei dati ripristinati. Controlla che i file siano presenti, che le dimensioni siano corrette e, se possibile, verifica l’hash di alcuni file critici rispetto agli originali. Automatizza questo processo con script che confrontano directory o eseguono test funzionali sui dati ripristinati.

Errori comuni e troubleshooting

Errore o messaggio esatto	Causa	Soluzione
`Error: repository does not exist`	Il repository `restic` non è stato inizializzato o il path è sbagliato.	Esegui `restic init` o verifica il path del repository (`-r`).
`Permission denied` durante il backup	L’utente che esegue `restic` non ha i permessi di lettura sui dati o di scrittura sul target.	Assicurati che l’utente abbia i permessi corretti (`sudo`, `chown`, `chmod`).
Backup lento o fallisce su S3	Problemi di connettività, credenziali S3 errate, Object Lock non configurato.	Controlla la connessione di rete, le variabili d’ambiente AWS, e verifica la configurazione Object Lock sul bucket S3.
`Error: data corruption` durante `restic check`	Corruzione dei dati nel repository di backup.	Questo è un errore grave. Potrebbe essere necessario ripristinare da uno snapshot precedente o ricreare il repository se la corruzione è estesa. Controlla l’affidabilità dello storage di destinazione.
Ripristino fallisce o dati incompleti	Snapshot corrotto, problemi di permessi sul target, spazio insufficiente.	Verifica lo snapshot con `restic check`, controlla i permessi sulla directory di destinazione (`--target`) e lo spazio disco.
`Error: S3 bucket does not support object lock`	Il bucket S3 non ha Object Lock abilitato o è abilitato in modalità non compatibile.	Crea un nuovo bucket S3 e abilita Object Lock durante la creazione (non può essere abilitato dopo).

Domande frequenti

Qual è la differenza tra una copia offsite e una copia immutabile?

Una copia offsite è semplicemente una copia dei dati che si trova in una posizione geograficamente diversa da quella principale. Può essere su un altro datacenter o su un servizio cloud. Una copia immutabile, invece, è una copia che non può essere modificata, cancellata o sovrascritta per un periodo di tempo predefinito, indipendentemente dalla sua posizione. Una copia immutabile può anche essere offsite, combinando così i benefici di entrambi gli approcci.

Ogni quanto tempo devo testare i miei backup?

La frequenza dipende dal tuo Recovery Point Objective (RPO) e Recovery Time Objective (RTO). Per dati molto critici, i test dovrebbero essere almeno settimanali o mensili. Per ambienti meno critici, trimestrali potrebbero essere sufficienti. L’importante è che i test siano regolari e automatizzati il più possibile, per ridurre il carico manuale e garantire consistenza.

Il backup 3-2-1-1-0 è valido anche per le macchine virtuali?

Assolutamente sì. La regola è agnostica rispetto al tipo di dato o sistema. Per le VM, i backup possono essere a livello di host (es. con Proxmox Backup Server) o a livello di guest. L’importante è applicare i principi di copie multiple, supporti diversi, offsite, immutabilità e test di ripristino a tutte le tue VM critiche.

Posso usare un semplice disco USB come copia immutabile?

Un disco USB può essere considerato una copia offline se viene fisicamente disconnesso dopo il backup. Questo lo rende immune a ransomware di rete. Tuttavia, non è immutabile nel senso tecnico del termine (i dati possono essere cancellati se il disco viene ricollegato). È una soluzione economica ma richiede gestione manuale e non offre la stessa protezione contro errori umani o accessi non autorizzati come un Object Lock su cloud.

Il 3-2-1-1-0 mi protegge da ogni tipo di perdita dati?

No, nessuna strategia di backup può garantire una protezione completa. Il 3-2-1-1-0 è un framework robusto che mitiga la maggior parte dei rischi, inclusi ransomware, guasti hardware, disastri naturali ed errori umani. Tuttavia, non protegge da bug software che corrompono i dati prima del backup, o da perdite di dati tra un backup e l’altro (a meno che non si implementi un sistema di Continuous Data Protection). È la migliore pratica corrente, ma va integrata con altre misure di sicurezza.

Conclusioni con takeaway operativi

L’evoluzione dalla regola 3-2-1 alla 3-2-1-1-0 è un passaggio obbligato per qualsiasi amministratore di sistema o responsabile della sicurezza che voglia garantire la resilienza dei dati in un ambiente di minacce in continua evoluzione. L’aggiunta di una copia immutabile o offline e l’imperativo dello “zero errori” nei test di ripristino trasformano una buona strategia di backup in una eccellente. Integrare strumenti come restic con servizi cloud che offrono Object Lock permette di automatizzare gran parte di questo processo, riducendo il rischio di errori manuali e garantendo che la tua ultima linea di difesa sia sempre pronta. Non aspettare che sia troppo tardi: rivedi e aggiorna la tua strategia di backup oggi stesso.

Fonti

Aggiornato: novembre 2026