Backup realtime e disaster recovery WordPress: quando serve davvero (e quando è spesa inutile)

Sul backup c'è un malinteso diffuso. Si parla di «backup realtime» come fosse un upgrade universale, una cosa che ogni sito dovrebbe avere. La realtà è più semplice — e meno romantica. Per la maggior parte dei siti WordPress un backup giornaliero verificato è più che sufficiente. Il realtime ha un costo e un senso solo quando la frequenza di cambiamento dei dati rende un gap di 24 ore una perdita inaccettabile.

Il primo dato che guardiamo quando ci arriva un sito nuovo è proprio questo: quanto spesso cambiano i contenuti? Un sito vetrina di un avvocato, aggiornato due volte l'anno, non ha bisogno di backup realtime. Un e-commerce che processa centinaia di ordini al giorno sì. Un portale editoriale che pubblica ogni ora sì. La differenza non è estetica: è la quantità di lavoro che si perde tra un backup e il successivo.

Cosa cambia davvero tra giornaliero e realtime

Un backup giornaliero scatta a un'ora fissa — tipicamente di notte, quando il traffico è basso. Se il sito si rompe alle 18:00, il punto di ripristino è la notte precedente: perdi tutto ciò che è successo tra le 00:00 e le 18:00. Per un blog è un fastidio. Per uno store è fatturato perso, ordini duplicati al ripristino, clienti che ricevono conferme per ordini che tecnicamente non esistono più.

Il backup realtime — più propriamente, la replica continua o il backup quasi-continuo — cattura le modifiche man mano che avvengono. In WordPress questo si ottiene in due modi: replicando il database in tempo reale su un'istanza separata, o scattando snapshot incrementali molto frequenti (ogni pochi minuti). Il primo è più costoso ma permette un failover vero; il secondo è più economico e riduce il gap a pochi minuti.

Quando il realtime è tecnicamente necessario

Tre casi lo giustificano. Primo: gli e-commerce WooCommerce con volume di ordini significativo. Ogni ordine è una transazione economica; perderne anche solo un'ora significa dispute, chargeback e danni reputazionali. Secondo: i siti editoriali che pubblicano a cadenza oraria — news, magazine, portali — dove un'ora di contenuti persi è lavoro giornalistico buttato. Terzo: forum e community dove gli utenti generano contenuti continuamente (commenti, post, iscrizioni): perdere le loro contribuzioni è un danno di fiducia, non solo di dati.

Per questi scenari il backup realtime non è un lusso: è la differenza tra un ripristino che costa minuti e uno che costa giorni di lavoro manuale per ricostruire ciò che è andato perso.

# Verifica la frequenza di modifica del database (indicatore grezzo)
# Conta le righe inserite/modificate nelle ultime 24h nelle tabelle più attive
mysql -u root -p -e "
SELECT 'wp_posts' AS tbl, COUNT(*) AS changes_last_24h
FROM wp_posts WHERE post_modified > NOW() - INTERVAL 1 DAY
UNION ALL
SELECT 'wp_woocommerce_orders', COUNT(*)
FROM wp_woocommerce_orders WHERE date_created > NOW() - INTERVAL 1 DAY
UNION ALL
SELECT 'wp_comments', COUNT(*)
FROM wp_comments WHERE comment_date > NOW() - INTERVAL 1 DAY;
"

Costruire un piano disaster recovery — e testarlo

Avere i backup non significa avere un piano DR. Un piano disaster recovery è una procedura documentata, testata, con un tempo di ripristino misurato. La regola è semplice: un backup non testato è un backup che non sai se funziona. Quante volte abbiamo visto backup regolari che al momento del bisogno risultavano corrotti, incompleti, o privi delle credenziali per ripristinarli.

Un piano DR serio ha tre componenti. La frequenza (giornaliera o realtime, decisa sul volume). La conservazione (non solo l'ultimo backup, ma una rotazione: 7 giornalieri, 4 settimanali, 12 mensili). E il test periodico: ripristinare il backup in un ambiente isolato e verificare che il sito carichi, che il database sia coerente, che i file media ci siano tutti.

# Test di ripristino in ambiente isolato (da eseguire mensilmente)
#!/bin/bash
# 1. Crea un'istanza di test pulita
wp db create test_restore --path=/var/www/test
# 2. Importa l'ultimo backup
wp db import /backups/last_backup.sql --path=/var/www/test
# 3. Sostituisci l'URL di produzione con quello di test
wp search-replace 'https://produzione.it' 'https://test.local' --path=/var/www/test
# 4. Verifica che il sito risponda
HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' https://test.local/)
if [ "$HTTP_CODE" = "200" ]; then
    echo "DR TEST OK: ripristino funzionante"
else
    echo "DR TEST FALLITO: HTTP $HTTP_CODE — il backup non è ripristinabile"
fi

Il costo nascosto del backup sbagliato

C'è un costo anche nel backup eccessivo. Attivare il realtime su un sito vetrina che cambia due volte l'anno è spesa inutile: paghi infrastruttura, storage e complessità operativa per un beneficio nullo. D'altra parte, tenere un backup giornaliero su un e-commerce che fa 500 ordini al giorno significa accettare di perdere fino a 500 ordini in caso di ripristino. Nessuna delle due è la scelta giusta: la scelta giusta dipende dal volume reale di cambiamento dei dati.

Il backup realtime è incluso nei piani di assistenza WooCommerce di WP Planet perché per un e-commerce è la scelta tecnicamente corretta. Per i siti editoriali ad alta frequenza di pubblicazione è attivabile quando tecnicamente necessario e previsto dal servizio. Per il resto, un backup giornaliero verificato e testato mensilmente è la combinazione che offre il miglior rapporto tra costo e protezione reale.