Pianificazione di backup e ripristino: proteggi i tuoi file

Un piano di backup e ripristino risponde a due domande numeriche: RPO (quanti dati puoi permetterti di perdere, misurato in tempo) e RTO (quanto a lungo puoi permetterti di essere inattivo). Definiscili per ogni workload, poi progetta a ritroso. Un database con RPO di 5 minuti ha bisogno di WAL shipping continuo; un report marketing settimanale con RPO di 24 ore ha bisogno di un job notturno. Abbinali alla regola 3-2-1 — tre copie, su due tipi di supporto, con una fuori sede — e testa i ripristini trimestralmente. La maggior parte delle storie del tipo "abbiamo i backup" finiscono male perché nessuno ha mai praticato il ripristino.

RPO e RTO: i numeri di partenza

RPO (Recovery Point Objective) = massima perdita di dati accettabile nel tempo. RTO (Recovery Time Objective) = massimo tempo di inattività accettabile.

Esempi per workload:

Database di produzione per un e-commerce: RPO 5 min, RTO 1 ora
Upload file rivolti ai clienti: RPO 15 min, RTO 2 ore
File server interno: RPO 24 ore, RTO 8 ore
Archivio email: RPO 24 ore, RTO 48 ore
Analytics marketing: RPO 24 ore, RTO 72 ore

RPO/RTO più stretti costano di più. Un RPO di 5 minuti significa replica continua (infrastruttura costosa); un RPO di 24 ore significa un job notturno (economico). Non over-engineerare — non tutti i workload hanno bisogno di hot standby.

La regola 3-2-1 funziona ancora

Tre copie dei dati, su due tipi di storage diversi, con una fuori sede. La regola 3-2-1 è precedente al cloud e vale ancora:

Primario: storage di produzione (S3, EBS, disco PostgreSQL)
Secondario: backup su supporto diverso o in una region diversa (un altro bucket S3 con replica, Glacier)
Terziario: fuori sede, idealmente vendor diverso o air-gapped (Backblaze B2, nastro on-prem, dischi fisici in una cassaforte)

Il punto sulla diversità del vendor conta. Un account AWS root compromesso può eliminare tutti i tuoi backup AWS. Un secondario su Backblaze, Wasabi o on-prem sopravvive a quello scenario. Per le aziende sotto i 50 milioni di EUR di fatturato, una copia su secondo vendor aggiunge forse 50-200 €/mese e assicura contro problemi catastrofici a livello di tenant.

Full, incrementale e synthetic full

Tre strategie di backup:

Full: copia tutto ogni volta. Semplice, ripristino veloce (un file), storage pesante.
Incrementale: copia solo ciò che è cambiato dall'ultimo backup. Efficiente in storage, il ripristino richiede full + tutti gli incrementali.
Synthetic full: merge lato server di full + incrementali in un nuovo full virtuale. Ripristino veloce da qualsiasi punto.

I moderni strumenti di backup (Veeam, Rubrik, restic con prune, BorgBackup) usano incremental-forever con synthetic full internamente. Il pattern: incrementale notturno, synthetic full settimanale, conserva 30 giornalieri + 12 mensili + 7 annuali (rotazione grandfather-father-son).

Per un file server da 2 TB con un tasso di modifica giornaliera del 5%, incremental-forever archivia circa 3-5 TB totali per un anno di conservazione — contro 700+ TB se si facessero full notturni.

Cifratura prima della trasmissione

I backup non dovrebbero viaggiare o essere conservati non cifrati. La cifratura lato client con AES-256-GCM (il default in restic, Borg, Duplicacy, Veeam e altri) garantisce che l'host di backup non veda mai il testo in chiaro.

La gestione delle chiavi conta più della scelta dell'algoritmo. Un backup cifrato con una chiave conservata nello stesso account AWS del backup è teatro — un attaccante con accesso IAM ottiene entrambi. Conserva le chiavi in:

AWS KMS con una chiave di account separato (decifratura cross-account)
HashiCorp Vault in un ambiente fuori banda
Un hardware security module (YubiKey, HSM) per la chiave root
Una copia cartacea stampata e sigillata per le chiavi davvero critiche

Ruota regolarmente (annualmente), registra ogni utilizzo e testa il ripristino con una chiave ruotata prima che la rotazione entri in vigore in produzione.

Immutabilità: la risposta al ransomware

Gli attacchi ransomware nel 2025 colpiscono comunemente prima i backup — cifrano i dati di produzione, poi eliminano o cifrano i backup per impedire il ripristino. I backup immutabili sconfiggono questo schema.

Implementazioni:

