Backup WordPress pre-aggiornamento: procedura agenzie

Juan Camilo Auriti

Perché il backup pre-aggiornamento è critico per le agenzie

Nel maggio 2026, secondo dati WP Engine, il 34% dei problemi critici sui siti WordPress client deriva da aggiornamenti mal gestiti. Per un’agenzia che gestisce decine o centinaia di siti, un aggiornamento fallito senza backup significa ore di lavoro non fatturabile, danni reputazionali e potenziali perdite di dati client.

La procedura di backup pre-aggiornamento non è opzionale: è un requisito contrattuale in qualsiasi SLA professionale. Un backup corretto deve essere:

Completo: database, file, configurazioni server
Verificato: testato per il ripristino effettivo
Accessibile rapidamente: tempo di recovery sotto i 15 minuti
Tracciato: log di quando e cosa è stato salvato
Isolato: non sullo stesso server del sito

La differenza tra un’agenzia junior e una senior si vede proprio qui: nella capacità di automatizzare queste procedure senza errori umani.

Anatomia di un backup WordPress completo

Un backup WordPress professionale non è solo un dump del database. Ecco i componenti essenziali che ogni agenzia deve salvare prima di un aggiornamento:

Database MySQL/MariaDB

Il cuore del sito. Include:

Tutte le tabelle wp_* (o prefisso custom)
Tabelle di plugin e temi premium
Dati utente, ordini e-commerce, form submissions
Configurazioni e options serializzate

Strumenti consigliati: mysqldump via CLI, WP-CLI con wp db export, oppure phpMyAdmin per emergenze. Il formato SQL compresso con gzip riduce lo storage del 70-85%.

File del sito

Componenti critici da salvare:

/wp-content/: plugins, themes, uploads (media library)
wp-config.php: credenziali database e security keys
.htaccess: regole di rewrite e security headers
robots.txt, sitemap.xml: configurazioni SEO
File core WordPress (opzionale ma consigliato per rollback rapido)

Note pratiche: la cartella /wp-content/uploads/ può pesare gigabyte. Per aggiornamenti minori (patch security), molte agenzie escludono gli uploads dai backup incrementali, mantenendo solo backup completi settimanali.

Configurazioni server

Spesso dimenticate ma cruciali per ripristini completi:

Versione PHP in uso (critical per compatibilità)
Estensioni PHP abilitate (gd, imagick, mbstring, etc.)
Configurazioni Nginx/Apache (virtual host, SSL)
Variabili d’ambiente e cron jobs
Certificati SSL (Let’s Encrypt o commerciali)

Salva queste info in un file server-config.txt dentro il backup stesso.

Strategia di backup pre-aggiornamento: il metodo 3-2-1

Per agenzie professionali, adotta la regola 3-2-1 anche per backup temporanei pre-aggiornamento:

3 copie: originale + 2 backup
2 media diversi: storage locale + cloud
1 copia off-site: geograficamente separata

Implementazione pratica per agenzie

Scenario tipo: agenzia con 50 siti client, aggiornamento major WordPress 6.9 → 7.0.

Fase 1 – Backup automatico schedulato:

Script bash/PHP che cicla tutti i siti (array da config centrale)
Per ogni sito: export DB, tar.gz della directory, salvataggio su NAS locale
Sync automatico su AWS S3 o Backblaze B2 (costo ~$5/TB/mese)
Log centralizzato con timestamp e dimensioni file

Fase 2 – Backup pre-aggiornamento immediato:

Backup on-demand 5 minuti prima dell’aggiornamento
Denominazione file: sitename_pre-update-7.0_20260521-1430.tar.gz
Retention: 7 giorni per backup pre-update, poi consolidamento

Fase 3 – Verifica integrità:

Checksum MD5/SHA256 del file backup
Test di decompressione (senza estrazione completa)
Verifica dimensione file vs. media storica (alert se -30%)

Tool consigliato per agenzie: script WP-CLI personalizzato che integra questi step. Tempo esecuzione medio per sito da 2GB: 45-90 secondi.

Automazione con WP-CLI: script production-ready

Per agenzie che gestiscono volumi, WP-CLI è lo standard. Ecco uno script base migliorato per backup pre-aggiornamento:

#!/bin/bash
# backup-pre-update.sh

SITE_PATH="/var/www/clientsite"
BACKUP_DIR="/backups/pre-update"
DATE=$(date +%Y%m%d-%H%M)
SITE_NAME="clientsite"

# Export database
cd $SITE_PATH
wp db export $BACKUP_DIR/${SITE_NAME}_db_${DATE}.sql --add-drop-table
gzip $BACKUP_DIR/${SITE_NAME}_db_${DATE}.sql

# Archive files (escludi cache e temp)
tar -czf $BACKUP_DIR/${SITE_NAME}_files_${DATE}.tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/updraft' \
  -C $(dirname $SITE_PATH) $(basename $SITE_PATH)

# Checksum
md5sum $BACKUP_DIR/${SITE_NAME}_*.gz > $BACKUP_DIR/${SITE_NAME}_${DATE}.md5

