Backup Restore — Cheat Sheet

Tag: backup, restore, rpo, rto, disaster-recovery, rsync

Livello: intermedio

TL;DR: Strategie, metriche e pratiche per garantire la persistenza dei dati e il ripristino operativo in caso di disastro, bilanciando costi e tempi di downtime.

Concetti chiave

RTO (Recovery Time Objective): tempo massimo tollerabile in cui un sistema può rimanere offline prima di causare danni inaccettabili.

RPO (Recovery Point Objective): quantità massima di dati (misurata in tempo) che l'azienda accetta di perdere in caso di guasto.

Backup Completo (Full): copia integrale di tutti i dati. Lento in scrittura, ma offre il ripristino più rapido.

Backup Incrementale: salva solo i dati modificati dall'ultimo backup di qualsiasi tipo. Molto veloce da eseguire, ma il restore richiede tutta la catena.

Backup Differenziale: salva i dati modificati dall'ultimo backup completo. Più veloce del full in scrittura, richiede solo due elementi per il restore.

Regola 3-2-1: mantenere 3 copie dei dati, su 2 tipologie di supporto differenti, di cui 1 conservata offsite (es. cloud).

Snapshot: cattura lo stato di un sistema in un istante preciso. Utile per rollback rapidi, ma non sostituisce un vero backup isolato.

Domande tipiche e risposte pronte

Q: Qual è la differenza operativa principale tra RPO e RTO?R: L'RPO definisce la frequenza con cui devo eseguire i backup (quanto indietro posso tornare), mentre l'RTO definisce l'architettura di restore (quanto in fretta posso tornare operativo).

Q: Come affronti il rischio ransomware sui backup?R: Isolo la destinazione dei backup dalla rete di produzione tramite segmentazione e utilizzo storage immutabile (WORM) per impedire alterazioni post-scrittura.

Q: Pensi che fare un backup giornaliero sia sufficiente?R: Dipende dall'RPO richiesto dal business. Per database critici spesso serve un backup continuo dei log delle transazioni, per i file statici può bastare una volta al giorno.

Insidie e errori comuni

Salvare i dati ma non testare mai le procedure di ripristino fino a quando non avviene un vero incidente.

Confondere la replica dei dati o la high availability (HA) con il backup (se un dato viene cancellato per errore, la replica cancella anche la copia).

Non monitorare silenziosamente lo stato di successo/fallimento dei job di backup schedulati.

Snippet e comandi

# Sincronizzazione incrementale standard di una directory locale verso remota
rsync -avz --delete /var/www/data/ utente@backup-server:/backups/data/

# Dump logico di un database PostgreSQL
pg_dump -U myuser -h localhost -d mydb -F c -f /backups/mydb_$(date +%F).dump

# Ripristino del dump PostgreSQL
pg_restore -U myuser -h localhost -d mydb -1 /backups/mydb_2026-10-22.dump

# Creazione di un archivio tar compresso con timestamp
tar -czvf /backups/config_$(date +%Y%m%d).tar.gz /etc/myapp/

Da ripassare

[ ] Meccanismi di Point-in-Time Recovery (PITR) per i database relazionali

[ ] Politiche di retention (es. schema nonno-padre-figlio) e gestione del ciclo di vita su cloud storage