Backup e ripristino: differenza, RPO, RTO e regola 3-2-1

Quasi tutti gli hosting scrivono «backup inclusi». È utile saperlo, ma risponde alla domanda sbagliata: quando un aggiornamento rompe il sito o qualcuno cancella per errore metà del catalogo, nessuno chiede se esiste un backup. Si chiede quanto ci vuole a tornare online e quanti dati sono andati persi.

Backup e ripristino: perché non sono la stessa cosa

Il backup è un oggetto: un archivio di file e database salvato a una certa ora. Il ripristino è un processo: rimettere quell'archivio su un server funzionante, ricollegare database, configurazione, DNS e certificati, e controllare che il sito risponda come prima. Il primo si automatizza; il secondo coinvolge persone, credenziali e decisioni, ed è lì che le cose si inceppano. Le cause tipiche di un ripristino fallito:

• Archivio vuoto o troncato: il job è andato in timeout o il disco era pieno, e nessuno leggeva gli esiti.
• C'è la cartella del sito ma non il database, o viceversa. La documentazione di WordPress è chiara: per ripristinare un sito servono entrambi.
• Dump del database fatto mentre il sito scriveva, quindi incoerente.
• Backup sullo stesso server o nello stesso account del sito: se perdi l'uno, o qualcuno ottiene l'accesso, perdi anche l'altro.
• Conservazione troppo corta: con due settimane di copie, un'infezione entrata tre settimane fa è già in ogni copia disponibile.
• Password del pannello, accesso allo storage remoto o chiavi di cifratura note a una sola persona.
• Procedura mai cronometrata: «ci vuole un'ora» è una stima a sentimento.

RPO e RTO spiegati con esempi

Due sigle trasformano «abbiamo i backup» in un impegno misurabile. Le definizioni di riferimento sono quelle della guida NIST SP 800-34 sulla continuità operativa.

• RPO (Recovery Point Objective): il punto nel tempo a cui i dati devono poter essere riportati dopo un incidente. Tradotto: quanti dati puoi permetterti di perdere. Se il backup parte ogni notte alle 2:00 e il server si guasta alle 18:00, perdi fino a 16 ore di modifiche.
• RTO (Recovery Time Objective): quanto a lungo il sistema può restare in fase di ripristino prima che il danno per l'attività diventi inaccettabile. Tradotto: entro quando il sito deve tornare online.

L'RPO dipende soprattutto dalla frequenza dei backup. L'RTO dipende da quanto pesa l'archivio, da dove si trova e da quanto è collaudata la procedura: 40 GB su uno storage remoto lento possono richiedere ore solo per il download, prima ancora di iniziare il ripristino. Qualche esempio, con valori indicativi da decidere caso per caso con chi conosce il business:

La regola 3-2-1 applicata a un sito web

La regola 3-2-1, raccomandata tra gli altri dall'agenzia statunitense CISA, è semplice: tre copie dei dati importanti (l'originale più due backup), su due tipi di supporto diversi, con una copia fuori sede. Su un sito ospitato diventa così:

• Copia 1: il sito in produzione.
• Copia 2: un backup vicino, per esempio nella cartella di backup del server o nello storage dello stesso fornitore. È la più rapida da ripristinare e copre gli errori di tutti i giorni.
• Copia 3: un backup lontano, su un'altra infrastruttura o presso un altro fornitore, con credenziali diverse da quelle del sito. Ti salva se perdi il server, l'account o l'accesso al pannello.

cPanel/WHM ne è un buon esempio: di default salva i backup nella cartella locale /backup del server, e la sua documentazione raccomanda con decisione di aggiungere una destinazione remota (S3 compatibile, SFTP, rsync e altre). Il National Cyber Security Centre britannico aggiunge due indicazioni pratiche: non affidarsi a due copie sullo stesso disco rimovibile e non lasciare i dispositivi di backup collegati in permanenza alla rete.

Ogni quanto fare il backup: sito vetrina ed e-commerce

La frequenza giusta non è «il più spesso possibile»: è quella che rispetta il tuo RPO. La documentazione di WordPress suggerisce un backup settimanale per i siti piccoli con pochi contenuti e uno giornaliero per quelli molto attivi, conservando almeno 3-5 copie recenti in posti diversi. È un buon punto di partenza, da adattare.

Sito vetrina

Per un sito che cambia poche volte al mese, un backup giornaliero di file e database dà già un RPO di 24 ore. Contano di più il backup manuale prima di ogni intervento (aggiornamento di WordPress, di PHP o di un plugin importante) e una conservazione abbastanza lunga: su un sito poco visitato una pagina alterata può restare online per settimane prima che qualcuno se ne accorga.

E-commerce

