DR geografico per clienti con infrastruttura on-premise. Architettura tipica: sito primario presso il cliente + site secondario in uno dei nostri data center italiani (Tier III). Proxmox Backup Server come motore: backup incrementale deduplicato a blocchi, retention granulare, ripristino file-level e VM-level. RPO tipico 15 minuti, RTO tipico 1-4 ore. Test di failover reale annuale (non sulla carta). Per l'hardware del sito cliente ci appoggiamo al partner Adenda S.r.l. così non vi leghiamo a un singolo fornitore.
01Cos'è davvero il DR geografico (e cosa non è il backup)
Confusione ricorrente: "facciamo i backup ogni notte, quindi siamo coperti". No. Il backup è una copia dei dati su un supporto secondario. Il DR è la capacità operativa di tornare produttivi in tempi definiti quando il sito primario è inagibile. Sono due cose collegate ma distinte, e chi le confonde scopre la differenza nel peggior momento possibile.
Un backup risponde a: "ho perso un file, me lo riprendo". Un DR risponde a: "la sede è allagata / il ransomware ha cifrato tutto / il rack è bruciato — dove ripartiamo domani mattina?". I rischi coperti dal DR geografico sono tre categorie reali: ransomware con propagazione sull'intero storage (scenario ormai settimanale per le PMI italiane), failure hardware totale (doppia rottura dischi, controller che si porta via il raid, incendio del rack), disastro fisico della sede (allagamento, incendio, furto con asporto server).
Se il secondo sito è nello stesso edificio del primo, non è DR geografico. Se non è testato, non è DR — è speranza.
02Architettura tipica cliente + DC
Lo schema che replichiamo con varianti minori per la maggior parte dei clienti: al sito primario, presso il cliente, vive il cluster di produzione — tipicamente 2-3 nodi Proxmox con storage locale ZFS o Ceph, più un Proxmox Backup Server locale che gestisce i backup short-term (retention 14-30 giorni, ripristino veloce dalla LAN).
Il sito secondario è uno dei nostri data center italiani: cluster Proxmox passivo dimensionato per accogliere il carico produttivo del cliente in failover, secondo PBS che riceve i backup incrementali tramite sync job, collegato al cliente via VPN IPsec site-to-site o WireGuard su circuiti dedicati quando la banda lo richiede. La replicazione è continua sui dataset critici (snapshot ZFS ogni 15 minuti) e giornaliera sul resto.
In caso di disastro, il DC diventa attivo: le VM partono dagli ultimi backup/snapshot disponibili, il traffico viene rerouted via DNS e/o BGP, la produzione riparte mentre si pianifica il ripristino del sito primario.
03Lo stack operativo
Niente magia, niente prodotti proprietari oscuri. Lo stack è composto da pezzi che leggiamo, capiamo e controlliamo:
- Proxmox Backup Server: motore di backup con deduplicazione a blocchi a livello di chunk, retention pinning granulare (keep-last, keep-daily, keep-weekly, keep-monthly), verifica periodica dell'integrità dei chunk, supporto remote sync con bandwidth limiting.
- ZFS snapshots + send/receive: per repliche incrementali efficienti dei dataset, granularità fino a minuti, compressione e cifratura nativa.
- Ceph: dove serve storage distribuito con replica cross-site, configurato con crush map che separa failure domain per datacenter.
- Reti: IPsec per tunnel site-to-site enterprise, WireGuard dove serve bassa latenza e gestione semplice. Monitoraggio attivo del link con alerting se il ritardo di replica supera le soglie contrattuali.
- Monitoring: Prometheus + Grafana con alert su lag di replica, fallimento job, esaurimento spazio PBS, fallimento verify.
04Come definiamo RPO e RTO nel contratto
Due numeri che cambiano tutto e che vanno scritti nero su bianco, non sottintesi.
RPO (Recovery Point Objective) — quanti dati potete perdere. Tradotto: qual è l'intervallo massimo tra l'ultimo backup valido e il disastro. Il nostro RPO tipico è 15 minuti sui dataset critici (database produttivi, file server operativi), 1-4 ore sul resto. L'RPO è limitato principalmente dalla bandwidth disponibile tra sito cliente e DC e dalla frequenza degli snapshot. Un RPO aggressivo su dataset grossi richiede circuiti dedicati — se l'upload è una FTTC domestica, il contratto racconterà una bugia.
RTO (Recovery Time Objective) — quanto tempo resta ferma la produzione. Dalla dichiarazione di disastro alla ripartenza operativa al DC. Il nostro RTO tipico è 1-4 ore a seconda del contratto. L'RTO è influenzato da: dimensione del dataset (restore di 50 TB è fisicamente diverso da 500 GB), complessità dell'applicativo (DB con vincoli di consistency, app distribuite con interdipendenze), livello di automazione del runbook. Il contratto specifica RTO distinti per classi di VM: produzione critical prima, sistemi di contorno dopo.
Diffidate di chi vi promette RPO 0 e RTO "pochi minuti" a prezzo ragionevole. O ha frainteso il problema o sta vendendo fumo.
05Backup vs DR — confronto operativo
Perché si continua a chiamarli uguali e non lo sono.
| Dimensione | Backup tradizionale | DR geografico |
|---|---|---|
| Obiettivo | Recupero dati | Continuità operativa |
| Localizzazione | Spesso stesso sito | Site secondario geograficamente separato |
| RPO | Ore o giorni | Minuti |
| RTO | Giorni | Ore |
| Ambiente di restore | Deve essere ricostruito | Già pronto e dimensionato |
| Test | Raro, spesso solo verifica integrità | Failover reale annuale |
| Protezione ransomware | Solo se air-gap o immutabilità | Copia fuori rete primaria + retention |
| Costo | Basso | Maggiore, ma proporzionato al downtime evitato |
Il DR include il backup — non lo sostituisce. Il cliente tipico ha entrambi: backup locale per restore rapido di singoli file/VM, DR geografico per lo scenario peggiore.
06Il test di failover annuale
Il DR non testato è una slide PowerPoint. Per questo ogni contratto DR include un test di failover reale una volta l'anno, non simulato sulla carta.
Il processo: finestra programmata con il cliente (tipicamente weekend o orario notturno a basso impatto), dichiarazione formale di "disaster simulato", attivazione del DC secondario, spegnimento controllato dell'infrastruttura primaria, reindirizzamento del traffico, verifica funzionale con checklist predefinita (login applicativi, transazioni di prova sui DB, flussi verso sistemi esterni), permanenza in produzione al DC per una finestra definita, rollback controllato al sito primario, sincronizzazione dei dati prodotti durante il test.
Al cliente consegniamo un report di test: RTO effettivo misurato, RPO effettivo misurato, anomalie rilevate, azioni correttive, aggiornamento al runbook. Se l'RTO misurato supera quello contrattuale, lo diciamo — e lavoriamo sulla causa (in genere: un'applicazione poco documentata, un'interdipendenza emersa solo sotto stress).
07Partnership con Adenda S.r.l. per l'hardware
Noi facciamo sistemistica, non siamo un rivenditore hardware. Per il lato ferro del sito primario del cliente ci appoggiamo al partner Adenda S.r.l.: dimensionamento server, procurement, consegna, assistenza hardware on-site. Questo significa che il cliente non è legato a noi per l'hardware — se un giorno volesse cambiare gestore del DR, l'infrastruttura fisica è di sua proprietà, contratto chiaro con Adenda, nessun lock-in.
Il principio è generale: chi vi vende il DR non deve essere l'unico a potervi toccare l'infrastruttura. È una forma di protezione per il cliente, non per noi.
08Un esempio reale
PMI manifatturiera piemontese, ~80 dipendenti, ERP gestionale + file server progettazione + server dipartimentali. Infrastruttura: cluster Proxmox 3-node on-prem, ~18 VM, ~12 TB dati totali. Contratto DR con replica sul nostro DC di Milano, RPO 15 min / RTO 2h.
Venerdì ore 23:40: ransomware lanciato da una postazione compromessa via RDP esposto (ereditato da un fornitore terzo). Encryption in corso su share SMB e dischi VM. Primo ack dal monitoring: ore 23:52 — alert su tasso anomalo di write su dataset ZFS. Chiamata di reperibilità: 00:04 sabato. Isolamento: 00:20 — cluster primario scollegato dalla rete, propagazione bloccata. Decisione failover: 02:30 sabato, dopo triage — dati irrecuperabili sul primario senza passare da ripulitura profonda.
Attivazione DC: VM ripartite dagli snapshot PBS pre-incident (ultimo snapshot valido ore 23:30 venerdì, RPO effettivo ~10 min). Servizi core (ERP, file server) operativi alle 06:00 sabato. Reindirizzamento traffico via DNS e VPN client puntata al DC. Domenica mattina: produzione di lunedì verificata in anteprima al DC, go/no-go confermato. Lunedì ore 07:00: gli operai timbrano come sempre, l'ERP risponde, i file di commessa ci sono. Ripristino primario: reinstallazione pulita dei 3 nodi, re-sync dal DC, rientro pianificato il weekend successivo con finestra programmata.
Costo del downtime evitato: incalcolabile con precisione, ordine di grandezza del canone DR annuale pagato per anni.
09Costi tipici
Ordini di grandezza realistici, canone mensile comprensivo di storage al DC, motore di backup, gestione, monitoring, runbook, test annuale. Non include l'hardware del sito primario (gestito via Adenda) né la banda dedicata verso il DC se richiesta.
- Cluster piccolo (3-5 VM, fino a ~2 TB dati): fascia ~350-700 €/mese. Adatto a studi professionali, piccole aziende di servizi.
- Cluster medio (15-30 VM, ~5-15 TB dati): fascia ~900-2.000 €/mese. Tipico PMI manifatturiere, aziende con gestionale + file server + server dipartimentali.
- Cluster grande (50+ VM, 20+ TB dati): fascia da ~2.500 €/mese in su, quotato su specifica. Entrano in gioco circuiti dedicati, cluster DC dimensionati su misura, RTO stretti per classi specifiche.
La voce principale che fa scalare il costo non è il numero di VM — è il volume dati (storage al DC) e la bandwidth necessaria per tenere l'RPO contrattuale. Il conto si fa a numeri, non a listini standard.