# Sync to S3
aws s3 sync $BACKUP_DIR s3://agency-backups/pre-update/ \
  --storage-class STANDARD_IA

# Log
echo "[$(date)] Backup completato: ${SITE_NAME}" >> /var/log/backup-pre-update.log

Questo script è eseguibile via cron o manualmente. Per 50 siti, wrappa in un loop e aggiungi notifiche Slack/email per fallimenti.

Integrazione con staging environment

Best practice 2026: testa sempre gli aggiornamenti su staging prima di toccare production. La sequenza corretta è:

Backup production completo
Clone production → staging (o refresh staging se già esistente)
Backup staging pre-aggiornamento
Aggiornamento su staging + test funzionali
Se OK: backup production immediato + aggiornamento
Se KO: analisi issue, fix, ripeti da punto 3

Tempo totale processo completo: 15-30 minuti per sito medio. Risparmio in troubleshooting: ore o giorni.

Strumenti professionali per agenzie: confronto 2026

Oltre agli script custom, esistono soluzioni dedicate per agenzie. Ecco un confronto basato su utilizzo reale:

UpdraftPlus Premium

Pro: interfaccia GUI, supporto multi-destinazione, scheduling granulare
Contro: overhead plugin su ogni sito, costo per-site ($70/anno × N siti)
Ideale per: agenzie piccole (5-20 siti) con team misto tecnico/non-tecnico

BlogVault/MalCare

Pro: backup incrementali real-time, dashboard centralizzata, staging incluso
Contro: costo elevato per volumi ($249/anno per 10 siti), vendor lock-in
Ideale per: agenzie focalizzate su e-commerce con cambiamenti frequenti

Script WP-CLI + S3/Backblaze

Pro: controllo totale, costo storage lineare (~$5/TB), no plugin overhead
Contro: richiede competenze DevOps, setup iniziale complesso
Ideale per: agenzie tecniche (30+ siti) con infrastruttura propria

ManageWP / MainWP

Pro: gestione centralizzata multi-sito, backup inclusi nella dashboard
Contro: backup basic (non sostituisce soluzione dedicata), limiti su retention
Ideale per: complemento a strategia backup esistente, non soluzione primaria

Tendenza 2026: agenzie mature usano combinazione WP-CLI per backup critici + dashboard type ManageWP per monitoring quotidiano.

Checklist pre-aggiornamento per team agency

Stampa e distribuisci al team tecnico. Ogni punto è bloccante per procedere:

Verifica SLA cliente: finestra di manutenzione approvata?
Backup completo production: DB + files + config server
Checksum e verifica integrità: file non corrotti
Test ripristino su staging: almeno 1 volta al mese (non per ogni update, ma come drill)
Documenta versioni attuali: WordPress, PHP, plugins, theme
Verifica compatibilità: changelog update vs. plugins attivi
Disattiva cache: plugin cache, CDN, object cache
Abilita debug mode: WP_DEBUG su staging
Notifica cliente: email automatica “manutenzione in corso”
Backup post-aggiornamento: conferma che tutto funziona prima di chiudere

Tempo esecuzione checklist completa: 8-12 minuti per sito. Automatizza punti 2, 3, 5, 7, 9 per ridurre a 3-4 minuti.

Recovery rapido: cosa fare quando l’aggiornamento fallisce

Scenario reale: aggiornamento WordPress causa white screen of death. Il backup ti salva, ma devi essere veloce.

Procedura rollback standard

Attiva modalità manutenzione: crea file .maintenance in root
Ripristina database: wp db import backup.sql (2-5 minuti per DB medi 50-200MB)
Ripristina file: estrai tar.gz sovrascrivendo directory corrente
Verifica wp-config.php: credenziali DB corrette
Flush cache e permalink: wp cache flush && wp rewrite flush
Test funzionalità critiche: login, checkout, form contatto
Rimuovi manutenzione: elimina .maintenance

Tempo recovery totale con backup preparato correttamente: 5-15 minuti. Senza backup: ore o giorni, con potenziale perdita dati.

Errori comuni da evitare

Backup sullo stesso disco del sito: se il disco muore, perdi tutto
Non testare mai i ripristini: scopri che il backup è corrotto solo quando serve
Escludere wp-config.php: poi devi ricreare manualmente security keys
Ignorare plugin premium con licenze: dopo ripristino potrebbero richiedere riattivazione
Backup senza compressione: sprechi 70% storage e bandwidth

Retention policy e gestione storage per agenzie

Con decine di siti e backup giornalieri, lo storage esplode. Policy bilanciata per agenzie:

Backup giornalieri: retention 7 giorni
Backup settimanali: retention 4 settimane
Backup mensili: retention 12 mesi
Backup pre-aggiornamento: retention 30 giorni
Backup pre-major-update: retention 90 giorni

Costo stimato storage cloud (Backblaze B2) per agenzia 50 siti, media 2GB/sito: ~$15-25/mese. ROI infinito quando eviti il primo disastro.

