Disaster Recovery cloud per PMI 2022: AWS, Azure, Veeam — costi e roadmap

Il 2021 ha lasciato un bilancio pesante per chi gestisce IT in azienda. Conti e REvil hanno colpito ospedali, supply chain e infrastrutture critiche. Colonial Pipeline a maggio ha fermato il carburante della East Coast americana per giorni. Kaseya a luglio ha trascinato con se centinaia di MSP e migliaia di clienti finali. HSE in Irlanda ha pagato in caos sanitario per mesi. Poi a dicembre, come una coda velenosa, Log4Shell: una vulnerabilita Java pervasiva che ha messo in panico qualsiasi sysadmin con applicazioni in produzione durante il weekend natalizio.

In questo scenario dire ancora che il disaster recovery e qualcosa che si valuta “quando avremo tempo” significa non aver capito il momento storico. Per una PMI italiana, oggi, un fermo di 48 ore puo significare perdita definitiva di clienti, contratti, reputazione. La domanda non e piu “se” succedera un incidente, ma “quando” e “saremo pronti”.

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.

Backup, Disaster Recovery e High Availability: tre cose diverse

Chiariamo il vocabolario: e qui che nascono i malintesi piu costosi. Il backup 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.

Il disaster recovery 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.

La high availability (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.

RPO e RTO: i due numeri che decidono tutto

Ogni discorso DR ruota intorno a due metriche. Il Recovery Point Objective (RPO) 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) e il tempo massimo che possiamo permetterci di stare fermi. Lo determina l’architettura DR scelta.

Esempi concreti PMI italiana:

• Sito vetrina WordPress: RPO 24h, RTO 8-24h. Costo trascurabile.
• Email Exchange/M365: RPO 1h, RTO 2-4h. Tipicamente coperto dal provider con SLA.
• Gestionale ERP on-premise: RPO 1h, RTO 2-4h. Qui serve un vero piano DR.
• E-commerce alto volume: RPO 15min, RTO 30min. Servono repliche continue e infrastruttura warm standby.
• Sistema produttivo industriale (SCADA, MES): RPO ~0, RTO <5min. Qui parliamo di HA, non DR.

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.

I quattro pattern DR cloud

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.

1. Backup & Restore (RTO 4-12 ore). 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: €80-200/mese.

2. Pilot Light (RTO 30-90 minuti). 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: €400-800/mese.

3. Warm Standby (RTO 5-30 minuti). 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: €1.000-2.000/mese.

4. Multi-Site Active-Active (RTO <5 minuti). 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.

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.

AWS Elastic Disaster Recovery (DRS)

A novembre 2021 AWS ha rilasciato in GA AWS Elastic Disaster Recovery (DRS), 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.

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 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.

