Ogni agenzia WordPress che gestisce più di cinque siti clienti ha già vissuto almeno una volta quella telefonata: “Il sito non funziona più. Cosa è successo?”. La domanda che segue immediatamente, nel panico dei minuti successivi, è quasi sempre la stessa: “L’ultimo backup quando risale?”.
Il backup WordPress non è una funzionalità opzionale da attivare “quando c’è tempo”. È l’infrastruttura di sicurezza sulla quale si regge tutta la reputazione di un’agenzia. Questa guida ti fornisce un sistema completo: dalla teoria alla pratica, dai comandi WP-CLI agli strumenti giusti, fino a come gestire backup di 10, 20 o 50 siti senza perdere la testa.
Il Costo del Downtime per un’Agenzia WordPress
Prima di entrare nel tecnico, è necessario capire cosa si rischia concretamente. Molte agenzie sottovalutano il costo reale di un incidente, perché calcolano solo il tempo di ripristino e non l’impatto a lungo termine.
I numeri concreti
Secondo i dati Gartner, il costo medio del downtime per le piccole e medie imprese si attesta intorno agli 8.000 euro all’ora. Per un e-commerce con 500 ordini giornalieri, anche solo quattro ore di inattività possono significare 2.000 euro di mancato fatturato diretto — senza contare i danni alla fiducia dei clienti finali.
Per un’agenzia, le implicazioni sono diverse ma ugualmente gravi:
- Perdita del cliente: un sito offline per ore senza una risposta professionale mette a rischio il contratto di manutenzione.
- Ore non fatturabili: il ripristino manuale su un sito senza backup può richiedere 6-12 ore di lavoro tecnico da assorbire internamente.
- Danno reputazionale: i clienti parlano tra di loro. Un disastro gestito male si trasforma in recensioni negative e passaparola negativo.
- Responsabilità legale: se il cliente ha perso dati sensibili (ad esempio dati di un e-commerce), le implicazioni GDPR possono essere significative.
Scenari reali che accadono ogni settimana
Un aggiornamento automatico di un plugin WooCommerce che rompe il checkout. Un attacco brute-force che inietta malware nei file PHP. Un hosting provider che migra i server e corrode la struttura del database. Un errore umano durante l’aggiornamento di un tema custom. Un certificato SSL scaduto che viene frainteso dall’hosting come sito compromesso e portato offline.
Nessuno di questi scenari è eccezionale. Sono eventi statisticamente probabili su qualsiasi portfolio di 20+ siti in un anno.
La domanda non è “se” accadrà, ma “quando” e “come sarete pronti”.
La Regola del 3-2-1 Applicata a WordPress
La regola del 3-2-1 è il fondamento di qualsiasi strategia di backup professionale. Nasce dall’industria fotografica negli anni ’90 e si è affermata come standard universale in tutti i contesti IT. Applicata a WordPress, funziona così:
- 3 copie totali dei dati: la copia di produzione attiva sul server, una copia locale (o sullo stesso hosting su storage separato), una copia offsite.
- 2 supporti diversi: almeno due tecnologie di storage differenti. Non due cartelle sullo stesso server.
- 1 copia offsite: almeno una copia deve trovarsi fisicamente o logicamente separata dall’infrastruttura principale.
Come implementare il 3-2-1 in pratica
| Copia | Dove | Tecnologia | Frequenza |
|---|---|---|---|
| Copia 1 (produzione) | Server hosting | File system + MySQL | In tempo reale |
| Copia 2 (locale) | Stesso hosting, storage separato | Snapshot / file compressi | Giornaliera |
| Copia 3 (offsite) | Cloud esterno | Google Drive / S3 / Backblaze | Giornaliera o settimanale |
Perché il 3-2-1 non è negoziabile per un’agenzia
Se hai solo il backup sull’hosting e l’hosting stesso va down, hai perso tutto. Se hai solo il backup sul tuo NAS in ufficio e c’è un incendio, hai perso tutto. La distribuzione geografica e tecnologica delle copie è l’unico modo per garantire la sopravvivenza dei dati in scenari estremi.
Per un’agenzia che gestisce siti di terzi, questo non è nemmeno solo una questione tecnica: è una questione contrattuale. Molti clienti enterprise richiedono esplicitamente documentazione della strategia di backup come condizione del contratto di manutenzione.
Cosa Includere nel Backup: File, Database e Configurazioni
Un errore comune è considerare il “backup WordPress” come sinonimo di “backup del database”. Il database è fondamentale, ma da solo non è sufficiente per un ripristino completo. Un backup WordPress professionale include quattro componenti distinti.
1. La cartella wp-content
Contiene i media caricati (immagini, PDF, video), i plugin installati, i temi attivi e personalizzati, i file di cache (se non rigenerabili), i file personalizzati dei plugin premium. Questa è spesso la parte più voluminosa del backup — su un sito maturo può pesare svariati gigabyte.
2. Il database MySQL
Contiene post, pagine, impostazioni, utenti, metadati WooCommerce, form submissions, log di accesso e tutte le tabelle dei plugin. Senza il database, i file wp-content sono inutili. Senza i file, il database è incompleto.
3. wp-config.php e .htaccess
wp-config.php contiene le credenziali del database, i prefissi delle tabelle, i salt delle chiavi di sicurezza e le costanti personalizzate. .htaccess contiene le regole di rewriting e le direttive di sicurezza personalizzate. Questi file non fanno parte di wp-content ma sono essenziali per il ripristino.
4. File di configurazione server (quando possibile)
Se l’agenzia gestisce anche il server (VPS o dedicated), è buona pratica includere nei backup anche la configurazione Nginx/Apache, i file cron di sistema e le variabili d’ambiente.
Cosa NON include il backup
Per ottimizzare dimensioni e tempi, si escludono tipicamente: la cartella wp-content/cache/ (rigenerabile), i log di debug, i file temporanei e i file del core WordPress (scaricabili da wordpress.org in qualsiasi momento).
Un backup ottimizzato esclude il core ma include tutto il resto:
# Backup selettivo con WP-CLI — esclude cache e log
wp db export /backup/db-$(date +%Y%m%d).sql
tar -czf /backup/files-$(date +%Y%m%d).tar.gz wp-content/ wp-config.php .htaccess --exclude=wp-content/cache --exclude=wp-content/debug.log
Strumenti di Backup a Confronto
Il mercato offre diversi strumenti per il backup WordPress. La scelta dipende da scala, budget e livello di automazione richiesto.
| Strumento | Tipo | Prezzo | Punti di forza | Limiti |
|---|---|---|---|---|
| UpdraftPlus | Plugin WP | Gratuito / €70 anno (premium) | Semplicissimo, ottimo storage remoto, largo supporto cloud | Gestione centralizzata assente: va configurato sito per sito |
| BlogVault | SaaS cloud | Da $7.4/sito/mese | Backup incrementali real-time, staging integrato, ottimo per WooCommerce | Costoso su portfolio grandi; nessun controllo sull’infrastruttura |
| BackupBuddy | Plugin WP | Da $99/anno (10 siti) | Molto completo, stager, ImportBuddy per ripristino guidato | Non scalabile per agenzie con 30+ siti, interfaccia datata |
| ManageWP | SaaS cloud | Da €2/sito/mese con add-on | Dashboard centralizzata per aggiornamenti + backup | Backup come add-on separato; sviluppo rallentato post-GoDaddy |
| WP-CLI | CLI locale | Gratuito | Massimo controllo, scriptabile, integrabile in pipeline CI/CD | Richiede accesso SSH, setup manuale per ogni sito |
UpdraftPlus: il punto di partenza
UpdraftPlus è il plugin di backup WordPress più installato al mondo, con oltre 3 milioni di installazioni attive. La versione gratuita supporta backup completi schedulati su Google Drive, Dropbox, Amazon S3, FTP e molti altri provider. La versione premium aggiunge backup incrementali, backup del database separato, multisite e alcuni strumenti di migrazione.
Il limite principale è strutturale: UpdraftPlus richiede configurazione sito per sito. Per un portfolio di 20 siti, questo significa 20 pannelli admin da visitare, 20 configurazioni da mantenere aggiornate, 20 posti dove le cose possono andare storte silenziosamente.
WP-CLI: il controllo totale
WP-CLI è lo strumento da riga di comando ufficiale di WordPress. Per le agenzie con accesso SSH ai server, è lo strumento più potente disponibile perché consente automazione completa via script.
# Esportazione database con timestamp
wp db export --add-drop-table /backups/$(wp eval 'echo sanitize_title(get_bloginfo("name"));')-$(date +%Y%m%d-%H%M%S).sql
# Verifica integrità del database dopo il backup
wp db check
# Ottimizzazione database prima del backup
wp db optimize
# Export tabelle specifiche (utile per backup parziali)
wp db export --tables=wp_posts,wp_postmeta,wp_options /backups/partial.sql
BlogVault: la scelta per e-commerce critici
BlogVault si distingue per il backup incrementale in tempo quasi reale (ogni 24 ore con storico delle modifiche), particolarmente adatto per siti WooCommerce ad alto volume di transazioni dove ogni ora di dati persa ha un costo diretto. Il prezzo per sito singolo è competitivo, ma su un portfolio di 50 siti il costo diventa significativo.
Automazione: Configurare Backup Schedulati e Verificati
Un backup non eseguito è un rischio. Un backup eseguito ma non verificato è un’illusione di sicurezza. Il processo di automazione professionale include tre componenti: scheduling intelligente, verifica automatica dell’integrità, notifiche sugli errori.
Frequenza ottimale per tipo di sito
| Tipo di sito | Database | File | Retention |
|---|---|---|---|
| Sito vetrina statico | Settimanale | Mensile | 3 mesi |
| Blog con aggiornamenti frequenti | Giornaliera | Settimanale | 6 mesi |
| WooCommerce con ordini | Giornaliera (o ogni 6h) | Settimanale | 12 mesi |
| Sito con form/lead | Giornaliera | Settimanale | 6 mesi |
| Sito in fase di sviluppo attivo | Giornaliera | Giornaliera | 30 giorni |
Verifica dell’integrità: il passaggio dimenticato
Il 30% dei backup fallisce silenziosamente — ovvero il processo termina senza errori apparenti ma il file risultante è corrotto o incompleto. Per verificare un backup database:
# Verifica integrità del file SQL compresso
gzip -t /backups/db-20260311.sql.gz && echo "File integro" || echo "File corrotto"
# Ripristino di test su database temporaneo
wp db create test_restore_db
wp db import /backups/db-20260311.sql --dbname=test_restore_db
wp db drop test_restore_db --yes
# Conta record nella tabella posts come sanity check
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish'" --dbname=test_restore_db
Notifiche intelligenti
Il sistema di notifiche deve distinguere tra tre stati: backup completato con successo, backup completato con warning (file mancanti, dimensione anomala), backup fallito. Solo i fallimenti richiedono azione immediata. I warning richiedono verifica manuale. I successi si loggano e si archiviano.
Recovery Time Objective (RTO) e Recovery Point Objective (RPO)
RTO e RPO sono le due metriche fondamentali di qualsiasi piano di disaster recovery. Molte agenzie non le conoscono e di conseguenza non hanno SLA definiti con i clienti — il che significa negoziare sotto pressione durante un incidente, nel peggior momento possibile.
Definizioni operative
Recovery Point Objective (RPO): quanta perdita di dati è accettabile? Un RPO di 24 ore significa che in caso di disastro perdiamo al massimo le ultime 24 ore di dati. Un RPO di 1 ora significa backup ogni ora.
Recovery Time Objective (RTO): quanto tempo massimo può stare offline il sito prima del ripristino completo? Un RTO di 4 ore significa che l’agenzia si impegna a ripristinare il sito entro 4 ore dalla segnalazione dell’incidente.
Come calcolare RTO e RPO per ogni cliente
Il calcolo non è puramente tecnico: dipende dal valore economico del sito per il cliente.
| Tipo di cliente | RPO consigliato | RTO consigliato | Backup adeguato |
|---|---|---|---|
| Sito vetrina B2B | 24-48h | 8-24h | Giornaliero, storage cloud |
| Blog/contenuti | 24h | 8h | Giornaliero, duplice storage |
| E-commerce medio | 4-6h | 2-4h | Ogni 6h, backup incrementale |
| E-commerce ad alto volume | 1h | 1h | Orario, replica in tempo reale |
| Piattaforma SaaS/membership | 30min-1h | 30min-1h | Real-time, backup ridondante |
Documentare gli SLA nel contratto
Una volta calcolati RTO e RPO per ogni cliente, il passo successivo è documentarli nel contratto di manutenzione. Questo ha tre benefici concreti:
- Definisce aspettative chiare e protegge l’agenzia da richieste irragionevoli (“il sito era offline da 10 minuti e non avevi ancora chiamato?”).
- Permette di tariffare correttamente: un RTO di 1 ora per un e-commerce richiede infrastruttura e processi significativamente più costosi di un RTO di 24 ore per un sito vetrina.
- Differenzia l’agenzia dalla concorrenza che non fa questo lavoro.
Procedura di Disaster Recovery Step-by-Step
Quando il disastro accade, il panico è il peggior nemico. Avere una procedura scritta, testata e disponibile offline è la differenza tra 30 minuti di downtime e 6 ore di confusione.
Fase 1 — Triage (0-5 minuti)
Prima di toccare qualsiasi cosa, valuta la situazione:
- Il sito è completamente offline (HTTP 500/502/503) o parzialmente funzionante?
- Il problema riguarda solo questo sito o altri siti sullo stesso server sono affetti?
- Quando è stato l’ultimo backup verificato?
- Ci sono state modifiche nelle ultime 24-48 ore (aggiornamenti, deploy, modifiche manuali)?
Fase 2 — Comunicazione con il cliente (0-10 minuti)
Notifica il cliente entro 10 minuti dall’identificazione del problema. Il messaggio deve essere breve, professionale e contenere un’ETA: “Abbiamo rilevato un problema sul tuo sito alle 14:32. Stiamo investigando. Ti aggiorniamo entro le 15:00 con una stima dei tempi di ripristino.”
Fase 3 — Identificazione della causa (5-20 minuti)
# Controlla i log di errore WordPress
wp eval 'echo WP_CONTENT_DIR;' && tail -100 wp-content/debug.log
# Verifica lo stato del database
wp db check --all-tables
# Controlla gli ultimi aggiornamenti applicati
wp plugin list --status=active --format=csv
wp core version --extra
# Verifica i permessi dei file critici
ls -la wp-config.php .htaccess wp-login.php
Fase 4 — Scelta della strategia di ripristino
Hai tre opzioni, in ordine di preferenza:
Opzione A — Rollback selettivo: se il problema è causato da un singolo plugin o aggiornamento recente, puoi disabilitare il componente problematico senza ripristinare l’intero sito.
# Disabilita tutti i plugin (bypassando il pannello admin se inaccessibile)
wp plugin deactivate --all
# Riattivali uno alla volta per identificare il colpevole
wp plugin activate nome-plugin
Opzione B — Ripristino del database: se il database è corrotto ma i file sono intatti.
# Ripristino database completo
wp db import /backups/db-$(date +%Y%m%d).sql
# Verifica post-ripristino
wp db check
wp eval 'echo "Connessione OK: " . get_bloginfo("url");'
Opzione C — Ripristino completo: quando sia file che database sono compromessi, o quando un attacco malware ha infettato i file.
# 1. Scarica WordPress core pulito
wp core download --skip-content --version=$(wp core version)
# 2. Ripristina wp-content dal backup
tar -xzf /backups/files-20260311.tar.gz -C /var/www/html/
# 3. Ripristina il database
wp db import /backups/db-20260311.sql
# 4. Verifica e aggiorna i permessi
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
# 5. Flush rewrite rules
wp rewrite flush
wp cache flush
Fase 5 — Verifica post-ripristino (15-30 minuti)
Prima di comunicare al cliente che il sito è ripristinato, esegui una checklist minima:
- Homepage caricata correttamente
- Login al pannello admin funzionante
- (Per WooCommerce) Checkout funzionante con ordine di test
- Immagini caricate e visibili
- Form di contatto funzionante
- SSL attivo e certificato valido
- Nessun errore nei log
Fase 6 — Post-mortem
Entro 48 ore dall’incidente, documenta cosa è successo, perché, come hai risposto e cosa farai per evitarlo in futuro. Il post-mortem non è una punizione: è lo strumento con cui si migliora il processo.
Gestire i Backup di 10, 20, 50 Siti: L’Approccio Scalabile
Con un solo sito, gestire il backup manualmente è fattibile. Con dieci siti comincia ad essere pesante. Con cinquanta siti, senza un’architettura scalabile, il backup diventa un lavoro a tempo pieno.
Il problema della frammentazione
L’approccio tipico di molte agenzie è installare UpdraftPlus su ogni sito e configurarlo separatamente. Il risultato è:
- 20-50 cartelle cloud diverse, ognuna con naming differente
- Nessuna visibilità centralizzata sullo stato dei backup
- Notifiche di errore che arrivano su email diverse
- Impossibilità di fare un backup di massa prima di un aggiornamento rischioso
- Nessun storico consolidato per rispondere a “quando è stato l’ultimo backup?”
L’architettura scalabile
Un sistema di backup scalabile per agenzie si basa su tre principi:
1. Storage centralizzato con struttura organizzata: tutti i backup confluiscono in un unico provider cloud (Amazon S3 o equivalente) con una struttura di cartelle prevedibile: /agenzia/cliente-nome/YYYY-MM/database/ e /agenzia/cliente-nome/YYYY-MM/files/. Questo permette ricerche rapide e audit automatizzati.
2. Orchestrazione da un unico punto: lo scheduling, il monitoraggio e le notifiche di errore vengono gestiti da un’unica piattaforma, non da 50 installazioni plugin indipendenti. Questo è il punto in cui strumenti come una dashboard centralizzata diventano essenziali.
3. Backup pre-aggiornamento automatici: ogni volta che viene schedulato un aggiornamento di massa su più siti, il sistema esegue automaticamente un backup incrementale di tutti i siti coinvolti, prima di procedere. Se un aggiornamento rompe un sito, il rollback è immediato.
Script per backup di massa via WP-CLI
Per agenzie con accesso SSH ai server, questo script esegue il backup di tutti i siti WordPress in una directory:
#!/bin/bash
# backup-all-sites.sh — backup di massa per siti multipli
BACKUP_BASE="/opt/backups"
DATE=$(date +%Y%m%d-%H%M%S)
for SITE_DIR in /var/www/*/; do
SITE_NAME=$(basename "$SITE_DIR")
# Verifica che sia un'installazione WordPress
if [ ! -f "$SITE_DIR/wp-config.php" ]; then
continue
fi
BACKUP_DIR="$BACKUP_BASE/$SITE_NAME/$DATE"
mkdir -p "$BACKUP_DIR"
# Backup database
wp --path="$SITE_DIR" db export "$BACKUP_DIR/database.sql" --quiet
# Backup file wp-content
tar -czf "$BACKUP_DIR/wp-content.tar.gz" -C "$SITE_DIR" wp-content --exclude=wp-content/cache 2>/dev/null
# Log del risultato
if [ $? -eq 0 ]; then
echo "[$DATE] SUCCESSO: $SITE_NAME" >> "$BACKUP_BASE/backup.log"
else
echo "[$DATE] ERRORE: $SITE_NAME" >> "$BACKUP_BASE/backup.log"
# Invia notifica (sostituire con webhook Slack/email)
# curl -X POST $SLACK_WEBHOOK -d "{"text":"Backup fallito: $SITE_NAME"}"
fi
done
Come AgencyPilot Centralizza Backup e Recovery
Gestire backup di 20 o 50 siti con script custom e plugin separati funziona, ma richiede competenze tecniche elevate, manutenzione costante e non offre la visibilità operativa necessaria per gestire un portfolio clienti in modo professionale.
AgencyPilot integra nativamente la gestione backup nell’infrastruttura di monitoraggio centralizzato. Dalla stessa dashboard dove monitori uptime, performance e sicurezza, puoi vedere lo stato di ogni backup per ogni sito.
Funzionalità backup di AgencyPilot
Le funzionalità di backup di AgencyPilot sono progettate specificamente per le esigenze delle agenzie:
Backup automatici schedulati: configura una volta la policy di backup per ogni sito — frequenza, tipo (database, file, completo), destinazione cloud — e il sistema si occupa del resto. Nessuna configurazione sito per sito nei pannelli admin.
Storico versioni con ricerca: ogni backup viene indicizzato con timestamp, dimensione, tipo e stato di verifica. Cercare il backup di un sito specifico in una data specifica richiede secondi, non minuti.
One-click restore: quando hai bisogno di ripristinare un sito, selezioni la versione dal catalogo e avvii il ripristino dalla dashboard. Il processo include verifica automatica dell’integrità prima del ripristino e notifica di completamento.
Backup pre-aggiornamento: prima di eseguire aggiornamenti di massa, AgencyPilot esegue automaticamente un backup snapshot di tutti i siti coinvolti. Se un aggiornamento introduce problemi, il rollback è immediato e documentato.
Alert su fallimenti: se un backup fallisce o se la dimensione del file è anomala rispetto alla media storica (potenziale indicatore di corruzione), ricevi una notifica immediata invece di scoprirlo durante un incidente.
Per un confronto dettagliato con altri strumenti di gestione come ManageWP e MainWP, incluse le funzionalità di backup, leggi il nostro confronto completo tra le piattaforme.
Il calcolo del valore per un’agenzia
Considera un’agenzia con 25 siti in gestione. Con l’approccio tradizionale (UpdraftPlus sito per sito), il tempo dedicato alla gestione backup — configurazione, verifica mensile, risposta agli errori, ripristini — è stimabile in circa 3-4 ore al mese. A un costo orario interno di 40 euro, sono 120-160 euro al mese di costo sommerso, ogni mese, solo per il backup.
Con un sistema centralizzato, quel tempo scende a 20-30 minuti di revisione dello storico, lasciando le ore rimanenti a lavoro fatturabile.
Conclusioni: La Checklist del Backup Professionale
Un sistema di backup WordPress professionale per agenzie non è un progetto da completare: è un processo da mantenere. Queste sono le aree da presidiare costantemente.
Checklist strategica
- [ ] Hai definito RTO e RPO per ogni sito cliente e li hai documentati nel contratto?
- [ ] Hai implementato la regola 3-2-1 (3 copie, 2 supporti, 1 offsite)?
- [ ] I backup includono database, wp-content, wp-config.php e .htaccess?
- [ ] La frequenza di backup è calibrata sul tipo e sul valore economico di ogni sito?
Checklist operativa
- [ ] Stai verificando l’integrità dei backup (non solo che il processo termini senza errori)?
- [ ] Hai un sistema di notifica centralizzato per i fallimenti?
- [ ] Esegui backup pre-aggiornamento prima degli aggiornamenti di massa?
- [ ] Hai testato almeno una volta il ripristino completo per ogni sito critico?
Checklist di scala
- [ ] La gestione backup è centralizzata o frammentata sito per sito?
- [ ] Puoi rispondere a “quando è stato l’ultimo backup di questo sito?” in meno di 30 secondi?
- [ ] Hai una procedura di disaster recovery scritta, testata e disponibile offline?
- [ ] Il tuo team sa esattamente cosa fare nelle prime 10 minuti di un incidente?
Un backup che non hai mai testato è un backup di cui non puoi fidarti. Pianifica oggi un test di ripristino su un sito non critico: è il modo più efficace per scoprire i punti deboli del tuo sistema prima che lo scopra un incidente reale.
FAQ: Backup WordPress per Agenzie
Con quale frequenza devo fare il backup di un sito WordPress?
Dipende dalla tipologia del sito. Un sito vetrina statico può essere sottoposto a backup settimanale. Un blog attivo richiede backup giornaliero. Un e-commerce con ordini frequenti necessita di backup ogni 4-6 ore, o più frequente per il solo database.
UpdraftPlus gratuito è sufficiente per un’agenzia?
Per uno o due siti, UpdraftPlus gratuito è funzionale. Per un portfolio di 10+ siti, la mancanza di gestione centralizzata diventa un limite operativo significativo: ogni configurazione è indipendente, ogni errore va trovato manualmente e non esiste una visione di insieme.
Qual è la differenza tra backup completo e backup incrementale?
Un backup completo copia tutti i file e il database ogni volta. Un backup incrementale copia solo i file modificati dall’ultimo backup completo. Il backup incrementale è più veloce, occupa meno spazio e permette granularità maggiore nel ripristino, ma richiede che l’intera catena di backup incrementali sia intatta per funzionare.
Quanto spazio cloud serve per i backup di un portfolio da 20 siti?
Dipende dal contenuto dei siti, ma una stima ragionevole per 20 siti WordPress medi (con media biblioteca di immagini) è 50-150 GB per mantenere 30 giorni di storico con backup giornalieri. Amazon S3 e Backblaze B2 hanno costi per GB molto contenuti.
Cosa succede se il provider di hosting va offline? Come accedo ai backup?
Questo è esattamente il motivo per cui la copia offsite nella regola 3-2-1 è obbligatoria. I backup su cloud esterno (Google Drive, S3, Backblaze) sono indipendenti dall’hosting e accessibili anche quando il server è completamente irraggiungibile.
Devo includere il core WordPress nel backup?
No. Il core di WordPress è scaricabile da wordpress.org in qualsiasi momento. Escluderlo riduce le dimensioni del backup e i tempi di trasferimento senza compromettere la completezza del ripristino.
FAQ
Qual è il modo migliore per fare il backup di WordPress?
Il backup completo di WordPress deve includere due componenti: i file del sito (cartella wp-content con temi, plugin e upload) e il database MySQL. Per agenzie che gestiscono più siti, la soluzione ottimale è un plugin come UpdraftPlus configurato per backup automatici giornalieri su storage remoto (Google Drive, S3, Dropbox), in modo da avere una copia fuori dal server di hosting. Il backup deve essere verificato periodicamente ripristinando in un ambiente di test.
Con quale frequenza fare il backup di un sito WordPress?
Dipende dalla frequenza con cui il sito cambia. Per un blog con nuovi articoli ogni settimana: backup giornaliero del database, settimanale dei file. Per un e-commerce con ordini giornalieri: backup del database ogni ora o ogni 4 ore. Per un sito vetrina che cambia raramente: backup settimanale completo è sufficiente. La regola generale è: il backup deve essere più frequente della perdita di dati che sei disposto ad accettare.
Cosa fare se WordPress non funziona dopo un aggiornamento?
Primo passo: disattiva tutti i plugin via FTP rinominando la cartella wp-content/plugins in plugins-disabled. Se il sito torna online, riattiva i plugin uno per uno per identificare il conflitto. Se il problema persiste, ripristina il tema di default. Se ancora non funziona, ripristina il backup precedente all’aggiornamento. Per evitare questa situazione, testare sempre gli aggiornamenti in un ambiente di staging prima di applicarli in produzione.
Come ripristinare un backup WordPress?
Il ripristino dipende da come è stato creato il backup. Con UpdraftPlus, vai in Impostazioni → UpdraftPlus → scheda Backup/Restore, seleziona il backup e clicca Ripristina. Per un ripristino manuale: carica i file via FTP nella cartella corretta, poi importa il database via phpMyAdmin o WP-CLI con il comando wp db import backup.sql. Dopo il ripristino, aggiorna i permalink andando in Impostazioni → Permalink e salvando.
