Il livello di protezione adeguato dipende dal guasto che l’impresa deve sostenere. Il backup fornisce uno stato dei dati ripristinabile. L’alta disponibilità locale può assorbire il guasto di un host. Un secondo sito estende la protezione oltre il dominio di guasto originario, ma richiede capacità, reti e commutazioni provate. Nessuna soluzione sostituisce il collaudo funzionale dell’applicazione.
La verifica del ripristino e la differenza tra HA Proxmox e backup sono già argomenti autonomi. Qui decidiamo quale combinazione di backup, risorse sostitutive locali e operatività di emergenza geograficamente separata sia adatta a un servizio e a un dominio di guasto. Anche la panoramica delle piattaforme pubblica non sostituisce questa analisi applicativa.
Definire prima il processo e due obiettivi temporali
L’esempio, dichiaratamente fittizio, è un ERP con VM applicativa, database e file delle fatture. In caso di perdita dell’intero sito , il reparto vuole riprendere gli ordini entro quattro ore e perdere al massimo 15 minuti di dati aziendali coerenti. Sono obiettivi RTO e RPO, non un impegno DAXS né valori misurati. Per un singolo host si potrebbe prevedere un obiettivo più breve; una registrazione cancellata per errore richiede invece un punto di ripristino precedente e intatto.
La business impact analysis deve valutare separatamente guasto host, perdita del sito e dati danneggiati o cancellati. Il servizio torna operativo solo quando funzionano accesso, operazione sul database e allegato associato. Alimentazione, rete locale, DNS, identità, chiavi e interfacce esterne sono dipendenze. Se manca un elemento, l’avvio del server sostitutivo non basta a rendere utilizzabile il servizio.
Tre livelli di protezione con limiti diversi
| Livello | Che cosa può fare | Che cosa resta da risolvere |
|---|---|---|
| A · Backup e ripristino | Backup separati consentono di tornare a dati verificati; l’applicazione viene ripristinata quando è disponibile il sistema di destinazione. | Capacità sostitutiva, durata del ripristino e coerenza funzionale determinano l’RTO. Senza un sito di recupero pronto, la perdita della sede non permette una promessa attendibile di quattro ore. |
| B · Ridondanza locale e backup | Più host con storage, quorum e rete adeguati possono avviare la VM su altre risorse dopo un guasto host. | Alimentazione, compartimento antincendio o accesso al sito condivisi restano un dominio di guasto. Dati cancellati o corrotti possono replicarsi; il backup separato resta necessario. |
| C · Secondo sito e backup | Capacità di emergenza predisposta e geograficamente separata, con dati applicativi replicati, può coprire la perdita del sito se commutazione e processo sono stati provati. | Ritardo di replica, identità condivise, collegamenti, chiavi e failover errato possono far mancare l’obiettivo di 15 minuti/quattro ore. Anche qui occorrono backup separati. |
L’HA locale può quindi rispondere a un guasto host, ma non realizza automaticamente il disaster recovery dell’intero sito. Microsoft distingue espressamente ridondanza e replica dal backup: un errore o una cancellazione replicati restano tali. Le linee guida AWS descrivono backup/restore, pilot light, warm standby e modelli multisito attivi con impegno crescente. Questi schemi cloud sono un criterio decisionale, non valori RPO/RTO universali per l’ERP qui ipotizzato.
Perimetro equivalente: calcolo trasparente a tre e cinque anni
Ogni livello confronta lo stesso servizio ERP produttivo e la stessa base di backup separato. La piattaforma produttiva esistente è quindi esclusa da tutte le varianti. Runbook di backup e base di test richiedono inizialmente 24 ore-persona; ogni anno si ipotizzano 3.600 € di backup/storage esterno, 12 × 4 ore-persona di gestione e due prove di ripristino da 16 ore-persona ciascuna. Il costo pieno liberamente assunto è 80 € per ora-persona: 1.920 € iniziali e, ogni anno, 3.600 + (48 + 32) × 80 = 10.000 €. Non sono prezzi di fornitori.
Il livello B aggiunge inizialmente 60 ore-persona per progetto e collaudo di host/storage/rete, poi ogni anno 7.800 € esemplificativi di capacità locale aggiuntiva, energia e supporto inclusi, 12 × 4 ore di gestione ulteriori e due prove HA da otto ore-persona aggiuntive. Il livello C aggiunge invece 96 ore-persona iniziali per siti, dati e commutazione e, ogni anno, 18.000 € di capacità di emergenza e rete predisposte, 3.600 € di trasferimento dati, 12 × 8 ore di gestione ulteriori e due prove di sito da 24 ore-persona aggiuntive. Le ore delle esercitazioni sono totali di squadra; la base comune di backup conta una sola volta per variante.
| Livello | Una tantum | Annuale | 3 anni | 5 anni |
|---|---|---|---|---|
| A · Backup/ripristino | 24 × 80 = 1.920 € | 10.000 € di base | 31.920 € | 51.920 € |
| B · Ridondanza locale | 1.920 + 60 × 80 = 6.720 € | 10.000 + 7.800 + 3.840 + 1.280 = 22.920 € | 75.480 € | 121.320 € |
| C · Secondo sito | 1.920 + 96 × 80 = 9.600 € | 10.000 + 18.000 + 3.600 + 7.680 + 3.840 = 43.120 € | 138.960 € | 225.200 € |
Sensibilità: Se la capacità predisposta del secondo sito costa 500 € al mese in più, il livello C aumenta di 6.000 € annui: 156.960 € su tre anni o 255.200 € su cinque. Prima dell’acquisto vanno aggiunti ricambi, imposte, offerte reali di linee e siti, diritti di licenza, gestione oltre le ore ipotizzate e costi di un guasto reale. Nessuna variante promette risparmi o una ripartenza garantita.
Decidere attraverso la prova
Per l’obiettivo ipotizzato di quattro ore/15 minuti in caso di perdita del sito , A e B non bastano da sole finché non esiste un’altra sede utilizzabile con dati, identità e accesso alla rete. C è soltanto una candidata: il gruppo deve misurare replica, coerenza database/file, accessi, decisione di commutazione, capacità sotto carico e ritorno durante una vera finestra di test. Se il reparto accetta un’emergenza più lunga con ordini manuali, può bastare una soluzione meno costosa. La scelta va deliberata, documentata e provata.
DAXS può rilevare servizio e dipendenze, definire l’operatività minima utile al reparto e confrontare le tre varianti con offerte reali e risultati di restore/failover. Contatta DAXS.
Fonti: Microsoft Learn: ridondanza, replica e backup · AWS Well-Architected: strategie di disaster recovery · Proxmox VE: funzioni HA e backup.
