Backup WordPress per Agenzie: Disaster Recovery, Automazione e Test di Ripristino [2026]

Perdi un sito WordPress in produzione e il tuo cliente ti chiama alle 23:00. Non hai un backup recente. Buona fortuna.

Questo scenario non è ipotetico. Nella nostra esperienza gestendo oltre 50 siti WordPress per agenzie e PA italiane, il backup è il primo processo che tutti configurano e l’ultimo che qualcuno testa davvero. Il risultato? Backup corrotti, ripristini che falliscono, e notti insonni.

In questa guida ti mostriamo come abbiamo strutturato il sistema di backup e disaster recovery in AgencyPilot, con strategie concrete, automazione reale e (la parte che tutti saltano) test periodici di ripristino.

TL;DR — Il Minimo Indispensabile

Se non hai tempo di leggere tutto:

1. Backup giornaliero automatico (database + file) con retention di 30 giorni
2. Backup off-site su storage separato dal server del sito
3. Test di ripristino mensile su ambiente staging
4. Procedura documentata che chiunque nel team può eseguire
5. Monitoraggio attivo: se il backup fallisce, lo sai entro 5 minuti

Non hai tutto questo? Continua a leggere.

Perché il Backup WordPress per Agenzie È Diverso

Gestire il backup di un singolo blog è banale. Un plugin, un cron, fatto. Ma quando gestisci 10, 20, 50 siti WordPress per clienti diversi, tutto cambia.

I problemi reali:

• Scala. Ogni sito ha dimensioni diverse. Un e-commerce con 40.000 prodotti e 12 GB di media non si backuppa come un sito vetrina da 200 MB.
• Frequenza variabile. Un sito che aggiorna contenuti ogni giorno ha bisogno di backup più frequenti rispetto a uno statico.
• Storage distribuito. Se tutti i backup finiscono sullo stesso server, un guasto disco li elimina tutti. Insieme ai siti.
• Responsabilità contrattuale. Con la PA italiana, perdere dati di un portale istituzionale non è solo un problema tecnico. È un problema legale.

La nostra guida alla gestione multi-sito copre l’organizzazione generale. Qui andiamo nel dettaglio della strategia di backup che usiamo quotidianamente.

La Strategia 3-2-1: Non È Opzionale

La regola 3-2-1 esiste da decenni nell’IT enterprise. Funziona anche per WordPress:

• 3 copie di ogni dato (produzione + 2 backup)
• 2 supporti diversi (disco locale + object storage remoto)
• 1 copia off-site (geograficamente separata)

In pratica, per ogni sito WordPress gestiamo:

I siti critici (e-commerce, portali PA) hanno backup locale ogni ora. Sembra eccessivo finché non perdi 6 ore di ordini WooCommerce.

Backup Database WordPress: mysqldump Non Basta

Il primo istinto di tutti: mysqldump e via. Funziona, ma ha limiti seri quando gestisci decine di database.

Il Problema del Lock

mysqldump con le opzioni di default blocca le tabelle durante l’export. Su un sito con traffico costante, questo significa rallentamenti visibili. Su un e-commerce in orario di punta, significa ordini persi.

La soluzione che usiamo:

#!/bin/bash
# Backup database WordPress senza lock delle tabelle
# Usa --single-transaction per InnoDB (default WordPress)

SITE_NAME="$1"
DB_NAME="$2"
BACKUP_DIR="/backups/daily/${SITE_NAME}"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p "${BACKUP_DIR}"

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  "${DB_NAME}" | gzip > "${BACKUP_DIR}/db_${DATE}.sql.gz"

# Verifica integrità: il file deve essere > 1KB
FILE_SIZE=$(stat -f%z "${BACKUP_DIR}/db_${DATE}.sql.gz" 2>/dev/null || stat -c%s "${BACKUP_DIR}/db_${DATE}.sql.gz")
if [ "$FILE_SIZE" -lt 1024 ]; then
  echo "ERRORE: backup troppo piccolo (${FILE_SIZE} bytes)" >&2
  exit 1
fi

echo "OK: ${BACKUP_DIR}/db_${DATE}.sql.gz (${FILE_SIZE} bytes)"

Il flag --single-transaction è la chiave. Crea uno snapshot consistente del database senza bloccare nulla, a patto che le tabelle usino InnoDB (lo standard di WordPress dal 2013). Il flag --quick evita di caricare l’intero risultato in memoria, fondamentale per database sopra i 500 MB.

Alternativa: Percona XtraBackup

Per siti con database sopra i 2 GB, mysqldump diventa lento anche con le ottimizzazioni. In quei casi usiamo Percona XtraBackup, che fa backup fisici (copia i file del database direttamente) senza downtime. La differenza di velocità è enorme: un database da 5 GB passa da 12 minuti con mysqldump a meno di 2 con XtraBackup.

Backup File WordPress: Cosa Includere (e Cosa No)

