Questo articolo mette ordine in un campo dove confusione regna sovrana: backup e DR non sono sinonimi, RPO e RTO non sono numeri di marketing, e il cloud (AWS, Azure, Veeam, Zerto) non e una bacchetta magica ma un set di strumenti con costi, limiti e procedure ben definite. L’obiettivo: aiutare il responsabile IT di una PMI da 20-100 dipendenti a costruire un piano DR che funzioni davvero il giorno del disastro.<\/p>\n
TL;DR<\/strong><\/p>\n Chiariamo il vocabolario: e qui che nascono i malintesi piu costosi. Il backup<\/strong> e una copia dei dati conservata in luogo separato, da cui ripristinare file, cartelle, database. Risponde a “ieri abbiamo perso una tabella per errore, possiamo recuperarla?”. Tempo di ripristino: ore. Granularita: alta. Costo: basso.<\/p>\n Il disaster recovery<\/strong> e un piano (e una infrastruttura) per riportare in produzione un sistema critico dopo un evento che ha reso indisponibile l’ambiente primario. Risponde a “il datacenter di Roma e off-line da un incendio, dobbiamo ripartire da Frankfurt entro 30 minuti”. Tempo di ripristino: minuti-ore. Granularita: applicazione\/sistema. Costo: medio-alto.<\/p>\n La high availability<\/strong> (HA) e una architettura che evita il downtime al primo posto: load balancer, cluster, repliche sincrone, failover automatico in secondi. Costo: alto. Una PMI puo (e spesso deve) avere tutti e tre, ma per servizi diversi: vetrina aziendale con backup giornaliero basta; gestionale di fatturazione richiede DR con RTO 1-2h; e-commerce a volume potrebbe meritare HA multi-AZ. Confondere i livelli porta a sovrainvestire dove non serve e sottoinvestire dove serve davvero.<\/p>\n Ogni discorso DR ruota intorno a due metriche. Il Recovery Point Objective (RPO)<\/strong> e la quantita massima di dati che siamo disposti a perdere, misurata in tempo. Un RPO di 1 ora significa che, nel peggiore degli scenari, perderemo al massimo l’ultima ora di transazioni. Lo determina la frequenza dei backup\/repliche. Il Recovery Time Objective (RTO)<\/strong> e il tempo massimo che possiamo permetterci di stare fermi. Lo determina l’architettura DR scelta.<\/p>\n Esempi concreti PMI italiana:<\/p>\n Mettere questi numeri nero su bianco, validati col business owner (non con l’IT da solo), e il primo passo concreto. Senza, qualsiasi conversazione con un vendor di DR diventa fuffa.<\/p>\n AWS ha formalizzato in white paper (2014, aggiornata 2021) quattro strategie DR che oggi sono lo standard de facto. Funzionano identiche su Azure e Google Cloud, e descrivono qualsiasi soluzione Veeam o Zerto.<\/p>\n 1. Backup & Restore (RTO 4-12 ore)<\/strong>. Dati e immagini su storage object (S3, Azure Blob). In caso di disastro, provisioning da zero nella region secondaria, restore dati, riavvio servizi. Pattern piu economico, il piu lento. Adatto a sistemi non critici, archivi, reporting. Costo PMI 30 VM: \u20ac80-200\/mese.<\/p>\n 2. Pilot Light (RTO 30-90 minuti)<\/strong>. Componenti core (database) replicate in continuo nella region secondaria, ma server applicativi spenti (o sostituiti da template\/AMI pronte). In caso di disastro si accendono le VM applicative, si fa puntare il DNS, si riparte. Database gia caldo, applicazione in 30 minuti. Costo PMI 30 VM: \u20ac400-800\/mese.<\/p>\n 3. Warm Standby (RTO 5-30 minuti)<\/strong>. Versione ridotta (scaled-down) dell’ambiente di produzione gira sempre nella region secondaria: VM accese ma piu piccole. In caso di disastro si scala su e si dirotta il DNS. Transizione in pochi minuti. Costo PMI 30 VM: \u20ac1.000-2.000\/mese.<\/p>\n 4. Multi-Site Active-Active (RTO <5 minuti)<\/strong>. Due (o piu) ambienti produttivi attivi in region diverse, dietro load balancer globale (Route 53, Traffic Manager). Se uno cade, l’altro assorbe il traffico trasparente. Non e piu DR ma HA geografica. Costo: 2x produzione, piu sincronizzazione cross-region.<\/p>\n Una PMI tipica adotta un mix: Backup&Restore per sistemi B\/C, Pilot Light per sistemi A. Solo mission-critical giustifica Warm Standby o Multi-Site.<\/p>\n A novembre 2021 AWS ha rilasciato in GA AWS Elastic Disaster Recovery (DRS)<\/strong>, successore di CloudEndure Disaster Recovery (acquisito 2019). La novita: per scenari AWS-to-AWS il vecchio CloudEndure era gratuito, ora DRS e managed con pricing semplificato. Per on-premise-to-AWS, DRS sostituisce CloudEndure con piena integrazione AWS Console e IAM nativi.<\/p>\n Come funziona: un agente leggero installato sulle VM sorgente (Windows o Linux, fisiche o virtuali) replica in continuo i block-level changes verso una staging area<\/em> in AWS, su istanze t3.small economiche. Replica lag tipico: pochi secondi. RPO effettivo: secondi-minuti. In caso di disastro DRS converte in pochi minuti le istanze di staging in EC2 di produzione, applicando rete, sicurezza e instance type definiti nel piano. RTO tipico: 5-20 minuti. Si possono lanciare drill non-disruptive in qualsiasi momento.<\/p>\n Pricing<\/strong> (us-east-1, riferimento marzo 2022): $0,028 per server-ora replicato (~\u20ac18\/server\/mese), piu storage EBS staging, piu data transfer cross-region. Scenario PMI: replica 20 VM da Milan (eu-south-1) verso Frankfurt (eu-central-1). Replica ~\u20ac360\/mese, storage staging 5 TB ~\u20ac450\/mese. Totale ~\u20ac800\/mese per RTO 15-30 minuti. Sweet spot: aziende gia su AWS o in migrazione, che vogliono copertura DR unificata. Debolezza: per ambienti puramente VMware on-prem vincono Zerto o Veeam.<\/p>\n ASR e in giro dal 2014 ed e la piattaforma DR managed piu matura dell’ecosistema Microsoft. Replica VM Hyper-V, VMware, fisici Windows\/Linux e Azure VM verso un Recovery Services Vault. Pattern simile a DRS: replica continua block-level, staging in storage Azure, failover\/failback in minuti.<\/p>\n Pricing<\/strong> (marzo 2022): $25 per istanza protetta al mese<\/strong> (~\u20ac22) piu storage Azure (LRS o GRS), networking e compute durante i failover. Il prezzo per istanza include licenze software Microsoft, fattore non trascurabile.<\/p>\n Per una PMI italiana il tema delicato e la region pair<\/strong>. Azure organizza i datacenter in coppie geograficamente correlate. La coppia europea storica e North Europe (Dublin)<\/strong> \u2194 West Europe (Amsterdam)<\/strong>. Italy North (Milano)<\/strong> e in preview\/imminente lancio, ma a marzo 2022 non e pienamente disponibile per workload produttivi con SLA. Soluzione tipica per tenere i dati in EU: produzione su West Europe (Amsterdam), DR su North Europe (Dublin). Per residenza Italia stretta, attendere Italy North GA o appoggiarsi a OVH\/Aruba per il primario e Azure per il DR.<\/p>\n Scenario PMI 30 VM su Azure West Europe con DR North Europe: $25 \u00d7 30 = $750\/mese (~\u20ac680) istanze protette, piu storage GRS staging (~\u20ac300-500 per 5 TB), piu egress. Totale 1.000-1.300 \u20ac\/mese per setup completo RTO 15-30 minuti. ASR si integra nativamente con Azure Backup, formando un pacchetto coerente: Backup per retention long-term e restore granulare, Site Recovery per failover applicativo.<\/p>\n Veeam resta il riferimento per ambienti VMware\/Hyper-V on-premise. v11<\/strong> (febbraio 2021) e v11a<\/strong> (luglio 2021) hanno consolidato tre capability cruciali: Continuous Data Protection (CDP)<\/strong> con RPO di secondi per VM VMware via stream log; backup immutabili<\/strong> via S3 Object Lock e Azure Blob Immutability (difesa numero uno contro ransomware che cancella i backup); Cloud Connect Replication<\/strong>, dove la PMI affida la repository DR a un VCSP italiano (Aruba, Welcome Italia, Reevo, Seeweb e altri). Costo VCSP per 30 VM: \u20ac1.200-2.500\/mese<\/strong> con RTO 30-60 minuti e datacenter in Italia.<\/p>\n Per scenari multi-applicazione, Veeam offre Disaster Recovery Orchestrator (VDRO)<\/strong>: motore di automation che codifica i runbook (sequenze di failover di gruppi VM con dipendenze), li testa periodicamente con report SLA, li esegue al disaster declaration. Trasforma un piano DR da PDF dimenticato in procedura ripetibile e auditabile.<\/p>\n Zerto<\/strong>, acquisita da HPE a luglio 2021 per 374M$, mantiene la sua nicchia: continuous data protection hypervisor-level con RPO < 30 secondi. La tecnologia journal-based consente non solo failover ma rollback puntuale a qualsiasi check-point degli ultimi 7-30 giorni (la “time machine” contro ransomware). Pricing per VM\/anno (\u20ac200-500), si adatta meglio a fasce medium-enterprise: per PMI 30 VM Zerto puo costare \u20ac8-15K\/anno solo licenze.<\/p>\n Per completezza, il mercato include anche Druva<\/strong> (cloud-native su AWS, backup endpoint, server, M365, Salesforce), Rubrik CDM<\/strong> (appliance policy-driven, mercato enterprise), Cohesity DataProtect<\/strong> (hyperconverged), Carbonite Server<\/strong> (OpenText, agente leggero), Datto SIRIS<\/strong> (via MSP, appliance + cloud), JetBackup<\/strong> (cPanel\/DirectAdmin) e stack OSS DIY<\/strong> (BorgBackup + Restic + Bacula\/Bareos) per chi ha competenze in casa e budget zero: funziona ma richiede ownership IT seria, senza un sysadmin dedicato e una trappola non una scorciatoia.<\/p>\n Dopo Schrems II (luglio 2020) della Corte di Giustizia UE, il trasferimento di dati personali verso gli USA non puo piu basarsi automaticamente sul Privacy Shield (invalidato). Le aziende che processano dati di cittadini UE devono dimostrare misure supplementari per garantire protezione equivalente al GDPR. Per il DR: tenere i dati nelle region EU<\/strong>, salvo eccezioni gestite con SCC e DPIA documentate.<\/p>\n Ogni hyperscaler ha region in Europa. AWS<\/strong>: Milano (eu-south-1, attiva da aprile 2020), Frankfurt, Ireland, Paris, Stockholm, London, Spagna (eu-south-2 in costruzione 2022). Azure<\/strong>: West Europe (Amsterdam), North Europe (Dublin), France Central, Germany West Central, Switzerland North, UK South. Italy North (Milano)<\/strong> in preview con GA imminente. Google Cloud<\/strong>: Milano (europe-west8, in preview), Frankfurt, London, Belgium, Netherlands, Finland, Warsaw, Zurich, Paris, Madrid. Pattern raccomandato per PMI italiana: primario Milano o Italia, DR Frankfurt o Amsterdam<\/strong>. Si copre il disaster geografico (alluvione, sisma, blackout) restando dentro UE per GDPR, soddisfando anche i requisiti settoriali piu stringenti (sanitario, finanziario, PA).<\/p>\n Un piano DR senza runbook documentato e un PDF morto. Il runbook<\/strong> e il documento step-by-step che dice, in italiano semplice, cosa deve fare ciascun ruolo nell’ordine corretto. Contiene: trigger e ownership<\/em> (chi dichiara il disaster e con quali criteri); roles & responsibility<\/em> (IT lead, communications, business owners, vendor escalation 24h); pre-flight check<\/em> (verifiche prima del failover); failover sequence<\/em> (ordine esatto: DNS, DB promotion, app restart, health-check); user communications<\/em> (messaggi pre-scritti per status page, email, social); verification matrix<\/em> (smoke test, API check, transazione end-to-end); failback plan<\/em> (come tornare al primario senza perdere i dati prodotti durante il DR). Un runbook reale per un gestionale occupa 10-30 pagine. Va versionato (Git, Confluence, SharePoint) e letto fisicamente<\/strong> dalle persone coinvolte: un runbook che il responsabile IT scopre alle 3 di notte durante l’attacco non e un runbook.<\/p>\n Statistica scomoda da Gartner e dall’esperienza sul campo: la maggior parte dei piani DR non viene mai testata<\/strong>, o viene testata in modo cosmetico (ping di una VM in DR, non un failover end-to-end). Al primo disastro reale scoprono che le credenziali sono cambiate, il DNS TTL e troppo lungo, un’integrazione esterna usa un IP whitelisted nel primario non nel secondario, il database in DR e in versione diversa, nessuno ricorda la password admin di emergenza, la VPN del fornitore non e replicata. Il DR drill<\/strong> e l’antidoto. Tre tipologie: tabletop exercise<\/strong> trimestrale (3-4 ore, identifica gap di processo), partial failover<\/strong> semestrale (una notte di lavoro, identifica gap tecnici), full DR test<\/strong> annuale (un weekend con business coinvolto, identifica gap di organizzazione e comunicazione). AWS DRS e ASR rendono i drill non-disruptive economici; Veeam VDRO ha sandbox testing. Non c’e piu nessuna scusa tecnica per non testare.<\/p>\n Il piano DR vive dentro un piano piu ampio di Incident Response<\/strong>. Quando arriva il ransomware, prima del failover bisogna capire: l’attaccante e ancora nella rete? Le credenziali AD sono compromesse? Se si “ripristina” il DR senza cleanup, l’attaccante segue il failover e cifra anche il secondario. Era lo scenario di Kaseya 2021: gli MSP con backup non infetti hanno potuto ripristinare; quelli con backup compromessi (perche l’attaccante era dentro da settimane) hanno scoperto il problema solo al restore.<\/p>\n Regola pratica: prima del failover per incidenti security, condurre una quick forensic<\/strong> per stabilire la data di compromissione iniziale e scegliere quale punto di restore usare (idealmente precedente alla compromissione). Aumenta l’RPO effettivo (si perdono giorni invece di minuti) ma evita di ripristinare un sistema gia compromesso. I piani DR moderni si scrivono di concerto con SOC interno o provider MDR (Managed Detection & Response) e includono un canale di escalation a IR firm (Mandiant, CrowdStrike Services, Kaspersky IR; in Italia Yoroi e Reply Communication Valley).<\/p>\n Dopo decine di audit DR su PMI, raccolgo i pattern fallimentari ricorrenti:<\/p>\n Per chiudere il cerchio normativo: il GDPR Art.32<\/strong> impone “misure tecniche e organizzative adeguate” citando esplicitamente “la capacita di ripristinare tempestivamente la disponibilita e l’accesso ai dati personali in caso di incidente fisico o tecnico”. Tradotto: il DR non e raccomandazione, e obbligo. Un’azienda colpita da ransomware senza piano DR documentato e testato e in violazione potenziale dell’art.32. L’Art.33<\/strong> impone notifica al Garante entro 72 ore<\/strong> dalla scoperta del breach: cosa e successo, quali dati coinvolti, quali mitigazioni. Tutto questo si decide al momento dell’incidente. Le sanzioni del GDPR (fino a 20M\u20ac o 4% fatturato globale) hanno reso questi articoli economicamente rilevanti.<\/p>\n Evoluzione che molti CFO non hanno ancora metabolizzato: nel corso del 2021 Lloyd’s of London<\/strong> ha annunciato che dal 2022 le polizze cyber dei suoi sindacati dovranno includere clausole esplicite di esclusione per “atti di guerra” e “operazioni di stato-nazione”. Effetto pratico: se un attacco viene attribuito a threat actor sponsorizzato da uno stato (come molti gruppi ransomware russi sono accusati di essere), la polizza puo non rispondere. Cambia drasticamente il calcolo costo\/beneficio: non si puo piu fare affidamento sulla cyber-insurance come unica strategia. Il DR self-managed (o managed con un provider serio) torna ad essere la vera mitigazione del rischio, non il piano B.<\/p>\n Costo medio per PMI italiana 30-50 dipendenti, ambiente misto (10-15 VM critiche, ERP, file server, posta su M365):<\/p>\n Roadmap 90 giorni<\/strong>: Settimane 1-2<\/em> business impact analysis (BIA), mappare applicazioni, definire RPO\/RTO, prioritizzare. Settimane 3-4<\/em> design architetturale, scegliere pattern (Backup&Restore, Pilot Light, Warm Standby) per ciascuna applicazione, selezionare tecnologia (AWS DRS, ASR, Veeam, Zerto), approvazione budget. Settimane 5-8<\/em> setup infrastruttura, provisioning region secondaria, installazione agenti, primo replica completa, validazione throughput e RPO. Settimane 9-10<\/em> stesura runbook applicativi, validazione con business owner, pre-scrittura comunicazioni. Settimane 11-12<\/em> primo drill non-disruptive (tabletop + partial failover), adjustments, onboarding del team, audit finale.<\/p>\n A 90 giorni una PMI ben organizzata ha un DR operativo, testato, documentato. A 180 giorni il primo full drill annuale convalida la maturita del processo.<\/p>\n Brentasoft progetta e gestisce piani Disaster Recovery cloud per PMI italiane, su AWS, Azure e infrastrutture Veeam managed. Region in Italia ed EU, runbook auditabili, drill trimestrali inclusi.<\/p>\n\n
Backup, Disaster Recovery e High Availability: tre cose diverse<\/h2>\n
RPO e RTO: i due numeri che decidono tutto<\/h2>\n
\n
I quattro pattern DR cloud<\/h2>\n
![\"Security](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/dr_inline1.jpg\")
<\/p>\nAWS Elastic Disaster Recovery (DRS)<\/h2>\n
Azure Site Recovery (ASR)<\/h2>\n
Veeam, Zerto e gli altri<\/h2>\n
![\"Diagramma](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/dr_inline2.jpg\")
<\/p>\nData residency: Italia, EU, Schrems II<\/h2>\n
Runbook e DR drill: dove falliscono l’80% dei piani<\/h2>\n
Integrazione con Incident Response<\/h2>\n
![\"Team](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/dr_inline3.jpg\")
<\/p>\nErrori comuni nelle PMI italiane<\/h2>\n
\n
GDPR, cyber-insurance, Lloyd’s: il contesto normativo<\/h2>\n
Budget tipico e roadmap 90 giorni<\/h2>\n
\n
Hai un’infrastruttura senza un piano DR testato?<\/h3>\n