Backup 3-2-1 per WordPress: il playbook completo per web agency

Se gestisci server per clienti WordPress, hai già sentito parlare della regola 3-2-1. Il problema è che la maggior parte delle agenzie la applica a metà: hanno "i backup", ma non sono mai stati testati. Quando arriva il disastro, scopri che l'ultimo backup funzionante è di tre mesi fa.

Questo playbook ti guida all'implementazione completa di una strategia backup 3-2-1 per WordPress, con tool specifici, script pronti e procedure di test.

Se stai lavorando su un'infrastruttura già fragile, leggi anche Server down: cosa fare nei primi 60 minuti e la pagina Backup & Disaster Recovery per trasformare questo playbook in un processo continuo.

Cos'è la regola 3-2-1 (e perché conta)

La regola è semplice:

• 3 copie dei tuoi dati (produzione + 2 backup)
• 2 supporti diversi (es. disco locale + object storage)
• 1 copia off-site (geograficamente distante)

Il punto non è fare backup. Il punto è riuscire a ripristinare. Un backup mai testato è un backup che non esiste.

Architettura consigliata per WordPress

Per un tipico hosting WordPress multisite su VPS, l'architettura che usiamo è questa:

Livello 1 - Backup locale (RPO: 1 ora)

• Snapshot LVM o backup incrementale su disco locale
• Serve per ripristini rapidi (file cancellati, update falliti)
• Non conta come backup "vero": se il disco muore, perdi tutto

Livello 2 - Backup off-site (RPO: 24 ore)

• BorgBackup o Restic verso object storage
• Compressione + deduplicazione = costi contenuti
• Retention: 7 giorni orari, 4 settimanali, 12 mensili

Livello 3 - Backup immutabile (RPO: 24 ore)

• Object Lock su S3-compatible (Backblaze B2, Hetzner Object Storage)
• Protezione da ransomware e cancellazione accidentale
• Retention: 30 giorni minimo

Tool: BorgBackup vs Restic

Entrambi sono validi. La scelta dipende dal contesto:

BorgBackup è la nostra scelta per server fissi:

• Compressione migliore (LZ4 o ZSTD)
• Deduplicazione più efficiente
• Repository-level encryption
• Serve Python sul server target

Restic è meglio per ambienti eterogenei:

• Binario statico Go (nessuna dipendenza)
• Supporto nativo per S3, B2, Azure, GCS
• Più semplice da configurare

Per questo playbook usiamo BorgBackup, ma i concetti si applicano a entrambi.

Se gestisci più siti WordPress e noti rallentamenti durante backup o restore, completa la lettura con Sito lento: 5 cause che il 90% delle agenzie ignora.

Step 1: Setup BorgBackup

# Installazione (Debian/Ubuntu)
apt update && apt install borgbackup

# Creazione repository criptato su storage remoto
export BORG_PASSPHRASE="la-tua-frase-segreta-lunghissima"
borg init --encryption=repokey-blake2 ssh://[email protected]/backup/webserver01

Quando questo playbook non basta

Se hai già avuto perdita dati, backup corrotti o restore falliti in produzione, la parte critica non è più "configurare il backup" ma progettare un vero runbook di recovery. In quel caso ha più senso partire da un audit gratuito o da un intervento SOS per verificare RPO, RTO e integrità dei repository già esistenti.

Step 2: Script di backup automatizzato

Questo script gestisce un tipico sito WordPress:

#!/bin/bash
# /usr/local/bin/wp-backup.sh

set -euo pipefail

SITE_DIR="/var/www/miosito.it"
DB_NAME="miosito_wp"
REPO="ssh://[email protected]/backup/miosito.it"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOG="/var/log/backup/miosito.it.log"

log() { echo "[$(date '+%Y-%m-%d %H:%M')] $1" >> "$LOG"; }

log "=== Inizio backup $TIMESTAMP ==="

# Dump database
mysqldump --single-transaction --routines --triggers "$DB_NAME" \
  > "${SITE_DIR}/db-backup.sql"
log "Dump database completato"

# Freeze filesystem (se LVM)
# lvchange -ay -pr vg0/snap_home 2>/dev/null || true

# Backup con Borg
borg create --stats --compression zstd,6 \
  "${REPO}::wp-${TIMESTAMP}" \
  "$SITE_DIR" \
  --exclude "${SITE_DIR}/wp-content/cache/*" \
  --exclude "${SITE_DIR}/wp-content/uploads/cache/*"
