Backup solo database WordPress: quando e perché farlo

Juan Camilo Auriti

Perché il database è il cuore di WordPress

Quando parliamo di backup WordPress, la maggior parte delle agenzie pensa immediatamente a soluzioni complete che includono file, plugin, temi e database. Ma c’è uno scenario spesso sottovalutato: il backup del solo database.

Il database MySQL o MariaDB di WordPress contiene tutti i dati critici del sito:

Contenuti di post, pagine e custom post type
Commenti e metadati
Utenti, ruoli e permessi
Configurazioni di plugin e temi (salvate in wp_options)
Menu, widget e customizer settings
Dati WooCommerce (ordini, clienti, prodotti)

I file di WordPress — core, plugin e temi — sono invece statici e riproducibili. Se usi Git per il codice e gestori di dipendenze, ripristinare i file è questione di minuti. Il database, invece, contiene dati unici e irrecuperabili.

Quando il backup del solo database è sufficiente

Esistono scenari specifici dove fare backup esclusivamente del database non solo è sufficiente, ma è anche la strategia più efficiente.

Sviluppo e staging controllati

Se gestisci l’infrastruttura con strumenti come Composer, WP-CLI e deployment automatizzati, i file sono già versionati. In questo caso:

Il codice è su repository Git (privato o su GitHub/GitLab)
I plugin e temi sono installabili via Composer o script automatici
Le configurazioni di ambiente sono gestite tramite file .env
Gli upload vengono gestiti separatamente (CDN, S3, backup incrementali)

In questi contesti, l’unico elemento volatile è il database. Un backup ogni 4-6 ore del DB può essere più che sufficiente.

Siti ad alto contenuto editoriale

Blog, magazine, siti news con aggiornamenti frequenti generano continuamente nuovi contenuti nel database. Per questi siti:

I file cambiano raramente (aggiornamenti plugin/temi settimanali o mensili)
Il database cambia ogni ora (nuovi articoli, commenti, revisioni)
Backup frequenti del DB (ogni 1-2 ore) garantiscono protezione dei contenuti
Backup completi settimanali sono sufficienti per i file

Questa strategia ibrida riduce drasticamente lo spazio di storage e il carico server.

E-commerce con volumi medi

Per WooCommerce con 50-500 ordini al giorno, il database è l’asset critico. Considera che:

Ogni ordine vale potenzialmente centinaia di euro
Perdere anche solo un’ora di ordini può essere costoso
I file di prodotto (immagini) sono spesso su CDN o backup separati
Backup del DB ogni 30-60 minuti proteggono le transazioni

Molte agenzie implementano backup del database ogni 30 minuti per WooCommerce, mantenendo backup completi solo una volta al giorno.

Vantaggi operativi per le agenzie

Adottare una strategia di backup mirata al database offre benefici concreti nella gestione quotidiana.

Velocità e automazione

Un database WordPress medio pesa tra 50-500 MB. Un backup completo con file può raggiungere 2-10 GB. La differenza in termini di performance è notevole:

Backup DB: 5-30 secondi
Backup completo: 2-15 minuti
Trasferimento DB via rete: quasi istantaneo
Ripristino DB: 10-60 secondi

Con strumenti come WP-CLI, puoi eseguire wp db export backup-$(date +%Y%m%d-%H%M%S).sql --add-drop-table e ottenere un dump completo in secondi, perfetto per cronjob frequenti.

Riduzione dei costi di storage

Conservare 30 giorni di backup con retention oraria per i primi 7 giorni genera numeri importanti:

Backup completi orari: ~168 backup × 5 GB = 840 GB
Backup DB orari: ~168 backup × 200 MB = 33.6 GB

Per 50 clienti, la differenza è di circa 40 TB vs 1.6 TB. Anche con storage economico a 0.02€/GB/mese, parliamo di 800€/mese vs 32€/mese solo per lo storage dei backup recenti.

Recovery Point Objective (RPO) ottimizzato

Il RPO indica quanto dato puoi permetterti di perdere. Con backup DB frequenti:

Backup ogni 30 minuti = RPO di 30 minuti massimo
Costo computazionale minimo sul server
Possibilità di mantenere più snapshot senza impattare le performance
Ripristini rapidi per errori specifici (contenuti cancellati, plugin mal configurati)

Come implementare backup database-only efficaci

La teoria è chiara, ma l’implementazione richiede attenzione ai dettagli tecnici.

Via WP-CLI (consigliato)

WP-CLI è lo strumento più affidabile per backup del database WordPress. Esempio di script bash:

#!/bin/bash
BACKUP_DIR="/var/backups/wordpress/db"
SITE_PATH="/var/www/html"
DATE=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=7

# Crea backup
cd $SITE_PATH
wp db export $BACKUP_DIR/db-backup-$DATE.sql --add-drop-table

# Comprimi
gzip $BACKUP_DIR/db-backup-$DATE.sql

# Pulisci vecchi backup
find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Carica su S3 (opzionale)
aws s3 cp $BACKUP_DIR/db-backup-$DATE.sql.gz s3://bucket-backups/wordpress/

Aggiungi questo script a cron per esecuzione automatica: 0 */2 * * * /path/to/backup-db.sh per backup ogni 2 ore.

Via mysqldump nativo

Se WP-CLI non è disponibile, mysqldump è l’alternativa diretta:

#!/bin/bash
DB_NAME="wordpress_db"
DB_USER="wp_user"
DB_PASS="password"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y%m%d-%H%M%S)

mysqldump -u$DB_USER -p$DB_PASS $DB_NAME \
  --single-transaction \
  --quick \
  --lock-tables=false \
  | gzip > $BACKUP_DIR/$DB_NAME-$DATE.sql.gz

L’opzione --single-transaction è fondamentale per database InnoDB: garantisce consistenza senza bloccare le tabelle durante il backup.

Plugin WordPress (per casi specifici)

Per clienti che richiedono interfacce grafiche, alcuni plugin permettono backup solo del database:

UpdraftPlus: opzione “Backup solo database” nelle impostazioni manuali
WP-DB-Backup: specifico per database, leggero ma non più mantenuto attivamente
BackWPup: configurazione granulare per job separati DB/file

Attenzione: i plugin aggiungono overhead e dipendenze. Per gestione multi-cliente professionale, soluzioni esterne (WP-CLI, mysqldump, servizi dedicati) sono preferibili.

Soluzioni SaaS specializzate

Servizi come BlogVault, ManageWP o GridPane offrono backup incrementali del database con retention configurabile. Vantaggi:

Backup automatici ogni ora o anche più frequenti
Storage esterno sicuro
Ripristino point-in-time via dashboard
Notifiche in caso di problemi

Per agenzie con 30+ clienti, questi servizi possono costare 200-500€/mese ma eliminano completamente la gestione manuale.

Cosa non puoi recuperare con solo il database

È fondamentale capire i limiti di questa strategia. Un backup del solo database non include:

File caricati: tutte le immagini, PDF, video in wp-content/uploads
Plugin e temi custom: codice sviluppato specificamente non versionato
File di configurazione: wp-config.php, .htaccess, php.ini custom
Traduzioni custom: file .po/.mo non standard

Per questi elementi, la strategia dipende dal contesto:

Uploads: backup separato incrementale (rsync, rclone) o CDN con versioning (Cloudflare R2, AWS S3)
Codice custom: repository Git privato
Config: template versionati o secrets manager

L’approccio professionale è backup ibrido: database frequente (ogni 1-6 ore) + file completo meno frequente (giornaliero o settimanale).

Strategie di retention per database WordPress

Conservare ogni backup per sempre è impraticabile. Una policy di retention equilibrata per database:

Ultime 24 ore: backup ogni ora (24 copie)
Ultima settimana: backup ogni 6 ore (28 copie totali)
Ultimo mese: backup giornaliero (30 copie)
Ultimo anno: backup settimanale (52 copie)
Oltre l’anno: backup mensile (tempo indefinito o 3-5 anni)