Automazione pulizia backup obsoleti

Script cron per eliminare backup vecchi secondo retention policy:

#!/bin/bash
# cleanup-old-backups.sh

BACKUP_DIR="/backups"

# Elimina backup giornalieri > 7 giorni
find $BACKUP_DIR/daily -name "*.tar.gz" -mtime +7 -delete

# Elimina backup pre-update > 30 giorni
find $BACKUP_DIR/pre-update -name "*.tar.gz" -mtime +30 -delete

# Log pulizia
echo "[$(date)] Cleanup completato" >> /var/log/backup-cleanup.log

Esegui questo script settimanalmente via cron: 0 3 * * 0 /scripts/cleanup-old-backups.sh

Integrazione backup nella pipeline CI/CD agency

Per agenzie avanzate con deployment automatizzato, il backup è parte del workflow Git:

Developer pusha su branch staging: trigger automatic staging deploy
Pre-deploy hook: backup automatico staging environment
Deploy su staging: codice applicato, composer update, cache cleared
Test automatici: smoke tests, accessibility, performance
Se pass: merge request su production con checklist backup manuale
Deploy production: backup automatico immediato, poi deploy, poi backup post-deploy

Tool utili: GitLab CI/CD, GitHub Actions, Buddy, DeployHQ. Integrazione backup via webhook o SSH commands.

Monitoraggio e alerting per backup falliti

Un backup che fallisce silenziosamente è peggio di nessun backup: crei falsa sicurezza. Sistema di monitoring essenziale:

Log centralizzati: tutti i backup loggano su sistema unico (Papertrail, Logtail, ELK stack)
Healthcheck endpoint: script invia ping a servizio esterno (Healthchecks.io, Better Uptime)
Alert immediati: Slack/email se backup non completa entro X minuti
Report settimanale: digest con tutti i backup eseguiti, dimensioni, durata
Dashboard visuale: Grafana o simili con metriche backup success rate

Metriche chiave da tracciare: success rate (target: >99.5%), tempo medio esecuzione, dimensione media file, storage utilizzato vs. quota.

FAQ

Quanto tempo prima dell’aggiornamento devo fare il backup?

Il backup va eseguito immediatamente prima dell’aggiornamento, idealmente entro 5-10 minuti. Per aggiornamenti pianificati, esegui un backup completo notturno e poi un backup on-demand appena prima di procedere. Questo garantisce che il backup includa eventuali modifiche last-minute (nuovo articolo, ordine e-commerce, etc.). Mai usare backup più vecchi di 24 ore per rollback post-aggiornamento.

Posso fare backup solo del database per aggiornamenti minori di WordPress?

Per patch security (es. WordPress 6.5.2 → 6.5.3) tecnicamente il solo database potrebbe bastare, ma è sconsigliato. Gli aggiornamenti WordPress core sovrascrivono file di sistema che potrebbero avere modifiche custom non documentate. Best practice agency: backup completo sempre, eventualmente escludi solo /wp-content/uploads/ per velocizzare se la media library pesa diversi GB e non cambia frequentemente. Tempo risparmiato: 30-60 secondi. Rischio: potenziale perdita configurazioni critiche.

Quale formato è meglio per backup: ZIP, TAR.GZ o SQL puro?

Per agenzie: TAR.GZ per file, SQL.GZ per database. Motivo: compressione gzip è standard Linux, compatibile con tutti gli strumenti CLI, comprime 70-85% meglio di ZIP, e mantiene permessi file Unix. ZIP è utile solo se client non tecnici devono scaricare ed estrarre su Windows. SQL puro non compresso spreca storage e bandwidth inutilmente. Formato ideale: sitename_db_20260521.sql.gz + sitename_files_20260521.tar.gz. Tempo decompressione: identico o migliore di ZIP.

Come testo che un backup sia effettivamente ripristinabile?

Drill mensile obbligatorio: scegli random 2-3 siti dalla lista client, ripristina backup su ambiente staging isolato, verifica login admin e funzionalità base. Tempo richiesto: 15-20 minuti per sito. Automatizza parzialmente: script che estrae tar.gz, importa DB, verifica HTTP 200 su homepage. Test completo richiede intervento umano per checkout e-commerce, form submission, etc. Documenta risultati in spreadsheet condiviso. Backup non testato = backup potenzialmente inutile.

Quanto storage serve per gestire backup di 50 siti client?

Calcolo reale basato su agency media 2026: sito WordPress medio 2GB (500MB database + 1.5GB file inclusi uploads). Con retention policy standard (7 daily + 4 weekly + 12 monthly), storage per sito: circa 15-20GB. Per 50 siti: 750GB – 1TB. Costo Backblaze B2: ~$5-7/mese. Costo AWS S3 Standard-IA: ~$12-18/mese. Risparmio con compressione gzip: -70%, quindi storage effettivo 225-300GB, costo $1.5-5/mese. ROI vs. costo recovery disaster: infinito.