Disaster Recovery per PMI italiane: RPO, RTO e 3 architetture tipiche

Il Disaster Recovery (DR) è una delle aree IT dove le PMI italiane hanno la disconnessione più grande fra dichiarazioni e realtà operativa: quasi tutti dicono di “fare i backup”, quasi nessuno saprebbe ripristinare il business in 2 ore se il datacenter prendesse fuoco. NIS2 ha cambiato le regole: per le PMI in scope (settori essenziali/importanti, soglie 50 dipendenti o 10 M€ fatturato) la business continuity diventa obbligo formale, non opzione. Per le PMI fuori scope, è comunque una delle 3 voci di spesa IT con il più alto ROI: costa 1 quello che evita di costare 100.

Questo pillar copre tutto il necessario per progettare e dimensionare un DR strutturato in PMI italiane: definizioni rigorose RPO/RTO (la differenza fa il 90% delle conversazioni mal poste), le 3 architetture standard del mercato 2026 (backup-only, pilot light, multi-region active-passive), costi tipici Azure per ognuna, mappa dell’obbligo NIS2, errori frequenti. Per la sintesi prodotto-specifica vedi anche il confronto Veeam Cloud vs Azure Backup; per le scelte di hosting cloud vedi Azure vs AWS per software custom.

Indice

1. Backup ≠ Disaster Recovery (definizioni)
2. RPO e RTO: il vocabolario operativo
3. Architettura A — Backup-only (RPO 24h / RTO 4-24h)
4. Architettura B — Pilot light (RPO 1h / RTO 1-2h)
5. Architettura C — Multi-region active-passive (RPO 5min / RTO 15min)
6. NIS2: quando il DR diventa obbligo formale
7. Test DR: la parte che NESSUNO fa
8. Errori frequenti

Backup ≠ Disaster Recovery (definizioni)

Confusione di termini più costosa del settore IT italiano. Definizioni operative:

Backup: copia periodica dei dati conservata separatamente. Risponde alla domanda “ho cancellato per sbaglio un file, posso recuperarlo?”. È un componente del DR, non DR a sé.

Disaster Recovery: capacità di ripristinare l’operatività del business dopo un evento disastroso (incendio datacenter, ransomware, errore catastrofico, alluvione). Risponde alla domanda “il nostro datacenter è inaccessibile da 4 ore, quanto ci vuole a tornare operativi?”. Include backup ma anche infrastruttura alternativa, procedure di ripristino, DNS switch, comunicazione utenti, test periodici.

Business Continuity: capacità di continuare a operare durante un evento (non solo ripristinare dopo). Include DR + processi non-IT (sede alternativa, telefoni, formazione personale al piano B). È un sovra-insieme del DR.

La distinzione tecnica è: backup è il dato, DR è il sistema, BC è l’azienda. Una PMI può avere backup eccellenti e DR pessimo (i dati ci sono ma sono inaccessibili per 3 giorni). Può avere DR eccellente e BC pessimo (i sistemi tornano in 1 ora ma il personale non sa come usarli). Il taglio di questa guida è DR, area dove le PMI italiane sono più indietro.

RPO e RTO: il vocabolario operativo

Due metriche su cui si fonda tutto il dimensionamento DR. Memorizzale, non sono opzionali.

RPO — Recovery Point Objective

Quanti dati massimi posso perdere? Espresso in tempo (es. RPO 1 ora = nel caso peggiore perdo l’ultima ora di lavoro).

RPO basso = costa di più (replica più frequente = più storage e network).

Esempi tipici PMI italiane:

RTO — Recovery Time Objective

Quanto tempo massimo accetto che il sistema sia down? Espresso in tempo (es. RTO 2 ore = dopo 2 ore di disservizio il business riprende).

RTO basso = costa molto di più (infrastruttura sempre pronta = più server, più licenze).

Esempi tipici PMI italiane:

La regola pratica

