Backup centralizzato per 50+ siti WordPress: guida pratica

Perché serve una strategia centralizzata

Gestire backup per decine di siti WordPress senza un sistema centralizzato porta inevitabilmente a disastri. Ho visto agenzie perdere dati critici perché si affidavano a plugin configurati manualmente su ogni singolo sito, senza monitoraggio né verifica sistematica dei restore.

Quando superi i 20-30 siti, la gestione manuale diventa insostenibile per motivi precisi:

• Inconsistenza operativa: ogni sito ha configurazioni diverse, frequenze variabili, destinazioni storage disparate
• Monitoraggio frammentato: devi accedere a ogni singola installazione per verificare lo stato dei backup
• Costi moltiplicati: licenze plugin duplicate, storage non ottimizzato, sprechi enormi
• Testing impossibile: nessuno testa restore di 50 siti manualmente con regolarità
• Recovery time elevato: in caso di emergenza, recuperare dati da sistemi diversi richiede ore

Una strategia centralizzata risolve questi problemi con un’architettura che separa orchestrazione, esecuzione e storage in componenti gestibili da un unico punto di controllo.

Architettura del sistema di backup

L’architettura efficace per 50+ siti WordPress si basa su tre layer distinti:

Layer di orchestrazione

Il cervello del sistema, responsabile di scheduling, monitoraggio e alerting. Opzioni concrete:

• Self-hosted: UpdraftCentral, MainWP con estensione backup, o script custom con cron centralizzato
• SaaS: ManageWP, WP Remote, BlogVault Enterprise, o AgencyPilot stesso
• Infrastructure as Code: Ansible playbooks con wp-cli, orchestrati da AWX/Tower

Per agenzie oltre i 50 siti consiglio soluzioni SaaS o IaC. Il self-hosted richiede maintenance continua che sottrae tempo alla gestione client.

Layer di esecuzione

I worker che eseguono materialmente i backup sui siti target:

• Plugin-based: UpdraftPlus, BackWPup, Duplicator Pro con gestione centralizzata
• Server-level: script bash/Python che usano wp-cli e mysqldump direttamente
• Snapshot filesystem: LVM snapshots, ZFS snapshots, o snapshot provider cloud (AWS EBS, DigitalOcean Volumes)

La scelta dipende dall’infrastruttura. Se i siti sono su hosting condiviso diversi, sei vincolato a plugin. Con VPS/server dedicati, gli script server-level offrono performance superiori e meno overhead WordPress.

Layer di storage

Destinazione finale dei backup, con requisiti di ridondanza e retention:

• Object storage S3-compatible: AWS S3, Backblaze B2, Wasabi, MinIO self-hosted
• Cloud provider specifici: Google Cloud Storage, Azure Blob Storage
• Storage dedicato: server backup con Borg/Restic, NAS con replica off-site

Per 50 siti con media 2GB ciascuno, calcola almeno 500GB-1TB di storage considerando retention di 30 giorni e backup giornalieri incrementali. Con object storage tipo Backblaze B2 (6$/TB/mese) parliamo di 6-12$/mese solo storage, più egress per eventuali restore.

Definire policy di backup efficaci

Le policy determinano cosa, quando e come backuppare. Ecco uno schema testato su portafogli 50+ siti:

Classificazione siti per criticità

Dividi i siti in tier con SLA diversi:

• Tier 1 – Critici: e-commerce, membership, siti con transazioni. Backup ogni 6 ore, retention 60 giorni, RTO 1 ora
• Tier 2 – Importanti: siti corporate aggiornati frequentemente. Backup giornaliero, retention 30 giorni, RTO 4 ore
• Tier 3 – Standard: siti vetrina, blog poco aggiornati. Backup ogni 3 giorni, retention 14 giorni, RTO 24 ore

Questa classificazione ottimizza costi storage e computational load. Un e-commerce con 500 ordini/giorno richiede RTO aggressivo; un sito vetrina statico no.

Componenti da includere

Non tutto va backuppato con la stessa frequenza:

