In breve: una strategia di backup solida per i server segue la regola 3-2-1: tre copie, due tipi di supporto, una copia fuori sede. Perché i backup superino anche un attacco, almeno una copia deve essere protetta dalla cancellazione da parte del server stesso. E solo un test di ripristino riuscito dimostra che il salvataggio funziona nel momento critico.
Che cosa significa la regola 3-2-1
La regola 3-2-1 è un principio semplice, collaudato da anni, per il salvataggio dei dati:
- 3 copie: i dati originali e due backup.
- 2 tipi di supporto: ad esempio disco locale e object storage, oppure storage del server e nastro.
- 1 copia fuori sede: in un'altra sede, presso un altro fornitore oppure offline.
Per i server web significa in concreto: un backup sullo stesso disco del sito non conta come copia autonoma. Se il server si guasta o viene compromesso, vanno perse entrambe. Per la direzione la domanda centrale non è perciò «Abbiamo dei backup?», ma «Possiamo ripristinare l'attività da una copia che l'incidente non ha raggiunto?»
Una strategia di backup per server che superi un attacco
Gli aggressori sanno che i backup vanificano il loro lavoro. Chi ha accesso a un server cerca perciò spesso anche i backup, per cancellarli o cifrarli. Una strategia moderna estende quindi spesso la regola 3-2-1 a 3-2-1-1-0: una copia in più offline o non modificabile e zero errori nel test di ripristino.
Tre principi rendono i backup resistenti:
- Pull invece di push: un sistema di backup separato preleva i dati dal server web. Il server web stesso non ha credenziali con cui potrebbe cancellare i backup.
- Immodificabilità: object storage con blocco della conservazione o snapshot che per un tempo stabilito non si possono cancellare.
- Accessi separati: l'account di backup non è lo stesso dell'account cliente dell'hosting e ha un proprio secondo fattore.
Cifri i backup che si trovano fuori sede e conservi la chiave separatamente. Una chiave persa rende il backup inutilizzabile, una chiave salvata insieme rende la cifratura priva di valore.
Che cosa deve essere salvato
Per i server web spesso si salva solo la webroot. Per un ripristino completo mancano allora parti importanti.
| Area | Esempi | Nota |
|---|---|---|
| File dell'applicazione | webroot, upload, temi, estensioni | gli upload cambiano spesso |
| Database | MySQL/MariaDB, PostgreSQL | salvare in modo coerente, non solo copiare i file |
| Configurazione | server web, pool PHP-FPM, php.ini, cronjob | necessaria per una ricostruzione rapida |
| Certificati e chiavi | certificati TLS, chiavi dell'applicazione | conservare cifrati e separati |
| Documentazione | accessi, dipendenze, procedura di ripristino | senza di essa ogni ricostruzione richiede più tempo |
Esempio: salvare database e file
L'esempio seguente mostra gli elementi di base di un salvataggio giornaliero. Nella pratica un software di backup con cifratura, deduplicazione e regole di conservazione si occupa del trasferimento fuori sede.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Salvare il database in modo coerente; credenziali da un file protetto, non nel comando
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# File dell'applicazione e configurazione
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Checksum per il controllo successivo
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Il file .backup-my.cnf contiene le credenziali di un utente di database che può solo leggere e ha i permessi 0600. --single-transaction garantisce per le tabelle InnoDB uno stato coerente senza fermare lo shop.
Poi un sistema separato trasferisce il backup fuori sede. È importante che questo passo sia monitorato: un job di backup che fallisce in silenzio da giorni emerge altrimenti solo nel momento critico. Basta una segnalazione giornaliera su esito, dimensione e durata, purché qualcuno la legga e verifichi le differenze.
Se usa in aggiunta backup o snapshot del Suo hoster, chiarisca per iscritto per quanto tempo vengono conservati, se può ripristinare da solo e se i backup restano disponibili in caso di account disdetto o bloccato. Queste copie sono un buon complemento, ma non sostituiscono un salvataggio proprio e indipendente.
Conservazione: perché dopo PHP2Shell gli stati più vecchi sono importanti
Dopo un attacco il backup più prezioso non è il più recente, ma il più recente pulito. Con PHP2Shell, secondo i media, il 17/10/2026 è stato osservato un primo tentativo di attacco e le patch sono uscite il 21/10/2026. Chi conserva solo sette giorni potrebbe non avere più uno stato sicuramente precedente alla possibile intrusione.
Uno schema collaudato combina più periodi, ad esempio backup giornalieri per alcune settimane, settimanali per alcuni mesi e mensili per un anno. I periodi esatti dipendono dal Suo bisogno di protezione e dagli obblighi di cancellazione derivanti dalla protezione dei dati.
È importante anche questo: un backup del periodo successivo a un'intrusione può contenere webshell o file modificati. Dopo un incidente non ripristini mai alla cieca, ma confronti i file con uno stato pulito e li verifichi prima che il sito torni online. Indicazioni su cosa osservare si trovano in Segnali di compromissione. Una patch non rimuove il malware introdotto, e nemmeno un backup lo fa da solo.
Testare e documentare il ripristino
Un backup senza test è un'ipotesi. Solo il ripristino mostra se tutte le parti sono presenti, se la chiave funziona e quanto dura effettivamente l'operazione.
- Ripristini regolarmente un salvataggio completo in un ambiente di test, database e configurazione inclusi.
- Verifichi che il sito funzioni poi completamente: login, ordini, moduli, e-mail.
- Misuri la durata e annoti quali passi sono stati manuali. Confronti il risultato con il tempo massimo che la Sua attività può reggere senza sito.
- Depositi le istruzioni di ripristino dove siano raggiungibili anche a server inattivo, ad esempio nel piano di emergenza IT.
Come aiuta concretamente PHP SOS?
- Verifichiamo i Suoi backup esistenti per completezza, conservazione, separazione dal server e protezione dalla cancellazione.
- Impostiamo un salvataggio 3-2-1 con copia non modificabile e testiamo il ripristino insieme a Lei.
- Dopo un incidente individuiamo l'ultimo stato pulito e lo ripristiniamo su un sistema aggiornato nell'ambito della rimozione del malware.
- Nel contratto di manutenzione della sicurezza monitoriamo costantemente i backup ed eseguiamo regolari test di ripristino.
Domande frequenti
Che cosa significa la regola 3-2-1 per i backup?
Tre copie dei Suoi dati, su due tipi di supporto diversi, di cui una in un altro luogo. La regola fa sì che né un guasto hardware né un attacco né un incendio colpiscano tutte le copie contemporaneamente.
Basta il backup del mio hoster?
È un buon complemento, ma raramente sufficiente. Chiarisca per quanto tempo l'hoster conserva gli stati, se può ripristinare da solo e se un aggressore con il Suo account cliente potrebbe cancellare i backup. È consigliabile una copia propria e indipendente.
Dopo un hack posso semplicemente ripristinare l'ultimo backup?
Solo con cautela. L'ultimo backup può già contenere codice dannoso e la vulnerabilità da cui è entrato l'aggressore resta poi aperta. Prima chiarire e chiudere la causa, poi ripristinare uno stato verificato su un sistema aggiornato.
Ogni quanto dovrei testare il ripristino?
Regolarmente e dopo modifiche importanti al sistema. Un ritmo fisso, ad esempio un ripristino completo a trimestre in un ambiente di test, si è dimostrato valido. È importante che il test sia documentato e che le lacune vengano risolte.