Questa strategia offre granularità dove serve (ore recenti) e comprime progressivamente i backup più vecchi. Per un database da 200 MB:

24 backup orari: 4.8 GB
4 backup aggiuntivi (6h): 800 MB
30 backup giornalieri: 6 GB
Totale approssimativo: ~12 GB per sito

Monitoraggio e alerting

Un backup non verificato è uno scenario di disaster recovery non testato. Implementa:

Health check post-backup: verifica che il file .sql.gz non sia corrotto (gzip -t file.sql.gz)
Dimensione minima: alert se il backup è più piccolo del 70% rispetto alla media degli ultimi 7 giorni
Test di ripristino mensile: automatizza il ripristino su ambiente di test per validare l’intero processo
Notifiche su fallimento: webhook, email o integrazione Slack quando cron fallisce

Script di esempio per verifica dimensione:

#!/bin/bash
CURRENT_SIZE=$(stat -f%z "$BACKUP_FILE" 2>/dev/null || stat -c%s "$BACKUP_FILE")
AVG_SIZE=$(find $BACKUP_DIR -name "*.sql.gz" -mtime -7 -exec stat -f%z {} \; | awk '{sum+=$1; count++} END {print sum/count}')
THRESHOLD=$(echo "$AVG_SIZE * 0.7" | bc)

if [ $CURRENT_SIZE -lt $THRESHOLD ]; then
    echo "WARNING: Backup troppo piccolo ($CURRENT_SIZE vs $AVG_SIZE media)"
    # Invia notifica
fi

Integrazione con workflow di sviluppo

Per agenzie che usano Git e deployment automatizzati, i backup del database si integrano perfettamente:

Pull database da produzione a staging: wp db export su prod, download via SSH, wp db import su staging
Sanitizzazione dati sensibili: usa plugin come WP Migrate DB Pro per anonimizzare email/password quando porti dati prod in sviluppo
Snapshots pre-deployment: crea backup DB automatico prima di ogni deploy per rollback immediato
Branch database separati: mantieni dump SQL in repository per setup rapido ambienti dev

Molte agenzie implementano script tipo: npm run db:pull:prod che automatizza download, import e search-replace URL in un comando.

FAQ

Quanto spesso devo fare backup del database WordPress?

Dipende dalla frequenza degli aggiornamenti. Per siti editoriali attivi: ogni 1-2 ore. Per siti corporate con pochi aggiornamenti: ogni 6-12 ore è sufficiente. E-commerce con WooCommerce: ogni 30-60 minuti per proteggere gli ordini. In generale, considera quanto dato puoi permetterti di perdere e configura la frequenza di conseguenza.

Il backup del database include anche gli upload di immagini?

No. Il database WordPress contiene solo i riferimenti (URL) alle immagini, non i file fisici. Le immagini sono salvate in wp-content/uploads e richiedono un backup separato dei file. Per proteggere completamente un sito servono sia backup del database che dei file uploads, ma con frequenze diverse.

Posso fare backup del database mentre il sito è online?

Sì, usando gli strumenti corretti. WP-CLI e mysqldump con l’opzione --single-transaction permettono backup consistenti senza bloccare le tabelle o mettere offline il sito. Evita invece --lock-tables che può causare downtime durante il backup. Per database molto grandi (>5GB) considera finestre di manutenzione o replica.

Come posso verificare che un backup database sia funzionante?

Il metodo più affidabile è il ripristino di test mensile: importa il backup in un ambiente staging e verifica che il sito funzioni. In alternativa, verifica l’integrità del file compresso (gzip -t file.sql.gz), controlla che la dimensione sia coerente con i backup precedenti e valida che contenga le tabelle principali aprendo il file SQL.

Quando è obbligatorio fare backup completo invece che solo database?

Il backup completo è necessario prima di aggiornamenti maggiori (WordPress, PHP, migrazioni server), per siti con molto codice custom non versionato, per e-commerce con plugin complessi che salvano dati anche nei file, e come baseline settimanale/mensile anche se fai backup frequenti del solo database. Il backup completo è la rete di sicurezza definitiva.