Non tutti i sistemi hanno gli stessi requisiti. Una PMI manifattura può tollerare benissimo che il sito web stia giù per 24 ore (RTO 24h), ma se il gestionale di produzione va giù per 4 ore perdono 30 k€ di lavorato (RTO 1h). Il DR di queste due cose va dimensionato diversamente — non si fa “DR uniforme” perché si paga 3 volte il giusto.

Pattern operativo: classifica i sistemi in 3 tier (mission-critical / business-important / supporto), assegna RPO/RTO target per tier, scegli l’architettura DR per tier.

Architettura A — Backup-only (RPO 24h / RTO 4-24h)

Cos’è: backup giornalieri del sistema verso una destinazione separata (cloud o NAS off-site). In caso di disastro, ripristino dei backup su nuova infrastruttura.

Quando ha senso: sistemi a tier 3 (supporto, dati storici, sistemi non-critical) o PMI molto piccole (5-15 dip) dove tutti i sistemi sono “important ma non critical”.

Tecnologia tipica:

• Veeam Backup for Microsoft 365 per dati M365 (Email, OneDrive, SharePoint, Teams)
• Veeam Cloud per server fisici/VM (Hyper-V, VMware, Linux)
• Azure Backup per workload Azure
• Storage tipico: Azure Blob Storage (cool/cold tier) per ottimizzare costi

Procedura DR:

1. Disastro avviene (es. ransomware su file server primario)
2. Team operativo identifica scope dell’incident (2-6 ore)
3. Spin-up VM o servizio nuovo su infrastruttura alternativa (1-4 ore)
4. Restore backup più recente sul nuovo target (1-8 ore in base a volume dati)
5. Switch DNS / configurazione punto-finale (1 ora)
6. Test funzionale + go-live (1-2 ore)

RTO realistico: 4-24 ore (8 ore tipico) per un sistema PMI.

Costo tipico PMI italiana 50 dip:

• Backup M365 (Veeam): ~3 €/utente/mese × 50 = 150 €/mese = 1.800 €/anno
• Backup VM cloud (Azure Backup) per 5 server: ~40 €/server/mese = 2.400 €/anno
• Setup iniziale + test annuale: 2.000 €/anno
• TCO 3 anni: ~18.600 €

Limite: rebuild completo dell’infrastruttura. Se è andata persa anche la configurazione (non solo i dati), serve ricostruire da documentazione runbook. La documentazione operativa diventa critica.

Architettura B — Pilot light (RPO 1h / RTO 1-2h)

Cos’è: oltre al backup giornaliero, un’infrastruttura alternativa pre-configurata (ma a basso costo, “in stand-by”) che può essere “accesa” in minuti. Si “pre-fabbrica” la versione DR del sistema su una region cloud secondaria, lasciandola a capacity ridotta. In caso di disastro, scala up + switch DNS.

Quando ha senso: sistemi a tier 2 (business-important, gestionali, CRM, ERP) per PMI 30-150 dip. Il vero sweet spot per PMI mid-market.

Tecnologia tipica Azure:

• Azure Site Recovery (ASR) per replica continua VM da region A a region B (RPO < 5 min teorico, RTO < 1h)
• Database geo-replicato (Azure SQL Geo-Replication, Cosmos DB multi-region)
• DNS Azure Traffic Manager o Azure Front Door per switch automatico
• Infrastruttura secondaria scalata down (es. VM più piccole, capacity ridotta a 30%)

Procedura DR:

1. Monitoring rileva disastro (alert automatici)
2. Team operativo conferma scope (15-30 min)
3. Failover automatico o manuale ad ASR (10-20 min — replica già continua)
4. Scale-up della capacity secondaria a livello produzione (20-30 min)
5. Verifica funzionale + comunicazione utenti (30 min)

RTO realistico: 1-2 ore per workload PMI ben progettato. RPO 15-60 minuti tipico.

Costo tipico PMI italiana 50 dip (incrementale rispetto al backup-only):