• Database: sempre incluso, ogni backup. Comprimere sempre (gzip/bzip2)
• wp-content/uploads: media files, backup completo settimanale + incrementale giornaliero
• wp-content/plugins + themes: backup quando rilevi modifiche (checksum-based)
• Core WordPress: skip, reinstallabile. Eccezione: installazioni con modifiche core custom
• File configurazione: wp-config.php, .htaccess, sempre inclusi

Strategia incrementale su uploads riduce drasticamente transfer. Un sito con 20GB di media trasferisce solo i file modificati dopo il primo full backup.

Retention e lifecycle

Policy retention bilanciata per 50+ siti:

• Ultimi 7 giorni: backup completi giornalieri
• 4 settimane precedenti: 1 backup/settimana
• 6 mesi precedenti: 1 backup/mese
• Oltre 6 mesi: archiviazione cold storage (S3 Glacier) o eliminazione

Con lifecycle policies automatiche su S3, sposti automaticamente backup vecchi verso storage tier più economici. Un backup di 2GB passa da 0.023$/mese (S3 Standard) a 0.004$/mese (Glacier Deep Archive).

Implementazione pratica: tre scenari

Scenario A: Hosting condiviso eterogeneo

50 siti distribuiti su hosting provider diversi, accesso solo FTP/SFTP e phpMyAdmin. Vincolo comune per agenzie cresciute organicamente.

Stack consigliato:

• UpdraftPlus Premium (70$/anno/sito con licenza agenzia) o BackWPup Pro
• UpdraftCentral per orchestrazione centralizzata
• Backblaze B2 come storage comune
• UptimeRobot per monitoring disponibilità siti

Configurazione:

// wp-config.php snippet per tutti i siti
define('UPDRAFTPLUS_B2_KEY', 'your-key');
define('UPDRAFTPLUS_B2_BUCKET', 'agency-backups');
define('UPDRAFTPLUS_B2_PREFIX', 'client-domain-com/');

Centralizza credenziali B2 via wp-config invece che GUI plugin: distribuisci config con script, eviti accessi manual e log centralizzato è più semplice.

Automazione: configura UpdraftCentral per pull report settimanali automatici. Crea dashboard Grafana che legge log UpdraftCentral via API per visualizzare backup success rate.

Scenario B: VPS/server dedicati con accesso root

50 siti su 5-10 VPS gestiti, accesso SSH completo. Scenario ideale per performance e controllo.

Stack consigliato:

• Script bash custom con wp-cli e mysqldump
• Restic per deduplica e encryption
• Wasabi o Backblaze B2 come backend
• Ansible per deployment configurazioni
• Healthchecks.io per monitoring esecuzioni cron

Script esempio backup singolo sito:

#!/bin/bash
SITE_PATH="/var/www/html/sitoclient.com"
DB_NAME="sitoclient_db"
BACKUP_TAG="sitoclient-com"

# Database dump
wp db export --path=$SITE_PATH - | gzip > /tmp/db.sql.gz

# Restic backup con tags
restic backup \
  --tag $BACKUP_TAG \
  --exclude 'wp-content/cache' \
  --exclude 'wp-content/plugins/*/cache' \
  $SITE_PATH /tmp/db.sql.gz

# Cleanup
rm /tmp/db.sql.gz

# Ping healthcheck
curl https://hc-ping.com/your-uuid-for-this-site

Restic deduplica automaticamente: 50 siti con plugin/themes simili condividono chunk storage. Risparmio reale 40-60% rispetto a backup tradizionali.

Orchestrazione Ansible: crea playbook che distribuisce script backup su tutti i VPS, configura cron jobs differenziati per tier, e mantiene aggiornate credenziali storage centralizzate.

Scenario C: Infrastruttura cloud moderna

50 siti su Kubernetes, AWS ECS, o DigitalOcean App Platform. Infrastruttura containerizzata.

Stack consigliato:

• CronJob Kubernetes che esegue wp-cli in pod ephemeral
• Velero per backup cluster-level (config, secrets, PV)
• Database gestiti (RDS, Cloud SQL) con snapshot automatici
• S3 versioning per wp-content/uploads sincronizzati