In un negozio online il database cambia di continuo: ordini, clienti, giacenze. Con un backup notturno puoi perdere fino a un giorno di ordini. Per abbassare l'RPO le strade sono due: dump del database più frequenti, per esempio ogni ora, con il backup completo dei file una volta al giorno; oppure il ripristino point-in-time di MySQL, che parte da un backup completo e riapplica le modifiche registrate nel binary log fino a un momento preciso. Richiede configurazione e competenza, ma è la più vicina a non perdere nulla.

Due dettagli che contano. Un dump fatto a sito acceso deve essere coerente: con tabelle InnoDB, l'opzione --single-transaction di mysqldump esporta lo stato del database a un istante preciso senza bloccare le applicazioni. E se ripristini il database di ieri, gli ordini di oggi spariscono dal sito ma non dal gateway di pagamento: prepara una procedura di riconciliazione prima di averne bisogno.

# Dump coerente di un database InnoDB, senza bloccare il sito
mysqldump --single-transaction --quick nome_db | gzip > nome_db-$(date +%F-%H%M).sql.gz

Come fare un test di ripristino periodico

Un test di ripristino non è un progetto: bastano un ambiente separato, un cronometro e un registro. La procedura che consigliamo:

1. Scegli un backup a caso tra quelli conservati, non sempre l'ultimo: verifichi anche che le copie più vecchie siano integre.
2. Prepara un ambiente isolato: un sottodominio di staging protetto da password ed escluso dall'indicizzazione, oppure un account separato.
3. Prima di avviare la copia, disattiva invio email, cron e webhook verso gateway di pagamento o gestionali: la copia di un e-commerce può mandare email vere a clienti veri.
4. Avvia il cronometro e ripristina file e database seguendo la procedura scritta, non la memoria. Il tempo totale è il tuo RTO misurato.
5. Verifica home e pagine principali, accesso all'area amministrativa, immagini caricate di recente, form di contatto e, per un e-commerce, checkout in modalità di test.
6. Guarda la data dell'ultimo contenuto o dell'ultimo ordine presente: la distanza dal momento dell'incidente simulato è il tuo RPO reale.
7. Annota data, backup usato, durata, problemi e chi ha eseguito il test; poi correggi la procedura dove si è inceppata.
8. Elimina l'ambiente di prova: contiene una copia completa dei dati, compresi quelli personali dei clienti.

# Ripristino del dump in un database di prova vuoto
mysql -e 'CREATE DATABASE restore_test'
gunzip < nome_db-2026-10-13-0200.sql.gz | mysql restore_test

# Controlli rapidi (wp_ è il prefisso predefinito di WordPress)
mysql -e 'SELECT COUNT(*) FROM restore_test.wp_posts'
mysql -e 'SELECT MAX(post_modified) FROM restore_test.wp_posts'

Ogni quanto ripeterlo? Il GDPR parla di verifiche regolari ma non fissa una cadenza. Come regola pratica: almeno ogni trimestre per i siti vetrina, ogni mese per e-commerce e siti con dati dei clienti, e sempre dopo una migrazione, un cambio di hosting o di plugin di backup, una nuova versione di PHP.

Checklist backup e ripristino

1. RPO e RTO scritti per ogni sito, concordati con il cliente.
2. Backup completo di file e database, con frequenza coerente con l'RPO.
3. Backup manuale prima di ogni aggiornamento importante.
4. Almeno una copia su un'infrastruttura diversa, con credenziali separate da quelle del sito.
5. Conservazione abbastanza lunga da coprire problemi scoperti in ritardo, con più versioni disponibili.
6. Esito di ogni backup monitorato, con un avviso se il job fallisce o l'archivio è anomalo.
7. Chiarito se le caselle email sono comprese nel backup del sito o vanno protette a parte.
8. Procedura di ripristino scritta e consultabile anche senza il server di produzione.
9. Credenziali e chiavi di cifratura dei backup custodite da almeno due persone.
10. Test di ripristino periodico con tempi misurati, registro aggiornato e ambiente di prova eliminato a fine test.

Le domande da fare al tuo hosting

«Backup inclusi» non è una risposta. Prima di affidare un sito, chiedi:

• Cosa viene salvato: file, database, email, zone DNS?
• Con che frequenza, e per quanti giorni vengono conservate le copie?
• Dove si trovano: stesso server, stesso data center o infrastruttura separata?
• Posso ripristinare da solo un singolo file o un database, o devo aprire una richiesta? Ci sono costi?
• Quando è stato fatto l'ultimo test di ripristino e quanto è durato?

Un fornitore serio risponde con numeri e date, non con aggettivi. In lubemy verifichiamo i backup con test di ripristino periodici e ne registriamo i tempi: se vuoi che ce ne occupiamo noi, partiamo dai tuoi RPO e RTO messi per iscritto e da quello che possiamo dimostrarti.