Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0

In un progetto per un'azienda del settore servizi digitali, il "disaster recovery" consisteva in un dump MySQL giornaliero salvato nella stessa directory /var/backups/ del server di produzione. Quando un ransomware ha cifrato l'intero filesystem - inclusa quella directory - il backup più recente recuperabile aveva 47 giorni, salvato su un disco esterno USB che qualcuno aveva collegato "quella volta per sicurezza". Il ripristino ha richiesto 9 giorni di lavoro manuale, con perdita definitiva di 6 settimane di dati transazionali. La National Cybersecurity Alliance stima che il 60% delle piccole imprese che subisce una perdita dati significativa chiude entro 6 mesi - non per l'incidente in sé, ma per l'incapacità di ripristinare le operazioni in tempo.

Cos'è un Disaster Recovery Plan e perché NIS2 lo rende obbligatorio?

Un Disaster Recovery Plan (DRP) è la procedura documentata e testata che permette di ripristinare dati, applicazioni e infrastruttura entro tempi e con perdite dati predefiniti dopo un incidente. La differenza con un backup è strutturale: un backup è una copia dei dati, un DRP è l'intero processo - dalla rilevazione dell'incidente al ripristino completo dell'operatività - con ruoli, tempi e procedure verificate. Il NIST SP 800-34 Rev. 1 (Contingency Planning Guide) definisce i due parametri fondamentali: RPO (Recovery Point Objective), la quantità massima di dati che l'organizzazione può permettersi di perdere, misurata in tempo dall'ultimo backup valido; e RTO (Recovery Time Objective), il tempo massimo entro cui il servizio deve essere ripristinato. Un RPO di 1 ora significa che il backup deve essere eseguito almeno ogni ora; un RTO di 4 ore significa che il team deve essere in grado di ripristinare tutto in 4 ore.

La Direttiva NIS2 (EU 2022/2555) rende il DRP un obbligo normativo. L'Articolo 21, comma 2, lettera c) richiede esplicitamente "business continuity, such as backup management and disaster recovery, and crisis management" come misura minima di gestione del rischio cybersecurity. Le sanzioni arrivano fino a 10 milioni di euro o il 2% del fatturato globale per le entità essenziali, e il management può essere ritenuto personalmente responsabile. Per le PMI italiane, questo significa che un DRP documentato con RPO/RTO definiti non è più una best practice - è un requisito legale.

Il report ITIC 2024 stima che il 90% delle medie e grandi imprese subisce costi superiori a $300.000 per ogni ora di downtime. Per le PMI i costi diretti sono inferiori, ma l'impatto proporzionale è devastante: un e-commerce da 500K€/anno che perde 3 giorni di operatività perde il 2.5% del fatturato annuo in un singolo incidente - a cui si aggiungono i costi di ripristino e la perdita di clienti.

Come implementare un DRP con backup 3-2-1-1-0 per infrastrutture PHP/Linux?

La regola 3-2-1, formulata da Peter Krogh nel 2005, prescrive 3 copie dei dati, su 2 supporti diversi, di cui 1 offsite. Veeam ha esteso la regola a 3-2-1-1-0: aggiunge 1 copia immutabile (protezione da ransomware che cifra i backup) e 0 errori (verifica automatica della recuperabilità). L'immutabilità si implementa con S3 Object Lock, backup su storage append-only o copie air-gapped (disco offline).

La Business Impact Analysis (BIA), definita dalla clausola 8.2.2 di ISO 22301:2019, è il processo formale per derivare RPO e RTO. Il framework stabilisce una gerarchia: MTPD (Maximum Tolerable Period of Disruption) > RTO > RPO. Il MTPD è il limite assoluto oltre il quale l'organizzazione subisce danni irreversibili; l'RTO deve rientrare in questo limite con margine di sicurezza; l'RPO determina la frequenza dei backup. Per un applicativo PHP/MySQL su VPS, uno script di backup automatizzato implementa la regola 3-2-1-1-0:

#!/bin/bash
set -euo pipefail

## Variabili - adattare a ciascun server
DB_NAME="production_db"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/dr"
RESTIC_REPO="s3:s3.eu-central-1.amazonaws.com/company-backups"
RETENTION_DAYS=30
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