log "Backup Borg completato"

# Cleanup: mantieni retention
borg prune --keep-hourly=7 --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \
  "$REPO"
log "Retention pruning completato"

# Rimuovi dump temporaneo
rm -f "${SITE_DIR}/db-backup.sql"
log "=== Fine backup ==="

Step 3: Configura crontab

# Backup ogni 6 ore
0 */6 * * * /usr/local/bin/wp-backup.sh 2>&1 | logger -t wp-backup

# Notifica fallimenti
0 8 * * * /usr/local/bin/check-backup-health.sh

Step 4: Test di ripristino (la parte che nessuno fa)

Script di test ripristino:

#!/bin/bash
# /usr/local/bin/test-restore.sh

set -euo pipefail

RESTORE_DIR="/tmp/restore-test"
REPO="ssh://[email protected]/backup/miosito.it"
DB_RESTORE="test_restore_db"

# Pulisci directory test
rm -rf "$RESTORE_DIR"
mkdir -p "$RESTORE_DIR"

# List backup disponibili
echo "Backup disponibili:"
borg list "$REPO" --short | tail -5

# Ripristina ultimo backup
LATEST=$(borg list "$REPO" --short | tail -1)
borg extract "${REPO}::${LATEST}" --destination "$RESTORE_DIR"
echo "Ripristino completato in $RESTORE_DIR"

# Test database
mysql -e "CREATE DATABASE IF NOT EXISTS $DB_RESTORE"
mysql "$DB_RESTORE" < "${RESTORE_DIR}/var/www/miosito.it/db-backup.sql"
echo "Database ripristinato: $DB_RESTORE"

# Verifica file chiave
for f in wp-config.php wp-content/themes wp-content/plugins; do
  if [ -e "${RESTORE_DIR}/var/www/miosito.it/$f" ]; then
    echo "✓ $f presente"
  else
    echo "✗ MANCANTE: $f"
  fi
done

# Cleanup
mysql -e "DROP DATABASE $DB_RESTORE"
rm -rf "$RESTORE_DIR"
echo "Test completato e pulito"

Policy di retention consigliata

| Livello | Frequenza | Retention | Scopo | |---------|-----------|-----------|-------| | Orario | Ogni 6 ore | 7 giorni | Errori umani, update falliti | | Giornaliero | 1/giorno | 30 giorni | Cancellazioni accidentali | | Settimanale | 1/settimana | 12 settimane | Recovery a lungo termine | | Mensile | 1/mese | 12 mesi | Compliance, audit |

Monitoraggio dei backup

Un backup che fallisce silenziosamente è peggio di nessun backup. Implementa alerting:

# Controlla se l'ultimo backup ha più di 8 ore
LAST_BACKUP=$(borg list ssh://backup@storage/backup/miosito.it --short | tail -1)
BACKUP_DATE=$(echo "$LAST_BACKUP" | cut -d- -f2)
HOURS_AGO=$(( ($(date +%s) - $(date -d "$BACKUP_DATE" +%s)) / 3600 ))

if [ "$HOURS_AGO" -gt 8 ]; then
  echo "ATTENZIONE: Ultimo backup $HOURS_AGO ore fa" | \
    mail -s "Backup Alert: miosito.it" [email protected]
fi

Checklist di implementazione

Prima di dichiarare "fatto", verifica:

• [ ] 3 copie dei dati (prod + 2 backup)
• [ ] 2 supporti diversi (disco + object storage)
• [ ] 1 copia off-site con geographic separation
• [ ] Almeno 1 copia con Object Lock (immutabile)
• [ ] Backup automatici in crontab
• [ ] Monitoring con alert su fallimento
• [ ] Test di ripristino eseguito almeno una volta
• [ ] Documentato RTO/RPO effettivi dopo test
• [ ] Retention policy configurata e verificata
• [ ] Passphrase chiave conservata fuori dal server

Quando chiamare un esperto

Se hai più di 10 siti WordPress da gestire, o se i dati sono critici (e-commerce, dati personali), considera un servizio gestito. Il costo di un backup configurato male si misura in dati persi e clienti persi.

Un sistema di backup professionale si paga da solo al primo incidente reale.