Non tutto il filesystem di WordPress merita un backup giornaliero. La directory wp-content/uploads/ cambia spesso. Il core WordPress no.

La nostra strategia di backup file:

Il backup incrementale degli uploads è fondamentale. Un sito con 15 GB di media non può permettersi un backup completo ogni notte: saturerebbe la banda e rallenterebbe il server. Con rsync e il flag --link-dest, copiamo solo i file cambiati dall’ultimo backup:

#!/bin/bash
# Backup incrementale wp-content con rsync
SITE_PATH="$1"
BACKUP_BASE="/backups/files/${2}"
DATE=$(date +%Y%m%d)
LATEST=$(ls -td "${BACKUP_BASE}"/20* 2>/dev/null | head -1)

mkdir -p "${BACKUP_BASE}/${DATE}"

RSYNC_OPTS="-a --delete --compress"
if [ -n "$LATEST" ]; then
  RSYNC_OPTS="${RSYNC_OPTS} --link-dest=${LATEST}"
fi

rsync ${RSYNC_OPTS} \
  --exclude='cache/' \
  --exclude='upgrade/' \
  --exclude='wflogs/' \
  "${SITE_PATH}/wp-content/" \
  "${BACKUP_BASE}/${DATE}/wp-content/"

echo "Backup completato: ${BACKUP_BASE}/${DATE}"

Il trucco di --link-dest: i file non modificati vengono collegati (hard link) al backup precedente. Occupano zero spazio aggiuntivo. Solo i file nuovi o cambiati consumano disco. Su un sito con 15 GB di media e 50 MB di modifiche giornaliere, il backup incrementale occupa appunto 50 MB, non 15 GB.

Automazione con AgencyPilot: Come Orchestriamo Tutto

Lo script singolo funziona per un sito. Per 50 serve orchestrazione. In AgencyPilot abbiamo costruito un sistema che:

1. Cataloga ogni sito con le sue specifiche: dimensione database, dimensione uploads, frequenza di aggiornamento, livello di criticità
2. Assegna la policy di backup automaticamente in base alla criticità (standard, alta, critica)
3. Esegue i backup in sequenza, non in parallelo. 50 backup simultanei ammazzerebbero qualsiasi server.
4. Verifica ogni backup dopo la creazione: dimensione minima, integrità archivio, checksum
5. Notifica solo i problemi. Nessuno vuole 50 email “backup OK”. Vuoi sapere quando qualcosa va storto.

Il principio è semplice: backup silenzioso, errore rumoroso.

Il sistema di monitoraggio che abbiamo descritto si integra direttamente: se un backup fallisce, l’alert parte entro 5 minuti con il dettaglio dell’errore e il nome del sito.

Il Test di Ripristino: La Parte che Tutti Saltano

Un backup che non hai mai testato non è un backup. È una speranza.

Ogni mese, su un ambiente staging dedicato, ripristiniamo almeno 3 siti dal backup. L’intera procedura, dal download del backup al sito funzionante su staging.

Checklist di Ripristino

1. Scarica backup database e file dall’archivio remoto
2. Crea database vuoto su staging
3. Importa il dump SQL
4. Copia i file in una nuova directory
5. Aggiorna wp-config.php con le credenziali staging
6. Esegui search-replace degli URL (produzione → staging) con WP-CLI
7. Verifica: homepage carica, admin accessibile, un post si apre, un form funziona
8. Documenta: tempo totale di ripristino, problemi trovati, azioni correttive

# Ripristino rapido con WP-CLI
wp db import backup_20260320.sql
wp search-replace 'https://sitocliente.it' 'https://staging.agencypilot.it/sitocliente' --all-tables
wp cache flush
wp rewrite flush

Il tempo di ripristino medio per noi è di 8-12 minuti per un sito standard (database sotto 500 MB, uploads sotto 5 GB). Conoscere questo numero è fondamentale: il tuo cliente vuole sapere “quanto ci mettete a rimettere tutto online”. Se non lo sai, non stai facendo disaster recovery. Stai improvvisando.

Disaster Recovery Plan: Oltre il Backup

Il backup è solo una parte del disaster recovery. Il piano completo include:

RTO e RPO per Ogni Sito

Due metriche che ogni agenzia dovrebbe definire per ogni cliente:

• RPO (Recovery Point Objective): quanti dati puoi permetterti di perdere. Un e-commerce con ordini continui ha RPO di 1 ora. Un sito vetrina aggiornato mensilmente ha RPO di 24 ore.
• RTO (Recovery Time Objective): quanto tempo puoi stare offline. Per la PA italiana, spesso il contratto specifica un RTO massimo (tipicamente 4-8 ore lavorative).

Questi numeri guidano tutto: frequenza di backup, infrastruttura necessaria, costo del servizio. Senza RPO e RTO definiti, stai tirando a indovinare.

Runbook Documentato