Approccio: separa completamente database e media da container WordPress. Backup database tramite snapshot provider nativi (RDS automated backups). Media su S3 con versioning: hai backup implicito senza tools aggiuntivi.

Container WordPress sono stateless e ricostruibili da Dockerfile. Backup necessari solo per config Kubernetes (gestito da Velero) e contenuti dinamici (db + uploads già coperti).

Monitoraggio e alerting

Sistema di backup senza monitoring è inutile. Scopri fallimenti quando serve restore: troppo tardi.

Metriche essenziali

• Backup success rate: percentuale backup completati con successo per site/settimana
• Backup size trend: crescita dimensione backup nel tempo, rileva anomalie
• Backup duration: tempo esecuzione, identifica siti con performance issues
• Storage usage: occupazione storage per cliente/tier
• Last successful backup age: tempo dall’ultimo backup OK per ogni sito

Alerting rules

Configura alert automatici su:

• Backup fallito per 2 esecuzioni consecutive su sito Tier 1
• Backup fallito per 7 giorni su qualsiasi sito
• Crescita improvvisa dimensione backup >50% (possibile malware/spam)
• Storage usage >80% quota allocata
• Backup duration >2 ore (media normale 15-30 minuti)

Integra con Slack, PagerDuty o Opsgenie per notifiche immediate al team operations.

Dashboard centralizzata

Crea dashboard unica con:

• Mappa stato backup ultimi 7 giorni (verde/giallo/rosso per ogni sito)
• Grafico trend storage usage mensile
• Lista siti con backup più vecchio di SLA (priorità intervento)
• Statistiche aggregate per cliente (se gestisci multi-tenant)

Tools utili: Grafana con Prometheus per metriche time-series, o dashboard custom che interroga API del tuo orchestratore backup.

Testing restore: il fattore critico ignorato

Backup non testato è backup inesistente. Il 34% delle agenzie scopre problemi backup solo durante emergenze reali (dati WP Engine Survey 2025).

Strategia testing mensile

Per 50 siti, testa restore completo di:

• Minimo 5 siti/mese selezionati random (copri tutti i siti in 10 mesi)
• Tutti i siti Tier 1 ogni trimestre
• Test full disaster recovery su ambiente staging ogni 6 mesi

Procedura testing standard:

1. Crea environment staging isolato (subdomain o VPS dedicato)
2. Esegui restore completo da backup più recente
3. Verifica integrità database (wp db check)
4. Testa funzionalità critiche (login admin, form contatti, checkout e-commerce)
5. Confronta checksum file critici con produzione
6. Documenta tempo restore effettivo vs RTO dichiarato
7. Distruggi environment staging

Automazione testing

Script automatizzato per testing restore:

#!/bin/bash
# Restore automation test
RANDOM_SITE=$(shuf -n1 sites-list.txt)
STAGING_URL="test.agency-staging.com"

echo "Testing restore for: $RANDOM_SITE"

# Restore da backup su staging
restic restore latest --target /var/www/staging \
  --tag $RANDOM_SITE

# Import database
wp db import backup.sql --path=/var/www/staging

# Update URLs
wp search-replace $RANDOM_SITE $STAGING_URL \
  --path=/var/www/staging

# Health check
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" $STAGING_URL)

if [ $HTTP_CODE -eq 200 ]; then
  echo "✓ Restore test passed for $RANDOM_SITE"
  # Log su sistema tracking
  curl -X POST https://your-tracking/api/restore-test \
    -d "{\"site\": \"$RANDOM_SITE\", \"status\": \"success\"}"
else
  echo "✗ Restore test failed for $RANDOM_SITE"
  # Alert team
  curl -X POST https://slack-webhook \
    -d "{\"text\": \"Restore test failed: $RANDOM_SITE\"}"
fi

Esegui script via cron mensile, accumula storico test nel tempo. Dopo 12 mesi hai dataset completo affidabilità restore per ogni sito.

Gestione disaster recovery

Quando serve restore reale, ogni minuto conta. Procedure chiare riducono RTO da ore a minuti.

Runbook disaster recovery

