| Livello (proposto) | Disponibilità | Modello | RPO / RTO |
|---|---|---|---|
| Standard | 99,7% | Multizona, database HA, backup isolati dalla rete | Zona: RPO ≈ 0. Regione: ripristino dal vault. |
| Live DR | 99,9% | Una seconda regione in esecuzione | RPO secondi, RTO ≤ 15 min |
| Live DR Premium | 99,95% | Traffico in entrambe le regioni, priorità 24 ore su 24, 7 giorni su 7 | RPO secondi, RTO ≤ 5 min |
Il tasso di non produzione è del 95%. La disponibilità viene misurata mensilmente all'ingresso TRANXACT, escludendo la finestra di manutenzione concordata (4 ore al mese previste).
Definisci il livello prima di dimensionarlo. Il ripristino di emergenza in tempo reale (Live DR) è una seconda regione a grandezza naturale e raddoppia approssimativamente i costi dell'infrastruttura in fase di esecuzione; mostralo come una riga a sé stante, in relazione ai costi di inattività che elimina.
Vivi, non essere passivo
Un sistema di standby passivo rimane inattivo, viene testato una volta all'anno, se non mai, e il failover avviene tramite ripristino e scalabilità. Il ripristino di emergenza attivo (Live DR) esegue un cluster a grandezza naturale e un database replicato in modo continuo che gestisce operazioni di lettura, reporting, richieste ASK e post sintetici per tutto il giorno. Il failover è una promozione: non viene ricostruito nulla e il suo stato di salute viene verificato ogni minuto.
| Test | impatto | Quante volte | Categoria |
|---|---|---|---|
| Verifica continua: registrazioni sintetiche, avvisi di ritardo, checksum del registro interregionale | Nessuno | Ogni minuto | Standard (TO_4.10.01) |
| Esercitazione di passaggio pianificato: metti in pausa le scritture, promuovi, sposta, verifica; scambia i ruoli | Scrittura interrotta per alcuni secondi | Trimestrale | Standard (TO_4.10.03) |
| Esercitazione di commutazione aggiuntiva | Scrittura interrotta per alcuni secondi | Su richiesta, con preavviso di 2 settimane. | Aggiuntivo (TO_4.10.04) |
| Trapano isolato: un clone recintato con integrazioni disabilitate | Nessuna informazione sulla produzione | Su richiesta, con preavviso di 2 settimane. | Aggiuntivo (TO_4.10.05) |
| Test di ripristino della camera bianca | Nessuna informazione sulla produzione | Annuale | Standard (TO_4.9.07) |
| Validazione aziendale dopo un'esercitazione | impegno del cliente | Ogni trapano | Escluso (TO_4.10.06) |
Backup
| DB di produzione | Database non di produzione | |
|---|---|---|
| Preso | Istantanea giornaliera + registri continui | Riepilogo giornaliero |
| Riprendersi per | In qualsiasi momento entro 30 giorni | L'ultima istantanea, 14 giorni fa |
| Copia di archivio | Giornaliero, immutabile, 90 giorni | Settimanale, immutabile, 30 giorni |
I documenti vengono versionati continuamente e copiati quotidianamente nel vault per la produzione. Anche l'infrastruttura come codice e la configurazione si trovano nel vault, quindi l'ambiente di runtime viene ricostruito dal codice anziché ripristinato.
Perché il caveau
La replica protegge dalle interruzioni, non dalla corruzione dei dati. Ransomware o dati corrotti vengono replicati sul server di standby e nella regione di disaster recovery in pochi secondi. Il vault è un account separato con identità e chiavi distinte, senza alcun collegamento di rete con l'ambiente di produzione, con conservazione dei dati "write-once" che nemmeno gli amministratori possono ridurre e cancellazione con doppia autorizzazione. I ripristini da questo vault vengono eseguiti in un ambiente isolato (scansione, riconciliazione, quindi promozione), mai direttamente sull'ambiente di produzione.
Una volta impostato, il periodo di blocco per la conservazione dei dati non può essere ridotto. Se necessario, è opportuno estenderlo fin da subito per esigenze di audit o legali, e dimensionare le copie a lungo termine in base alla crescita del registro e al volume dei documenti, non alle dimensioni attuali del database.
Calderwood ha scelto Live DR con una copertura del 99,9% in una seconda regione di Azure nella stessa giurisdizione. La prima esercitazione di failover e un ripristino in ambiente pulito sono programmati prima del go-live come fasi di verifica della prontezza. I partner bancari e di gestione delle buste paga sono inclusi nel piano di failover, in modo che i loro endpoint seguano il Traffic Manager.
Provalo Un'operazione batch corrompe 4.000 fatture di Calderwood alle 14:05. Live DR è integro, con un ritardo di 2 secondi. Il failover nella regione di DR risolve il problema?
No. La corruzione si è replicata sul server di standby e sulla regione di ripristino d'emergenza pochi secondi dopo che si è verificata: il failover ripristina gli stessi dati corrotti. La soluzione è un ripristino a un punto specifico nel tempo alle 14:04 (TO_4.9.05, Standard) oppure, se la cronologia stessa è sospetta, un ripristino completo dal vault (TO_4.9.06), con l'approvazione dei dati ripristinati da parte del responsabile finanziario (TO_4.9.11).