--- title: "Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0" description: "Il 60% delle PMI che subisce una perdita dati critica chiude entro 6 mesi. Un DRP con RPO/RTO definiti, backup 3-2-1-1-0 e test periodici è obbligatorio con NIS2." canonical: "https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-azienda.html" author: "Maurizio Fonte" date: "2025-05-29T08:11:16+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Business Continuity" tags: ["Business Continuity", "Consulenza IT"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) [Consulenza IT](https://www.mauriziofonte.it/blog/cat/consulenza_it.html) # [Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0](https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-azienda.html) Giovedì 29 Mag 2025, alle 08:11 ![Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0](https://www.mauriziofonte.it/image/001490200-disaster-recovery-plan-importanza-azienda.jpg) 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](https://invenioit.com/continuity/disaster-recovery-statistics/) 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](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) (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)](https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html) 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](https://itic-corp.com/itic-2024-hourly-cost-of-downtime-report/) 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](https://bp.veeam.com/security/Design-and-implementation/Protect.html): 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](https://advisera.com/27001academy/knowledgebase/how-to-implement-business-impact-analysis-bia-according-to-iso-22301/) (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: ```bash #!/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](https://www.percona.com/blog/backup-restore-performance-conclusion-mysqldump-vs-mysql-shell-utilities-vs-mydumper-vs-mysqlpump-vs-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](https://queue.acm.org/detail.cfm?id=2371516) (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](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html) 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](https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html): il monitoraggio rileva l'incidente, il DRP guida il ripristino. L'[Infrastructure as Code](https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html) 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](https://www.mauriziofonte.it/pages/about). Se il tuo "disaster recovery" è un dump MySQL nella stessa macchina di produzione, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dalla BIA e dalla definizione di RPO/RTO per i servizi critici. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteMonitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana28 Mag 2025](https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html)[Articolo successivo »Security awareness per PMI: dal 33% di click rate al 4% con simulazioni di phishing e formazione continua30 Mag 2025](https://www.mauriziofonte.it/blog/post/formazione-sicurezza-informatica-importanza-aziendale.html) ### Articoli correlati a Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0 - [Contrattualizzare la business continuity: perché un contractor PHP esperto tutela le applicazioni mission-critical della tua azienda](https://www.mauriziofonte.it/blog/post/business-continuity-applicazioni-php-pmi-contractor-esperto-disaster-recovery.html) Per una PMI, un'applicazione mission critical che smette di funzionare significa perdita di fatturato e danno reputazionale. Questo articolo · 13 Gennaio 2025 ![Contrattualizzare la business continuity: perché un contractor PHP esperto tutela le applicazioni mission-critical della tua azienda](https://www.mauriziofonte.it/image/001100070-business-continuity-applicazioni-php-pmi-contractor-esperto-disaster-recovery.jpg) - [Disaster Recovery Plan: perché senza un piano reale stai giocando d'azzardo con il futuro della tua azienda](https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-strategica-azienda.html) La mancanza di un Disaster Recovery Plan mette seriamente a rischio il futuro della tua azienda. Scopri perché è fondamentale adottare subito · 14 Mag 2025 ![Disaster Recovery Plan: perché senza un piano reale stai giocando d'azzardo con il futuro della tua azienda](https://www.mauriziofonte.it/image/001020070-disaster-recovery-plan-importanza-strategica-azienda.jpg) - [Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/blog/post/impatto-attacco-ransomware-pmi-simulazione-piano-risposta.html) Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario · 11 Marzo 2026 ![Valutare l'impatto di un attacco ransomware su una PMI: simulazione e piano di risposta](https://www.mauriziofonte.it/image/002340070-impatto-attacco-ransomware-pmi-simulazione-piano-risposta.jpg) - [Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/blog/post/backup_del_filesystem_e_dei_database_di_server_web.html) Il backup di un server web non è uno script da lanciare e dimenticare: è una strategia che mette insieme due cose diverse, i file e i database, · 18 Febbraio 2026 ![Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/image/000070070-backup_del_filesystem_e_dei_database_di_server_web.jpg) - [Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) Un piano di disaster recovery non è un backup: è la definizione di RTO e RPO realistici, l'analisi del rischio, i runbook di ripristino, le procedure · 8 Settembre 2025 ![Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/image/002260070-piano-disaster-recovery-php-continuita-operativa-pmi.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-azienda.html Pubblicato: 2025-05-29 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.