Documenta processo step-by-step per ogni scenario:

Scenario 1: Sito compromesso (hack, malware)

1. Metti sito offline (maintenance mode o server block)
2. Identifica ultimo backup pulito pre-compromissione
3. Restore file e database da backup pulito
4. Aggiorna tutti plugin/themes/core WordPress
5. Cambia tutte password (admin, FTP, database)
6. Scan malware (Wordfence CLI, maldet)
7. Riporta online e monitora 48h

Scenario 2: Perdita dati accidentale

1. Identifica scope perdita (file specifici, post, database completo)
2. Se perdita parziale, valuta restore selettivo vs completo
3. Restore su staging, estrai solo dati necessari
4. Importa dati estratti in produzione
5. Verifica consistenza dati ripristinati

Scenario 3: Failure infrastruttura completo

1. Provisiona nuova infrastruttura (VPS, hosting)
2. Installa stack LAMP/LEMP base
3. Restore file WordPress da backup
4. Restore database
5. Configura DNS per puntare a nuovo server
6. Verifica funzionalità complete
7. Update backup config per nuovo environment

Checklist pre-restore

Prima di ogni restore produzione:

• Backup stato attuale (anche se corrotto, per sicurezza)
• Comunica downtime a cliente con ETA restore
• Documenta causa necessità restore (tracking incidents)
• Prepara environment restore (spazio disco, permessi)
• Verifica integrità backup da ripristinare

Ottimizzazione costi e performance

Riduzione costi storage

Con 50 siti, costi storage impattano significativamente. Strategie comprovate:

• Deduplica: Restic/Borg riducono 40-60% storage per siti simili
• Compressione aggressiva: bzip2 invece gzip per backup archiviati (trade-off CPU vs storage)
• Lifecycle policies: sposta backup >30gg su storage class economici automaticamente
• Exclude cache e temp: wp-content/cache, uploads/cache, file .log non servono
• Backup differenziali intelligenti: su media files, solo modificati dopo ultimo full

Caso reale: agenzia con 60 siti, 150GB totali backup. Dopo ottimizzazione: 65GB storage effettivo. Risparmio: ~85$/anno su Backblaze B2.

Performance optimization

• Parallelizzazione: esegui backup multipli siti contemporaneamente (attenzione CPU/IO)
• Rate limiting: distribuisci backup nell’arco 24h per evitare picchi carico
• Compressione on-the-fly: comprimi durante trasferimento, riduci banda
• Resume capability: backup grandi devono supportare resume se interrotti
• Incremental forever: dopo primo full, solo incrementali (approccio Restic/Borg)

Bandwidth management

Con 50 siti x 2GB backup x 30 giorni = 3TB transfer/mese. Su connessioni limitate, problematico.

Soluzioni:

• Backup notturni (bandwidth meno contesa)
• Throttle transfer rate (rsync –bwlimit, Restic –limit-upload)
• Backup differenziali per ridurre volume trasferito
• Mirror backup locale + sync asincrono verso cloud

Compliance e considerazioni legali

Per agenzie che gestiscono siti e-commerce o con dati sensibili, backup hanno implicazioni legali.

GDPR e privacy

• Encryption obbligatoria: backup devono essere cifrati at-rest e in-transit
• Data retention limits: non conservare backup oltre necessità (30-90gg solitamente sufficienti)
• Right to be forgotten: processo per rimuovere dati utente da backup quando richiesto
• Geographic restrictions: alcuni clienti richiedono storage in EU (S3 eu-west, Hetzner Storage Box)

Encryption best practices

Tutti i backup devono essere cifrati. Approcci:

• Application-level: UpdraftPlus supporta encryption, Restic cifra nativamente
• Storage-level: S3 SSE, Backblaze B2 encryption
• Client-side prima upload: gpg encryption prima trasferimento (massima sicurezza)

Gestione chiavi critiche: usa vault dedicato (HashiCorp Vault, AWS Secrets Manager). Mai hardcodare chiavi in script o config files committati su git.

Checklist implementazione completa

Per implementare strategia backup centralizzata da zero:

1. Audit esistente: inventario tutti siti, backup attuali, hosting, accessi (settimana 1)
2. Classificazione tier: assegna criticità e SLA a ogni sito (settimana 1)
3. Scelta stack: decide orchestratore, worker, storage basato su infrastruttura (settimana 2)
4. Setup storage: provisiona bucket/storage, configura lifecycle policies (settimana 2)
5. Deployment worker: installa plugin o script su tutti i siti, automatizza con Ansible (settimane 3-4)
6. Configurazione orchestratore: setup scheduling, destination, retention per tier (settimana 4)
7. Monitoring setup: dashboard, alerting, healthchecks (settimana 5)
8. Testing iniziale: restore test su 10 siti sample (settimana 6)
9. Documentazione: runbook disaster recovery, procedure team (settimana 6)
10. Training team: forma operations su nuovi processi (settimana 7)
11. Cutover finale: disattiva vecchi backup, monitoring 2 settimane intensive (settimana 8)

Budget realistico per agenzia 50 siti:

• Software/licenze: 500-2000€/anno (dipende da stack)
• Storage: 150-400€/anno (dipende da dimensioni e retention)
• Implementation time: 40-80 ore devops/sysadmin
• Maintenance ongoing: 4-8 ore/mese monitoring e troubleshooting

FAQ

Quanto storage serve realmente per 50 siti WordPress con backup giornalieri?

Dipende fortemente da dimensione media siti e strategia retention. Calcolo realistico: sito medio 2-3GB (database 200-500MB, uploads 1.5-2.5GB). Con backup incrementali intelligenti e retention 30 giorni, stima 1.5-2TB storage totale. Usando deduplica (Restic/Borg), riduci a 800GB-1.2TB. Su Backblaze B2 (6$/TB/mese) parliamo di 5-12$/mese. Budget sicuro: 20$/mese storage per 50 siti con margine crescita.

Meglio backup plugin-based o script server-level per grandi volumi?

Se hai accesso SSH/root, script server-level sono superiori per 50+ siti: performance migliori (no overhead WordPress), più controllo, deduplica efficace, automazione semplificata, costi licenze azzerati. Plugin-based obbligatori solo su hosting condiviso senza SSH. Hybrid approach funziona: plugin per hosting condiviso, script per VPS/dedicati. MainWP o UpdraftCentral orchestrano entrambi da interfaccia unica.

Come gestire backup di database enormi (5GB+) senza timeout?

Database grandi richiedono approccio specifico: usa mysqldump con opzioni ottimizzate (–single-transaction, –quick, –max_allowed_packet=512M), dividi dump in chunk con –tab o split, comprimi on-the-fly con pipe (mysqldump | gzip), esegui backup via cron con NICE priority bassa per non impattare produzione, considera MySQL replication slave dedicato per backup (zero impatto su master). Per e-commerce 10GB+, valuta backup incrementali binlog-based invece di full dump giornalieri.

Quali sono i segnali che il mio sistema backup sta fallendo silenziosamente?

Red flags comuni: dimensione backup non cresce nonostante contenuti aggiunti (backup parziali), tempo esecuzione drasticamente ridotto improvvisamente (script terminano con errori non catturati), notifiche successo ma file backup datati su storage, backup completa ma restore test fallisce, log pieni di warning ignorati, credenziali storage scadute ma nessun alert, spazio disco 100% su backup destination. Soluzione: monitoring proattivo con healthchecks esterni, restore test automatizzati mensili, alert su anomalie dimensioni/durata backup.

Restore da backup richiede sempre downtime del sito live?

No necessariamente. Per restore completo disaster recovery sì. Ma per recovery selettivo dati: restore su staging environment isolato, estrai solo contenuti necessari (post specifici, file media), importa selettivamente in produzione via WP-CLI o manualmente, zero downtime percepito. Per emergenze con RTO aggressivo: mantieni standby environment pre-configurato, restore su standby, switch DNS/load balancer quando pronto, downtime ridotto a TTL DNS (5-15 minuti). E-commerce Tier 1 dovrebbero avere procedure restore <1h downtime documentate e testate.