Cos’è un runbook di disaster recovery e perché serve alle agenzie
Un runbook di disaster recovery è un documento operativo che contiene procedure dettagliate, step-by-step, per rispondere a emergenze critiche sui siti WordPress. Non è un semplice piano teorico: è una checklist eseguibile che il tuo team può seguire anche sotto stress, alle 3 di notte, quando un cliente ti chiama perché il suo e-commerce è down.
Le agenzie web gestiscono mediamente 15-50 siti cliente contemporaneamente. Secondo dati Uptime.com 2026, il 78% delle agenzie affronta almeno un’emergenza critica ogni trimestre: attacchi ransomware, corruzioni database, errori di deployment, problemi hosting. Senza un runbook testato, il tempo medio di ripristino (MTTR) sale da 2-3 ore a oltre 8 ore, con costi diretti e reputazionali significativi.
Un runbook efficace trasforma la gestione delle emergenze da panico reattivo a processo controllato. Riduce la dipendenza da singoli tecnici esperti, permette onboarding rapido di nuove risorse e documenta le decisioni prese durante le crisi per analisi post-mortem.
Struttura base del runbook: sezioni essenziali
Un runbook disaster recovery WordPress deve contenere sezioni specifiche, organizzate per tipo di emergenza e livello di gravità. La struttura che proponiamo è testata su oltre 200 interventi reali documentati da agenzie italiane nel 2025-2026.
Classificazione emergenze e priorità
Prima di ogni procedura, definisci la scala di severità che determina tempi di risposta e risorse allocate:
- P0 – Critico: sito completamente inaccessibile, perdita dati in corso, violazione sicurezza attiva. SLA risposta: 15 minuti, risoluzione: 2 ore
- P1 – Alto: funzionalità critica non disponibile (checkout, login, form contatti). SLA risposta: 30 minuti, risoluzione: 4 ore
- P2 – Medio: performance degradate, errori intermittenti, funzionalità secondarie offline. SLA risposta: 2 ore, risoluzione: 8 ore
- P3 – Basso: problemi estetici, feature non critiche. SLA risposta: 1 giorno lavorativo
Ogni emergenza P0 e P1 richiede notifica immediata al cliente, apertura ticket su sistema di gestione agenzia e log dettagliato di tutte le azioni intraprese.
Informazioni di accesso centralizzate
Il runbook deve linkare o contenere (in sezione protetta) gli accessi essenziali per ogni sito cliente:
- Credenziali WordPress admin (utente emergency con ruolo amministratore dedicato)
- Accesso SSH/SFTP con chiavi e IP whitelisting
- Pannello hosting (cPanel, Plesk, custom)
- DNS provider e credenziali Cloudflare/altro CDN
- Repository Git e branch protection rules
- Documentazione backup: location, retention policy, ultimo test ripristino
- Contatti cliente: primario, secondario, orari reperibilità
Per sicurezza, non inserire password in chiaro nel runbook: usa riferimenti a password manager aziendale (1Password, Bitwarden Teams) con vault dedicati per cliente.
Checklist di triage iniziale
Prima di iniziare qualsiasi procedura di recovery, esegui sempre il triage per identificare correttamente il problema:
- Verifica accessibilità esterna: testa da multiple location (uptime monitor, mobile, incognito)
- Controlla status hosting: pannello provider, statuspage.io del datacenter
- Analizza log server: error_log, access_log (ultimi 500 righe)
- Verifica integrità database: connessione MySQL, tabelle corrotte
- Controlla spazio disco: df -h, verifica quota hosting
- Identifica modifiche recenti: deploy, aggiornamenti plugin/tema, modifiche DNS
Questa fase richiede 5-10 minuti ma previene il 40% degli interventi di recovery inutili: molte emergenze percepite sono problemi di cache, DNS non propagato o manutenzione programmata hosting.
Procedura 1: Ripristino da backup completo
Scenario più comune: sito compromesso, corruzioni multiple, necessità di rollback completo. Questa procedura assume esistenza backup verificato entro 24-48 ore.
Pre-requisiti e preparazione
Prima di iniziare il ripristino:
- Identifica backup più recente funzionante (non necessariamente l’ultimo se compromesso)
- Verifica integrità backup: checksum file, dump SQL apribile
- Stima downtime: comunica al cliente finestra realistica (1-3 ore tipicamente)
- Metti sito in modalità manutenzione se parzialmente accessibile
- Crea snapshot stato corrente (anche se compromesso) per analisi post-mortem
Step di ripristino
- Backup dello stato corrente: anche se danneggiato, salva per forensics
cd /path/to/wordpress tar -czf emergency-backup-$(date +%Y%m%d-%H%M).tar.gz wp-content/ mysqldump -u user -p database > emergency-db-$(date +%Y%m%d-%H%M).sql - Pulizia directory WordPress: rimuovi file esistenti (escludi wp-config.php se non compromesso)
rm -rf wp-admin wp-includes wp-content/plugins/* wp-content/themes/* # Mantieni wp-content/uploads se non compromessi e grandi - Estrazione backup file:
tar -xzf backup-wordpress-YYYYMMDD.tar.gz -C /path/to/wordpress/ - Ripristino database:
mysql -u user -p database < backup-database-YYYYMMDD.sql - Verifica permessi:
find /path/to/wordpress -type d -exec chmod 755 {} \; find /path/to/wordpress -type f -exec chmod 644 {} \; chmod 600 wp-config.php - Test funzionalità: verifica login admin, homepage, pagine chiave, form, checkout se e-commerce
- Flush cache: Cloudflare, Redis/Memcached, plugin caching WordPress
- Verifica post-ripristino: controlla log errori, test transazioni se applicabile
Tempo stimato: 45-90 minuti a seconda dimensione sito. Per siti oltre 10GB, considera ripristino incrementale: prima database e core, poi uploads in background.
Troubleshooting comuni
- Errore connessione database dopo ripristino: verifica credenziali wp-config.php, host database (localhost vs IP), privilegi utente MySQL
- Mixed content warnings: URLs hardcoded con http nel database ripristinato. Fix:
wp search-replace 'http://domain.com' 'https://domain.com' --all-tables - Plugin incompatibili dopo ripristino: disattiva tutti, riattiva uno alla volta identificando colpevole
- Dimensione import SQL supera limiti: usa WP-CLI o split file:
split -l 5000 backup.sql backup-part-
Procedura 2: Recovery da attacco malware
Scenario: sito compromesso con malware, backdoor, redirect malevoli. Richiede approccio diverso dal semplice ripristino backup per evitare reinfezione.
Step di contenimento
- Isola sito immediatamente: cambia tutte le password (WordPress, FTP, database, hosting), revoca sessioni attive
wp user list --field=ID | xargs -I % wp user session destroy % - Metti sito offline: htaccess deny, maintenance mode o IP whitelisting solo team tecnico
- Identifica punto di ingresso: controlla log accessi anomali, file modificati recentemente
find /path/to/wordpress -type f -mtime -7 -ls - Scansione malware: usa Wordfence CLI, Sucuri scanner o manuale
grep -r "eval(base64_decode" /path/to/wordpress/ grep -r "
Pulizia e ripristino sicuro
- Reinstalla core WordPress: download pulito versione corrente
wp core download --force --skip-content - Analizza e pulisci plugin: confronta con repository ufficiale, reinstalla da zero versioni pulite. Elimina plugin nulled o non ufficiali
- Verifica tema: confronta con versione originale, attenzione a file sospetti in uploads/
- Sanitizza database: cerca codice malevolo in post_content, options, postmeta
wp db query "SELECT * FROM wp_options WHERE option_value LIKE '%base64%'" - Aggiorna tutto: core, plugin, tema alle ultime versioni sicure
- Hardening sicurezza: disabilita file editing, proteggi wp-config.php, implementa 2FA, limita tentativi login
Tempo stimato: 3-6 ore per infezione media. Infezioni complesse o siti grandi possono richiedere 8-12 ore.
Prevenzione reinfezione
- Implementa monitoring integrità file (Wordfence, Sucuri, iThemes Security)
- Configura backup automatici giornalieri testati
- Abilita auto-update per security patch
- Audit permessi utenti WordPress: rimuovi admin inutilizzati
- Implementa WAF (Cloudflare, Sucuri Firewall)
Procedura 3: Database corrotto o crash
Scenario: errore "Error establishing database connection", tabelle corrotte, query fallite. Problema comune dopo crash server o disco pieno.
Diagnosi database
- Verifica connettività MySQL:
mysql -u user -p -h localhost -e "SHOW DATABASES;" - Controlla status servizio:
systemctl status mysql # o service mysql status - Verifica spazio disco: database non parte se disco pieno
df -h du -sh /var/lib/mysql/ - Controlla log errori MySQL:
tail -100 /var/log/mysql/error.log - Identifica tabelle corrotte:
mysqlcheck -u user -p database --check
Riparazione database
- Abilita repair mode WordPress: aggiungi a wp-config.php
define('WP_ALLOW_REPAIR', true);Accedi a
domain.com/wp-admin/maint/repair.php - Repair via mysqlcheck:
mysqlcheck -u user -p database --auto-repair - Optimize dopo repair:
mysqlcheck -u user -p database --optimize - Se repair fallisce: ripristina da backup database più recente
Tempo stimato: 15-45 minuti. Database grandi (>2GB) possono richiedere ore per repair completo.
Automazioni e integrazioni runbook
Un runbook efficace nel 2026 non è solo documento statico ma sistema integrato con tool agenzia.
Integrazioni essenziali
- Sistema ticketing: ogni procedura genera ticket con template pre-compilato (Jira, Linear, ClickUp)
- Monitoring: alert automatici attivano runbook specifico (UptimeRobot, Pingdom, StatusCake)
- Notification: escalation automatica via Slack/Teams con checklist interattiva
- Documentation: log automatico azioni eseguite per compliance e post-mortem
- Password manager: link diretti a credenziali necessarie (1Password CLI integration)
Script di supporto
Crea repository Git con script riutilizzabili per procedure comuni:
#!/bin/bash
# emergency-backup.sh
# Backup rapido pre-intervento
SITE_PATH=$1
BACKUP_DIR="/backups/emergency"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
echo "Starting emergency backup for $SITE_PATH"
# File backup
tar -czf $BACKUP_DIR/files-$TIMESTAMP.tar.gz -C $SITE_PATH .
# Database backup
wp db export $BACKUP_DIR/db-$TIMESTAMP.sql --path=$SITE_PATH
echo "Backup completed: $BACKUP_DIR/*-$TIMESTAMP.*"Metriche e miglioramento continuo
Traccia per ogni intervento:
- Tempo detection → inizio intervento (target: <15 min per P0)
- Tempo totale ripristino (MTTR)
- Procedura utilizzata e deviazioni dal runbook
- Root cause identificata
- Costo intervento (ore team)
Analizza quarterly: quali emergenze più frequenti? Quali procedure necessitano ottimizzazione? Dove investire in prevenzione?
Template runbook: struttura consigliata
Struttura documento runbook consigliata per agenzie (formato Notion, Confluence o Google Docs):
- Dashboard overview: tabella siti cliente con link diretti a sezione specifica, status ultimo backup, severity medio, contatti
- Procedure per scenario: sezione per ogni tipo emergenza (10-15 scenari coprono 95% casi reali)
- Reference tecnica: comandi comuni, troubleshooting generico, link documentazione
- Contatti e escalation: team interno, fornitori hosting, esperti esterni
- Post-mortem log: storico interventi con lesson learned
- Changelog runbook: versioning procedure, update dopo ogni incidente significativo
Mantieni versione PDF stampabile per scenari estremi (infrastruttura agenzia offline).
Checklist implementazione runbook in agenzia
Per implementare efficacemente un runbook disaster recovery:
- Audit situazione attuale: documenta tutti i siti gestiti, backup esistenti, procedure informali già in uso
- Prioritizza siti critici: inizia runbook dettagliato per top 20% siti per fatturato/criticità
- Coinvolgi team: workshop per raccogliere esperienze emergenze passate, identificare gap
- Crea template base: struttura generale applicabile a maggior parte siti
- Personalizza per cliente: adatta template a specificità tecniche (hosting, stack, integrazioni)
- Testa procedure: disaster recovery drill trimestrali su siti non critici o staging
- Forma team: onboarding nuovo personale include simulazioni emergenze
- Revisiona regolarmente: quarterly review procedure, update dopo ogni incidente reale
- Automatizza dove possibile: script, monitoring, notification riducono errore umano
Implementazione completa richiede 2-4 settimane per agenzia media (20-30 siti). Investimento ripagato al primo incidente gestito efficacemente.
Tool e risorse per disaster recovery WordPress
Strumenti consigliati per supportare runbook operativo:
Backup e recovery
- UpdraftPlus Premium: backup automatici, ripristino granulare, storage multipli
- BlogVault: backup incrementali real-time, staging integrato, malware scanning
- BackWPup: soluzione open source flessibile, job multipli schedulabili
- Duplicator Pro: eccellente per migrazioni e cloning rapido
Monitoring e alerting
- ManageWP: gestione centralizzata multi-sito, backup, monitoring uptime
- MainWP: alternativa self-hosted open source a ManageWP
- UptimeRobot: monitoring HTTP/HTTPS con alert multi-canale
- New Relic: APM completo per performance e error tracking
Sicurezza e malware
- Wordfence: firewall, scanning, response team per emergenze
- Sucuri: WAF cloud, incident response, cleanup garantito
- iThemes Security Pro: hardening completo, 2FA, file change detection
Documentazione e procedure
- Notion: wiki aziendale con database siti, checklist interattive
- Confluence: documentazione enterprise con permessi granulari
- IT Glue: piattaforma documentazione specifica MSP/agenzie
Per agenzie che gestiscono 15+ siti, considerate piattaforme come AgencyPilot che integrano monitoring, backup management e runbook operativi in dashboard unificata.
FAQ
Quanto spesso va testato il runbook di disaster recovery?
Il runbook va testato almeno trimestralmente attraverso disaster recovery drill pianificati. Seleziona un sito non critico o ambiente staging e simula uno scenario di emergenza (es. ripristino da backup, recovery da database corrotto). Testa anche componenti specifici: tempo di accesso credenziali, funzionamento script automatici, catena di escalation. Dopo ogni incidente reale, aggiorna il runbook con lesson learned entro 48 ore. Agenzie mature eseguono test mensili rotando scenari diversi e coinvolgendo membri team differenti per verificare che procedure siano comprensibili a tutti.
Quali informazioni sensibili vanno protette nel runbook?
Non inserire mai password, chiavi API o token in chiaro nel runbook. Usa riferimenti a password manager aziendale con vault dedicati per cliente (es. "Credenziali in 1Password > Vault Cliente X > WordPress Admin"). Proteggi accessi SSH con chiavi anziché password e documenta solo path alle chiavi. Per informazioni sensibili come dettagli infrastruttura, IP whitelisting o vulnerabilità note, mantieni runbook su piattaforma con controllo accessi granulare (Notion Enterprise, Confluence con permissions). Considera versione runbook "sanitized" per contractor o junior senza accesso completo. Backup del runbook stesso va cifrato e versionato.
Come gestire disaster recovery per siti WooCommerce con transazioni attive?
Siti e-commerce richiedono procedura specifica per minimizzare perdita transazioni. Prima del ripristino, esporta ordini e customer data dall'admin WooCommerce se accessibile. Durante downtime, attiva maintenance page con messaggio chiaro e stima ripristino (evita perdita fiducia cliente). Dopo ripristino, verifica integrità ordini confrontando con email notifiche inviate e gateway pagamento (Stripe, PayPal dashboard). Considera finestra manutenzione programmata per ripristini non urgenti (es. ore notturne). Per siti critici implementa setup high-availability con failover automatico o replica database real-time. Comunica proattivamente ai clienti finali via email status ordini e eventuali azioni necessarie.
Quale backup retention policy è adeguata per siti cliente?
Policy standard consigliata: backup giornalieri conservati 30 giorni, backup settimanali conservati 3 mesi, backup mensili conservati 1 anno. Per siti e-commerce o alta frequenza contenuti: backup ogni 6-12 ore conservati 7 giorni, poi daily per 60 giorni. Mantieni sempre almeno 3 generazioni backup anche per siti poco attivi (protezione da corruzioni silenziose). Testa ripristino almeno un backup al mese selezionato casualmente. Storage off-site obbligatorio: mai solo su stesso server del sito (usa S3, Backblaze B2, Google Cloud Storage). Per compliance GDPR, documenta retention e cancellazione automatica dopo periodo. Siti critici: considera backup incrementali continui con point-in-time recovery (BlogVault, UpdraftPlus Premium).
Come quantificare il ROI di un runbook disaster recovery?
Calcola ROI confrontando costo implementazione vs costi evitati. Investimento iniziale: 40-60 ore per runbook completo (15-20 siti), circa €2.400-€3.600 a €60/ora. Costi evitati per incidente gestito efficacemente: riduzione MTTR da 8h a 2h = 6 ore risparmiate (€360), riduzione churn cliente da 15% a 3% post-incidente (valore lifetime cliente medio), costi reputazionali evitati. Con media 4 incidenti/anno, risparmio diretto €1.440 + retention cliente. ROI positivo già primo anno. Benefici indiretti: onboarding nuovi tecnici più rapido (20 ore risparmiate), riduzione stress team, upsell servizi gestione proattiva a clienti. Agenzie con runbook maturo riportano 60% riduzione escalation emergenze e 40% miglioramento client satisfaction scores.