Pricing (us-east-1, riferimento marzo 2022): $0,028 per server-ora replicato (~€18/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 ~€360/mese, storage staging 5 TB ~€450/mese. Totale ~€800/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.

Azure Site Recovery (ASR)

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.

Pricing (marzo 2022): $25 per istanza protetta al mese (~€22) piu storage Azure (LRS o GRS), networking e compute durante i failover. Il prezzo per istanza include licenze software Microsoft, fattore non trascurabile.

Per una PMI italiana il tema delicato e la region pair. Azure organizza i datacenter in coppie geograficamente correlate. La coppia europea storica e North Europe (Dublin) ↔ West Europe (Amsterdam). Italy North (Milano) 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.

Scenario PMI 30 VM su Azure West Europe con DR North Europe: $25 × 30 = $750/mese (~€680) istanze protette, piu storage GRS staging (~€300-500 per 5 TB), piu egress. Totale 1.000-1.300 €/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.

Veeam, Zerto e gli altri

Veeam resta il riferimento per ambienti VMware/Hyper-V on-premise. v11 (febbraio 2021) e v11a (luglio 2021) hanno consolidato tre capability cruciali: Continuous Data Protection (CDP) con RPO di secondi per VM VMware via stream log; backup immutabili via S3 Object Lock e Azure Blob Immutability (difesa numero uno contro ransomware che cancella i backup); Cloud Connect Replication, dove la PMI affida la repository DR a un VCSP italiano (Aruba, Welcome Italia, Reevo, Seeweb e altri). Costo VCSP per 30 VM: €1.200-2.500/mese con RTO 30-60 minuti e datacenter in Italia.

Per scenari multi-applicazione, Veeam offre Disaster Recovery Orchestrator (VDRO): 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.

Zerto, 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 (€200-500), si adatta meglio a fasce medium-enterprise: per PMI 30 VM Zerto puo costare €8-15K/anno solo licenze.

Per completezza, il mercato include anche Druva (cloud-native su AWS, backup endpoint, server, M365, Salesforce), Rubrik CDM (appliance policy-driven, mercato enterprise), Cohesity DataProtect (hyperconverged), Carbonite Server (OpenText, agente leggero), Datto SIRIS (via MSP, appliance + cloud), JetBackup (cPanel/DirectAdmin) e stack OSS DIY (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.

Data residency: Italia, EU, Schrems II

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, salvo eccezioni gestite con SCC e DPIA documentate.

Ogni hyperscaler ha region in Europa. AWS: Milano (eu-south-1, attiva da aprile 2020), Frankfurt, Ireland, Paris, Stockholm, London, Spagna (eu-south-2 in costruzione 2022). Azure: West Europe (Amsterdam), North Europe (Dublin), France Central, Germany West Central, Switzerland North, UK South. Italy North (Milano) in preview con GA imminente. Google Cloud: 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. Si copre il disaster geografico (alluvione, sisma, blackout) restando dentro UE per GDPR, soddisfando anche i requisiti settoriali piu stringenti (sanitario, finanziario, PA).

Runbook e DR drill: dove falliscono l’80% dei piani

Un piano DR senza runbook documentato e un PDF morto. Il runbook e il documento step-by-step che dice, in italiano semplice, cosa deve fare ciascun ruolo nell’ordine corretto. Contiene: trigger e ownership (chi dichiara il disaster e con quali criteri); roles & responsibility (IT lead, communications, business owners, vendor escalation 24h); pre-flight check (verifiche prima del failover); failover sequence (ordine esatto: DNS, DB promotion, app restart, health-check); user communications (messaggi pre-scritti per status page, email, social); verification matrix (smoke test, API check, transazione end-to-end); failback plan (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 dalle persone coinvolte: un runbook che il responsabile IT scopre alle 3 di notte durante l’attacco non e un runbook.

Statistica scomoda da Gartner e dall’esperienza sul campo: la maggior parte dei piani DR non viene mai testata, 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 e l’antidoto. Tre tipologie: tabletop exercise trimestrale (3-4 ore, identifica gap di processo), partial failover semestrale (una notte di lavoro, identifica gap tecnici), full DR test 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.

Integrazione con Incident Response

Il piano DR vive dentro un piano piu ampio di Incident Response. 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.

Regola pratica: prima del failover per incidenti security, condurre una quick forensic 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).

Errori comuni nelle PMI italiane

Dopo decine di audit DR su PMI, raccolgo i pattern fallimentari ricorrenti:

1. “Abbiamo i backup, siamo a posto”: backup ≠ DR. Quanto ci mettete a ripartire? Se non avete fatto un test cronometrato, la risposta e “non lo sapete”.
2. Backup sullo stesso sito: il NAS Synology in armadio nella stessa stanza dei server. Ottimo per restore di file singoli, inutile contro incendio, alluvione, ransomware che cifra anche il NAS via SMB.
3. Backup non immutabili: Conti, REvil, BlackMatter cercano repository Veeam, account cloud con credenziali rubate, volumi storage e li cifrano prima di colpire produzione. Senza Object Lock o air-gapped tape, il backup non vi salva.
4. Nessun proprietario: senza un Disaster Recovery Manager nominato (anche part-time) il piano si fossilizza.
5. Documentazione fuori sincrono: l’IT manager che ha scritto il piano se ne e andato 18 mesi fa, l’infrastruttura nel frattempo e migrata su Azure.
6. Recovery worse than disaster: piani DR talmente complessi da produrre piu danni dell’incidente originale. Semplificare, semplificare, semplificare.
7. Niente test post-modifica: si aggiunge una applicazione, nessuno aggiorna il runbook DR. Il prossimo failover scopre la modifica nel modo peggiore.
8. SLA cloud confusi con SLA business: AWS e Azure garantiscono uptime infrastruttura, non uptime della vostra applicazione. Il loro 99,99% non e il vostro 99,99%.

GDPR, cyber-insurance, Lloyd’s: il contesto normativo

Per chiudere il cerchio normativo: il GDPR Art.32 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 impone notifica al Garante entro 72 ore 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€ o 4% fatturato globale) hanno reso questi articoli economicamente rilevanti.

Evoluzione che molti CFO non hanno ancora metabolizzato: nel corso del 2021 Lloyd’s of London 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.

Budget tipico e roadmap 90 giorni

Costo medio per PMI italiana 30-50 dipendenti, ambiente misto (10-15 VM critiche, ERP, file server, posta su M365):

• Assessment e progettazione: €3.000-7.000 una tantum (RPO/RTO per applicazione, design, runbook).
• Setup tecnico: €2.000-5.000 una tantum (configurazione cloud, installazione agenti, primo full replica, validazione).
• Run cost: €800-2.500/mese (replica storage, compute staging, licenze).
• Test annuali: €1.500-3.000/anno (tabletop trimestrale + partial semestrale + full annuale).
• Manutenzione runbook: 4-8 ore/mese di personale dedicato (interno o consulenza).

Roadmap 90 giorni: Settimane 1-2 business impact analysis (BIA), mappare applicazioni, definire RPO/RTO, prioritizzare. Settimane 3-4 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 setup infrastruttura, provisioning region secondaria, installazione agenti, primo replica completa, validazione throughput e RPO. Settimane 9-10 stesura runbook applicativi, validazione con business owner, pre-scrittura comunicazioni. Settimane 11-12 primo drill non-disruptive (tabletop + partial failover), adjustments, onboarding del team, audit finale.

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.

Conclusione

Il disaster recovery cloud non e una checkbox di compliance, e un’assicurazione operativa che si compra prima del bisogno. In un anno (il 2021) in cui ransomware ha colpito ospedali, oleodotti, MSP e governi, fingere che “a noi non capitera” e posizione difficile da difendere davanti al CdA. Le tecnologie sono mature: AWS Elastic Disaster Recovery, Azure Site Recovery, Veeam Backup & Replication v11a, Zerto coprono qualsiasi scenario PMI con pricing prevedibile. La domanda non e piu se investire in DR ma quale pattern adottare per quale applicazione, con quale RPO/RTO, e — soprattutto — quanto spesso testarlo. La risposta a quest’ultima domanda separa i piani DR efficaci dai PDF dimenticati nel cassetto.