• Azure Site Recovery: ~25 €/server replicato/mese = 3.000 €/anno (10 server)
• Storage replicato secondario: ~30% storage primario × 0,02 €/GB/mese = 500 €/anno
• Infrastruttura secondaria stand-by: VM piccole su region B = 2.000 €/anno
• Setup iniziale + test semestrali: 5.000 €/anno (primo anno), 2.000 €/anno dopo
• TCO 3 anni incrementale: ~25.500 € (oltre al backup-only)

Limite: complessità setup iniziale alta. Serve buona competenza Azure architettura. Una PMI può farlo internamente con team IT esperto + 4-6 settimane di lavoro, oppure delegare a partner (SynSphere o equivalente) per setup chiavi in mano.

Architettura C — Multi-region active-passive (RPO 5min / RTO 15min)

Cos’è: due region cloud attive in parallelo, con sincronizzazione continua. La region “active” serve il traffico, la region “passive” è pronta a prendere il carico in pochi minuti. È il livello “enterprise-grade” del DR.

Quando ha senso: sistemi tier 1 (mission-critical) per PMI con e-commerce ad alto traffico, gestionali produzione 24/7, infrastructure-as-a-service erogata a clienti finali, ISV italiani con SLA contrattuali al 99,95%+. Tipicamente PMI 100+ dipendenti o ISV verticali.

Tecnologia tipica Azure:

• Region primaria (Italy North) + region secondaria (West Europe) con failover automatico
• Azure SQL Auto-failover Group (replica sincrona, RPO < 5 sec teorico)
• Storage geo-zone-redundant (GZRS) per dati statici
• Azure Front Door con priority routing + health probes per failover < 60 secondi
• Architettura applicativa stateless lato compute (sessioni utente in cache distribuita o token JWT, no sticky session)

Procedura DR:

1. Health probe rileva fault (10-30 secondi)
2. Failover automatico DNS via Front Door (1-2 min)
3. Carico migra su region passiva (zero intervento umano per i primi 15 min)
4. Team operativo conferma scope dell’incident in parallelo
5. Comunicazione utenti se necessaria

RTO realistico: 5-15 minuti. RPO < 5 min.

Costo tipico PMI italiana 50-150 dip (incrementale rispetto al pilot light):

• Replica sincrona DB cross-region: 30-50% overhead sui costi DB primario = 3.000-8.000 €/anno
• Compute attivo region secondaria (anche se minimo): 30-50% capacity primaria = 4.000-12.000 €/anno
• Front Door Premium + WAF: 600-1.500 €/anno
• Setup iniziale (architettura completa progettata per multi-region): 10.000-25.000 € una tantum
• Test DR mensili: 3.000 €/anno ricorrenti
• TCO 3 anni incrementale: ~40.000-100.000 € (oltre al pilot light)

Limite: investimento serio. Vale la pena solo per workload mission-critical dove ogni ora di downtime costa decine di migliaia di euro o si erogano servizi a clienti finali con SLA contrattuali. Per la maggior parte delle PMI italiane (90%+) questa architettura è over-engineering — Pilot Light è già “abbondante”.

NIS2: quando il DR diventa obbligo formale

D.Lgs 138/2024 (recepimento NIS2) art. 21 elenca 10 misure tecniche minime obbligatorie per soggetti essenziali e importanti. Tre di queste impattano direttamente il DR:

• Lettera c: business continuity (gestione di backup e ripristino di emergenza)
• Lettera d: sicurezza della supply chain (tema DR-related se fornitori critici)
• Lettera h: politiche e procedure per uso e gestione della crittografia

Cosa significa in pratica per le PMI italiane in scope NIS2 (50+ dip o 10+ M€ fatturato in settori manifattura, sanità, food, MSP IT, logistica):

1. Backup documentati e testati: non basta avere backup. Bisogna documentare cosa si backupa, con che frequenza, dove, e fare almeno un test ripristino all’anno documentato.
2. DR plan formale: documento aziendale che descrive le procedure di ripristino per i sistemi mission-critical, con RPO/RTO target e responsabili.
3. Audit ACN potenzialmente richiesto: dal 17 ottobre 2026 l’ACN può richiedere evidenza tecnica del DR plan e dei test eseguiti.

