Backup incrementale WordPress: differenze con il completo e quando serve davvero

Il backup completo è il primo che si impara: ogni notte si copia tutto — file e database — in un'area di storage separata. È semplice da capire e semplice da ripristinare, perché il ripristino è un'operazione singola: prendi l'ultimo backup, ripristini, il sito torna. Il problema è che su un sito di 5 GB, trasferire 5 GB ogni notte consuma banda, I/O e tempo — anche se rispetto al giorno prima è cambiato solo un articolo da 2 KB.

Il backup incrementale risolve questo: dopo un backup completo iniziale, i successivi inviano solo i blocchi modificati. Su un sito che cambia poco, il backup notturno passa da 5 GB a 20 MB. La banda risparmiata è enorme, e su hosting con limiti di trasferimento fa la differenza tra un servizio sostenibile e uno che costa troppo. Ma il ripristino non è più un'operazione singola: serve ripristinare il completo più ogni incrementale fino al punto desiderato, in ordine.

Il ripristino incrementale: la catena che non si spezza

La catena di backup incrementali è fragile per definizione: se un anello è corrotto o perso, i successivi diventano inutilizzabili perché si basano su di esso. Per questo un backup incrementale serio prevede periodicamente un nuovo completo — il 'full backup sintetico' — che consolida la catena in un unico punto di ripristino. Senza questa consolidazione, dopo mesi di incrementali il ripristino diventa un'operazione lunga e rischiosa.

La domanda operativa non è 'completo o incrementale', ma 'quanto vale il mio RPO'. Il RPO — Recovery Point Objective — è quanto dati posso permettermi di perdere. Un sito vetrina che cambia una volta a settimana tollera un backup completo notturno: al massimo perde le modifiche di un giorno. Un e-commerce che processa ordini ogni ora ha un RPO di minuti, e lì né il completo né l'incrementale notturno bastano: serve il realtime.

# Backup incrementale dei file con rsync (differenziale vs completo)
# Il flag --link-dest crea hard link ai file non modificati:
# trasferisce solo il delta, ma ogni snapshot è un backup completo
# indipendente (ripristino singolo, non a catena).

rsync -a --delete \
  --link-dest=/backup/wordpress-2026-11-09/ \
  /var/www/wordpress/ \
  /backup/wordpress-2026-11-10/

# Verifica la dimensione del delta trasferito
du -sh /backup/wordpress-2026-11-10/
# Se il sito è cambiato poco, pesa pochi MB invece di GB.

# Backup del database: dump incrementale con binlog (MySQL)
# Richiede binlog abilitato in my.cnf: log_bin = mysql-bin
mysqlbinlog --start-datetime='2026-11-09 00:00:00' \
  /var/lib/mysql/mysql-bin.000123 > /backup/db-incrementale.sql

Il backup realtime: una terza categoria

Il backup realtime non è un incrementale veloce: è un paradigma diverso. Invece di scattare foto periodiche, replica ogni scrittura sul database primario verso una replica — tipicamente via binlog streaming o replica sincrona. Il RPO scende a secondi o a zero. Il costo è di infrastruttura: serve una replica sempre attiva, con le sue risorse, e una rete a bassa latenza tra primario e replica.

Il realtime ha senso quando il costo di perdere dati supera il costo dell'infrastruttura: e-commerce con ordini continui, editoriali che pubblicano ogni ora, forum e community con contenuti generati dagli utenti. Su un sito vetrina che cambia una volta a settimana, il realtime è sprecato — il completo notturno basta e avanza. La regola è abbinare il tipo di backup al valore dei dati, non alla moda del momento.

Un backup non è tale finché non è stato ripristinato con successo. Lo ripetiamo spesso perché è il punto in cui tutti scoprono i problemi: il backup c'era, ma era corrotto, o incompleto, o il ripristino richiedeva un accesso che nessuno aveva più. Un piano di disaster recovery testato periodicamente — ripristinare in un ambiente isolato e verificare — è l'unica prova reale che il backup funziona. Un check-up dell'infrastruttura include sempre questa verifica.