Il tuo runbook di disaster recovery deve rispondere a una domanda: “Se io (il lead developer) sono irraggiungibile, qualcun altro può ripristinare questo sito?” Se la risposta è no, non hai un piano. Hai una dipendenza da una singola persona.

Il runbook che usiamo in AgencyPilot copre:

• Dove sono i backup (path esatti, credenziali in password manager)
• Come accedere al server (SSH, credenziali, VPN se necessaria)
• Procedura passo-passo di ripristino (con screenshot)
• Chi contattare e quando (escalation matrix)
• Cosa comunicare al cliente (template email pre-scritto)

Sicurezza dei Backup: Il Punto Cieco

Un backup non crittografato è un data breach in attesa di succedere. Dentro un dump WordPress ci sono email utenti, password hashate, dati WooCommerce, informazioni personali.

Le nostre regole:

• Crittografia at-rest: ogni backup viene crittografato con GPG prima del trasferimento off-site
• Crittografia in-transit: tutti i trasferimenti via SSH/TLS
• Accesso limitato: le credenziali di accesso ai backup sono separate da quelle del server
• Retention policy: i backup scaduti vengono eliminati automaticamente (GDPR richiede che non conservi dati oltre il necessario)

Per la sicurezza WordPress in generale, abbiamo una guida dedicata. Qui il punto chiave è: tratta i backup con la stessa attenzione che dedichi al server di produzione.

# Crittografia backup con GPG
gpg --symmetric --cipher-algo AES256 \
  --batch --passphrase-file /etc/backup-passphrase \
  backup_sitocliente_20260320.tar.gz

# Upload crittografato su S3
aws s3 cp backup_sitocliente_20260320.tar.gz.gpg \
  s3://agencypilot-backups/sitocliente/ \
  --storage-class STANDARD_IA

Il flag --storage-class STANDARD_IA (Infrequent Access) dimezza il costo di storage su S3. I backup li accedi raramente (si spera mai). Pagare il prezzo standard non ha senso.

Errori Comuni (Che Abbiamo Fatto Anche Noi)

Trasparenza totale. Ecco cosa abbiamo sbagliato nei primi anni:

1. Backup sullo stesso disco del sito. Disco morto = sito + backup persi. La regola 3-2-1 esiste per questo.
2. Mai testato un ripristino. Il primo test ha rivelato che 3 backup su 20 erano corrotti. Tre siti senza rete di sicurezza.
3. Backup completo ogni notte su siti grandi. Saturavamo la banda del server, rallentando i siti durante le ore notturne (quando i cron di manutenzione girano). Il backup incrementale ha risolto tutto.
4. Nessun monitoraggio. Un cron fallito silenziosamente per 2 settimane. Due settimane senza backup, senza che nessuno se ne accorgesse.
5. Credenziali backup nel repository. La cosa più stupida che abbiamo fatto. Ora tutto passa per il password manager.

FAQ — Domande Frequenti sul Backup WordPress per Agenzie

Ogni quanto devo fare il backup di un sito WordPress?

Dipende dalla frequenza di aggiornamento. Un e-commerce attivo: ogni 1-6 ore. Un sito vetrina: giornaliero. Un sito statico aggiornato mensilmente: settimanale. La domanda giusta è: “quanti dati posso permettermi di perdere?” Quello è il tuo RPO, e definisce la frequenza.

I plugin di backup WordPress sono sufficienti per un’agenzia?

Per un singolo sito, plugin come UpdraftPlus o BlogVault funzionano bene. Per 20+ siti, diventano un problema: ogni plugin ha la sua interfaccia, le sue credenziali storage, i suoi log. Serve un sistema centralizzato che gestisca tutto da un punto unico. È uno dei motivi per cui abbiamo costruito questa funzionalità in AgencyPilot.

Quanto costa una strategia di backup 3-2-1 per 50 siti?

Meno di quanto pensi. Storage S3 Infrequent Access costa circa 0.0125$/GB/mese. Per 50 siti con una media di 2 GB di backup ciascuno (compressi), parliamo di circa 1.25$/mese per lo storage remoto. Il costo vero è il tempo di setup e la disciplina di mantenere il sistema. Lo storage è quasi gratis.

Come gestisco il backup dei siti WordPress su hosting condiviso?

Hosting condiviso limita l’accesso SSH e i cron. In quel caso, un plugin di backup con storage esterno (Google Drive, S3, Dropbox) è la soluzione più pratica. Da AgencyPilot, ci colleghiamo via REST API al plugin installato sul sito e orchestriamo il backup centralmente.

Il mio hosting “include backup giornalieri”. Non basta?

No. I backup dell’hosting sono su infrastruttura dell’hosting. Se il provider ha un problema (succede), perdi sito e backup insieme. E spesso non hai controllo su retention, frequenza o formato. Usali come livello aggiuntivo, mai come unico livello.