Per la guida completa NIS2 vedi il pillar D.Lgs 138/2024.

Per le PMI fuori scope NIS2: nessun obbligo formale. Ma è comunque buona pratica avere backup-only minimum + DR plan documentato — non per Garante, ma per la propria sopravvivenza aziendale.

Test DR: la parte che NESSUNO fa

Statistica empirica dal nostro lavoro su PMI italiane: il 70% delle PMI ha backup, il 20% ha un DR plan documentato, il 5% lo testa annualmente. Il 65% si scopre con DR rotto solo durante il disastro reale.

Test DR significa: una volta all’anno (per NIS2: obbligatorio), simulare un disastro e provare la procedura di ripristino end-to-end. Tipologie:

Tabletop exercise (1-2 ore): il team operativo discute “ipotizziamo che il datacenter sia inaccessibile da 4 ore, cosa facciamo?”. Identifica gap nel runbook, ruoli e responsabilità non chiare. Minimo richiesto per qualsiasi PMI seria.

Partial restore test (4-8 ore): si fa ripristino di una VM o di un dataset non-critical su ambiente di test. Verifica che i backup funzionino e che il team conosca la procedura. Tipico target annuale per PMI 30-50 dip.

Full DR drill (1-3 giorni): simulazione completa del disastro con switch verso infrastruttura secondaria, comunicazione utenti (in ambiente di test), verifica RTO/RPO effettivi. Obbligatorio per architettura C (multi-region active-passive), raccomandato per architettura B almeno ogni 2 anni.

Costo del test: 1.000-5.000 € per partial restore, 5.000-15.000 € per full drill (in base a complessità). Costo del NON test: la prima volta che il disastro è reale, scoprire che il backup era corrotto da 6 mesi.

Errori frequenti

Cinque errori che vediamo regolarmente nelle PMI che ci contattano post-incident:

1. Backup sullo stesso storage del primario. Ransomware cifra tutto, backup incluso. Backup deve essere su storage immutabile (Azure Blob immutability) o off-site fisicamente (cloud diverso, NAS in altra sede).

2. Retention troppo breve. Backup conservato 7 giorni. Ransomware rilevato 14 giorni dopo (timeline tipica). Backup pulito ormai sovrascritto. Retention minima raccomandata: 30 giorni rolling + 1 backup mensile per 12 mesi.

3. Niente test ripristino. Backup esistono ma nessuno ha mai verificato di poterli leggere. Caso reale frequente: backup database fatto con tool A, tool A discontinuato 2 anni dopo, backup illeggibile.

4. RPO/RTO non concordati col business. L’IT decide RTO 8 ore. Il business scopre durante il disastro che 8 ore di stop costano 80 k€. L’IT scopre che il business avrebbe pagato di più per RTO 1 ora. Sempre allineare RPO/RTO con il business prima del setup.

5. Documentazione runbook non aggiornata. Procedure scritte 3 anni fa, infrastruttura cambiata 2 volte, runbook obsoleto. Durante il disastro qualcuno legge il runbook e fa l’azione sbagliata. Review runbook ogni 6-12 mesi.

CTA

Hai backup ma non un DR plan strutturato? Tre passi pratici:

1. Classifica i sistemi in 3 tier (mission-critical / business-important / supporto), assegna RPO/RTO target a ognuno usando le tabelle sopra come riferimento.
2. Scegli l’architettura per tier: tier 3 → A backup-only, tier 2 → B pilot light, tier 1 → C multi-region (solo se davvero mission-critical).
3. Programma un test annuale: anche solo un tabletop exercise di 2 ore vale più di un DR plan teorico mai testato.

Per un assessment del tuo setup attuale + dimensionamento DR con TCO chiaro, scrivici. Su PMI italiane il primo colloquio basta per identificare i tier critici e dimensionare in maniera ragionevole.