Backup e Disaster Recovery: Proteggere i Dati del Tuo Sito

Un backup è l'unica protezione che conta quando il sito viene compromesso, il database si danneggia, o il server muore. Eppure molti siti non hanno un backup, o hanno backup non testati che non funzionano quando servono. Questa guida spiega come costruire una strategia di backup solida e un piano di disaster recovery che funziona davvero.

Cosa è il backup e perché non basta averne uno

Un backup è una copia dei tuoi dati (file, database, configurazioni) salvata in un luogo diverso dal server. Se il server viene compromesso o si guasta, puoi ripristinare il sito dal backup.

Ma il 90% dei backup sono inutili perché:

• Non vengono mai testati: un backup che non è mai stato ripristinato è teorico. Potresti scoprire troppo tardi che il backup è corrotto.
• Sono incompleti: il backup contiene solo i file, non il database. O viceversa.
• Sono vecchi: un backup di tre mesi fa significa perdere tre mesi di dati.
• Non sono offsite: se il data center brucia, il backup locale brucia insieme.
• Non sono automatizzati: richiedono un'azione manuale ogni volta — che non succede.

Componenti di una strategia di backup solida

1. Backup giornalieri automatizzati

Il backup deve essere automatico, non una cosa che ricordi di fare. Ogni notte (o ogni ora per siti critici), il sistema deve fare un backup completo di:

• Database: MySQL dump full (schema + data)
• File: tutti i file del sito (code, media, config)
• Configurazioni: file .env, php.ini, vhost Apache, etc

2. Retenzione progressiva

Non puoi tenere backup infiniti (costo). Usa una strategia di retenzione:

• Giornalieri: ultimi 7 giorni (restore veloce per corruzioni recenti)
• Settimanali: ultimi 4 backup (restore a una settimana fa)
• Mensili: ultimi 12 backup (restore a mesi fa)

Così hai una history lunga senza l'overhead di storage infinito.

3. Storage offsite

Il backup locale è una falsa sicurezza. Se il server viene attaccato, il backup locale potrebbe essere eliminato dall'attaccante. Se il data center subisce un incendio, il backup locale brucia insieme al server.

Soluzioni offsite:

• S3 AWS o Backblaze B2: storage cloud a basso costo (€1-5/mese per un sito medio). Automatizzato via API.
• Google Drive o OneDrive: gratuito fino a 5-15 GB, sincronizzazione via rclone o script
• Server dedicato esterno: un VPS su un provider diverso, connesso via SFTP. Costo: €3-5/mese.

Come fare backup: strumenti e implementazione

Opzione 1: Plugin WordPress (se usi WP)

UpdraftPlus, BackWPup, Duplicator: plugin che automatizzano il backup e lo caricano su S3/Dropbox.

# Installazione
wp plugin install updraftplus --activate

# Configurazione via WP Admin UI
# Scegli frequenza (giornaliera), storage (S3), e via — fatto.

Opzione 2: Script Bash automatico (server dedicato)

Crea uno script bash che gira ogni notte via cron:

#!/bin/bash
# backup.sh

BACKUP_DIR="/backups"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mame_db"
DB_USER="root"

# Backup database
mysqldump -u $DB_USER $DB_NAME | gzip > $BACKUP_DIR/db_$DATE.sql.gz

# Backup file sito
tar -czf $BACKUP_DIR/files_$DATE.tar.gz /var/www/mio-sito

# Upload a S3 (richiede aws-cli installato)
aws s3 cp $BACKUP_DIR/db_$DATE.sql.gz s3://mio-bucket-backup/
aws s3 cp $BACKUP_DIR/files_$DATE.tar.gz s3://mio-bucket-backup/

# Cancella backup locali più vecchi di 7 giorni
find $BACKUP_DIR -name "*.gz" -mtime +7 -delete

echo "Backup completato: $DATE"

Poi aggiungi a crontab:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Opzione 3: Servizio gestito (Bacula, Backblaze, Carbonite)

Se non vuoi amministrare il backup, servizi come Backblaze automatizzano tutto. Costo: €50-150/anno per un sito.

Disaster Recovery: il piano per quando il sito va down

Un backup è inutile se non sai come usarlo. Un Disaster Recovery Plan è la documentazione del "come ripristino il sito in caso di emergenza".

Documento DR minimo:

DISASTER RECOVERY PLAN - Mio Sito
==================================

1. CONTATTI EMERGENZA
   - Provider hosting: xxx
   - Amministratore sistema: xxx
   - Numero di emergenza: xxx

2. BACKUP LOCATIONS
   - Offsite primario: AWS S3 bucket "mio-backup"
   - Offsite secondario: Google Drive cartella "Backup"
   - Backup locale: /backups/ (per restore veloce)

3. RIPRISTINO RAPIDO (RTO < 1 ora)
   a. Accedi al server via SSH
   b. Scarica il backup più recente da S3
   c. Ripristina il database:
      mysql < db_backup.sql
   d. Ripristina i file:
      tar -xzf files_backup.tar.gz -C /var/www/
   e. Verifica: curl http://mio-sito.com

4. RIPRISTINO SU NUOVO SERVER (se il vecchio è morto)
   a. Provvigiona un nuovo VPS
   b. Installa Apache, PHP, MySQL
   c. Esegui i passi 3.b-3.e sopra

5. TEST DEL BACKUP
   - Primo lunedì di ogni mese: ripristina il backup su un server test
   - Verifica che il sito funziona
   - Documenta eventuali problemi

6. ESCALATION
   - Se DR > 1 ora, escalate al provider hosting
   - Se DR > 4 ore, comunicare ai clienti

Test del backup: l'unica prova che funziona

Un backup non testato è una scommessa. Il test di backup è semplice:

1. Prendi il backup più recente
2. Ripristinalo su un server di test (una VM, un VPS secondario, o localhost)
3. Verifica che il sito è identico all'originale
4. Documenta il tempo impiegato (RTO)
5. Se fallisce, investigare e riparare il backup

Fai questo test almeno una volta al mese. Se il backup funziona al test, probabilmente funzionerà anche in emergenza.

Costi di backup e storage