## 1. Dump MySQL con lock minimo (single-transaction per InnoDB)
mysqldump --single-transaction --routines --triggers \
  --user="${DB_USER}" "${DB_NAME}" \
  | gzip > "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz"

## 2. Backup incrementale cifrato con restic (copia 2: offsite S3)
## restic usa AES-256 e deduplicazione content-defined
restic -r "${RESTIC_REPO}" backup \
  "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz" \
  /var/www/production/storage \
  /var/www/production/.env \
  /etc/nginx/sites-available \
  /etc/php/8.3/fpm/pool.d \
  --tag "daily" --tag "automated"

## 3. Verifica integrità (lo "0 errori" della regola 3-2-1-1-0)
restic -r "${RESTIC_REPO}" check --read-data-subset=10%

## 4. Pulizia retention - mantieni 30 giornalieri, 12 settimanali
restic -r "${RESTIC_REPO}" forget \
  --keep-daily ${RETENTION_DAYS} \
  --keep-weekly 12 \
  --prune

## 5. Notifica esito (integra con Slack/email/Alertmanager)
echo "Backup completato: db_${TIMESTAMP}.sql.gz - verificato OK"

Per database MySQL superiori a 10 GB, Percona XtraBackup è l'alternativa a mysqldump: esegue backup fisici hot (senza lock), supporta backup incrementali e point-in-time recovery. Il benchmark Percona su un database da 177 GB mostra tempi di restore ordini di grandezza inferiori rispetto al dump logico. Per database sotto i 5 GB - la maggioranza delle PMI - mysqldump --single-transaction resta la scelta più semplice e portabile.

Errori comuni nella pianificazione del Disaster Recovery

Il primo errore è non testare i backup. Un backup non testato è un'ipotesi, non una garanzia. Google ha formalizzato questa pratica con il programma DiRT (Disaster Recovery Testing): esercitazioni annuali multi-giorno che rompono intenzionalmente sistemi di produzione per verificare che le procedure di recovery funzionino. Il principio si applica a ogni scala: per una PMI, un test trimestrale di restore completo (database + applicativo + configurazione) su un server di staging è il minimo. Se il restore non funziona in test, non funzionerà in emergenza.

Il secondo è non definire RPO e RTO. Senza questi parametri, il team non sa quale backup ripristinare, quanto tempo ha per completare il recovery, né quale livello di perdita dati è accettabile. Il risultato è improvvisazione sotto pressione - esattamente la condizione che produce errori. La BIA (ISO 22301) fornisce il framework per derivare RPO e RTO dai requisiti di business, non dalla capacità tecnica.

Il terzo è salvare i backup sullo stesso server di produzione. Un ransomware che cifra il filesystem cifra anche /var/backups/. La copia immutabile della regola 3-2-1-1-0 esiste per questo: un backup su S3 con Object Lock non può essere modificato né cancellato per il periodo di retention configurato, nemmeno con le credenziali root del bucket.

Il quarto è avere un DRP che nessuno conosce. Un documento PDF in una cartella condivisa che nessuno ha letto non è un piano - è documentazione inerte. Il DRP deve includere un runbook operativo con comandi esatti, credenziali di accesso ai backup (in un password manager, non nel documento), contatti di escalation e checklist per ogni tipo di incidente. I backup per VPS senza un runbook di restore testato lasciano il team nella stessa condizione di chi non ha backup.

Il Disaster Recovery è il complemento del monitoraggio proattivo: il monitoraggio rileva l'incidente, il DRP guida il ripristino. L'Infrastructure as Code rende il DRP ripetibile - un playbook Ansible che ricostruisce l'intero stack da zero è un piano di recovery testabile, non una procedura manuale soggetta a errori. Per conoscere il mio approccio alla business continuity per infrastrutture PHP, visita la mia pagina professionale. Se il tuo "disaster recovery" è un dump MySQL nella stessa macchina di produzione, contattami per una consulenza dedicata - partiamo dalla BIA e dalla definizione di RPO/RTO per i servizi critici.