S3 Object Lock (Compliance Mode): nemmeno root può eliminare per il periodo di conservazione
Azure Blob immutable storage: simile, applicato a livello di container
Veeam Hardened Linux Repository: append-only, solo SSH, nessuna API di cancellazione
Nastro fisico in un caveau: l'air gap definitivo

Per i dati business-critical, almeno una copia di backup dovrebbe essere immutabile per il periodo di conservazione. Il costo incrementale è solitamente zero — la conservavi comunque. Il valore quando arriva il ransomware è totale.

Test: la parte non opzionale

Un backup che non hai mai ripristinato non è un backup; è speranza. Programma di test per priorità:

Tier 1 (mission-critical): esercitazione di ripristino completo trimestralmente, ripristino file casuale mensilmente
Tier 2 (business-importante): esercitazione di ripristino completo semestralmente, ripristino file casuale trimestralmente
Tier 3 (standard): esercitazione di ripristino completo annualmente, ripristino file casuale trimestralmente

Registra nel test:

Quanto tempo ha richiesto il ripristino (confronta con RTO)
I dati corrispondevano allo stato di produzione (checksum rispetto a un punto noto)
Permessi o configurazioni hanno fallito nel ripristino
Cosa si è rotto e come è stato risolto

Le aziende che saltano i test scoprono i backup corrotti durante gli incidenti reali, che è il momento più costoso per imparare qualcosa.

I backup dei database hanno bisogno di un piano proprio

File e database si archiviano in modo diverso. Una directory .pgdata copiata a metà transazione è corrotta. Usa gli strumenti nativi:

PostgreSQL: pg_basebackup + archiviazione WAL per PITR, pg_dump per il logico
MySQL: Percona XtraBackup per il fisico hot, mysqldump per il logico
MongoDB: mongodump, replica set con secondari ritardati
Microsoft SQL Server: backup nativo con BACKUP DATABASE, log shipping per PITR

Per un database PostgreSQL da 500 GB con RPO di 5 minuti, backup base notturni + archiviazione WAL continua su S3 ti danno point-in-time recovery a qualsiasi secondo negli ultimi 30 giorni. Tempo di ripristino: recupera il backup base (30 min), riproduci il WAL fino all'ora target (5-30 min). RTO stretto significa una replica warm pronta alla promozione.

Snapshot consistenti con le applicazioni

Gli snapshot del filesystem (ZFS, Btrfs, AWS EBS, Azure managed disk, GCP persistent disk) congelano un punto nel tempo a livello di blocco. Per i database, combina con il quiesce dell'applicazione:

pg_start_backup('label') (PostgreSQL) o FLUSH TABLES WITH READ LOCK (MySQL)
Esegui lo snapshot
pg_stop_backup() o sblocca

Lo snapshot è consistente con l'applicazione — utilizzabile per il ripristino senza crash recovery. AWS Backup, Azure Backup e Google Cloud Backup automatizzano questo pattern per i database comuni.

Distribuire gli archivi di backup a terze parti

Quando i backup devono andare a parti esterne — revisori, autorità regolamentari, amministratori successori — il trasferimento stesso richiede attenzione. FTP è antiquato; gli allegati email hanno limiti di dimensione; consegnare chiavette USB è lento.

Il trasferimento file cifrato end-to-end gestisce la distribuzione ad-hoc dei backup in modo pulito. HexaTransfer sposta file fino a 10 GB con cifratura AES-256-GCM lato client e un link monouso. Utile per inviare uno snapshot del database a un revisore del Garante della Privacy senza concedergli accesso ai tuoi bucket S3.

La documentazione fa parte del backup

Il miglior backup del mondo è inutile se la persona che sa come ripristinarlo è in vacanza e nessun altro sa come fare. Documenta:

Cosa è incluso nel backup e cosa no (esclusioni esplicite)
Programma e conservazione per workload
Gestione delle chiavi e accesso
Runbook di ripristino con comandi passo dopo passo
Lista contatti (supporto vendor, on-call)
Risultati e date dei test

Stampa una copia. Conserva una copia nella cassaforte fisica con le chiavi di emergenza. Se il runbook di backup vive solo in una pagina Confluence servita dalla stessa infrastruttura che è appena andata giù, hai un problema. La carta funziona ancora quando nient'altro funziona.

Definisci RPO/RTO, implementa 3-2-1 con immutabilità, cifra lato client, testa trimestralmente, documenta in modo ossessivo. Il successo del backup è 10% tecnologia e 90% disciplina.

Provalo su hexatransfer.com — gratuito, senza account, max 10 GB.