In un mondo sempre più digitale, le aziende dipendono dai propri servizi online come mai prima d'ora. Quando questi servizi si interrompono, le ripercussioni sul business possono essere serie. È qui che entra in gioco il Disaster Recovery su AWS: un insieme di pratiche per prepararsi e ripartire dopo eventi che colpiscono l'infrastruttura IT e i dati. AWS (Amazon Web Services) mette a disposizione un framework solido e flessibile per pianificare il disaster recovery, permettendo alle aziende di ridurre i tempi di inattività e di rimettersi in moto più rapidamente quando accade l'imprevisto.
Cosa si intende per "disastro" nel Disaster Recovery
Per "disastro", nel contesto del disaster recovery, si intende qualsiasi evento che comprometta gravemente l'operatività aziendale. Si va dalle calamità naturali, come alluvioni o terremoti, agli attacchi informatici, ai blackout, fino agli errori umani che provocano perdita di dati o interruzioni dei sistemi. La pianificazione del disaster recovery serve proprio ad anticipare questi eventi, per quanto imprevedibili, e a predisporre piani capaci di limitarne al minimo l'impatto sul business.
Il modello di responsabilità condivisa di AWS
Quando si pianifica il disaster recovery è fondamentale conoscere a fondo lo Shared Responsibility Model di AWS. AWS opera secondo questo modello, in base al quale le responsabilità per un ambiente sicuro e conforme sono ripartite tra AWS e cliente.
AWS è responsabile della sicurezza "del" cloud: sicurezza fisica dei data center, infrastruttura globale, hardware e rete. I clienti, invece, sono responsabili della sicurezza "nel" cloud, ossia della protezione di dati, applicazioni, sistemi operativi e Identity and Access Management. In sintesi: AWS fornisce una base sicura sulla quale i clienti possono costruire ed eseguire i propri workloads, aggiungendo un ulteriore livello di sicurezza.
High Availability e Disaster Recovery a confronto
High availability e disaster recovery sono due pilastri di una strategia IT completa. Possono sembrare simili, ma rispondono a esigenze diverse.
L'high availability mira a mantenere un livello di servizio accettabile durante l'operatività ordinaria. Significa progettare i sistemi in modo che restino accessibili anche in caso di guasto di singoli componenti. Si pensi, ad esempio, a un sito di e-commerce: se è configurato in alta disponibilità, anche quando un'istanza si blocca il sito continua a funzionare regolarmente, perché il carico viene distribuito sulle altre istanze disponibili.
Il disaster recovery, invece, riguarda il ripristino dei servizi dopo un evento fortemente disruptive. Significa avere un piano per recuperare dati, applicazioni e infrastrutture critiche in seguito a un disastro. Per fare un esempio: se quello stesso sito di e-commerce subisse un grave attacco informatico con conseguente perdita massiva di dati e blocco del servizio, sarebbe il piano di disaster recovery a guidare il recupero dei dati e il ripristino delle funzionalità del sito.
Disaster Recovery e Business Continuity: due approcci a confronto
Disaster recovery e business continuity sono strettamente collegati, ma si concentrano su aspetti differenti della gestione delle crisi.
Il disaster recovery è un sottoinsieme della business continuity. Si focalizza sui processi tecnici necessari a ripristinare sistemi, applicazioni e dati dopo un disastro. Riprendendo l'esempio precedente, dopo l'attacco informatico il processo di disaster recovery comprenderebbe le azioni necessarie per rimettere online il sito di e-commerce, sanare le vulnerabilità di sicurezza e ripristinare la piena operatività.
La business continuity, invece, è un approccio complessivo volto a garantire il funzionamento ininterrotto delle funzioni aziendali essenziali durante e dopo un disastro. Mentre il disaster recovery si concentra principalmente sui sistemi IT e sul recupero dei dati, la business continuity allarga lo sguardo. Tornando all'esempio del sito di e-commerce, garantire la continuità operativa potrebbe significare potenziare la capacità del call center per far fronte all'aumento delle richieste, attivare procedure di vendita temporanee e comunicare in modo proattivo ai clienti la situazione e i tempi previsti per la risoluzione. Riguarda tutti gli ambiti aziendali che un disastro potrebbe colpire, non solo l'IT.
Strategie di Disaster Recovery
Per pianificare il disaster recovery in AWS si possono scegliere diverse opzioni, in base alle esigenze specifiche dei propri workloads. Ecco quattro strategie chiave:
- Backup and Restore: è uno degli approcci tradizionali al disaster recovery. Prevede l'esecuzione di backup regolari sul cloud e, in caso di disastro, il loro utilizzo per ripristinare dati e applicazioni perduti. Si tratta di una strategia semplice ed economica, perché si pagano solo le risorse di storage occupate dai backup. Il rovescio della medaglia è il tempo di ripristino, che può essere lungo a seconda delle dimensioni dei dati e delle applicazioni da recuperare. È la soluzione più adatta per applicazioni non critiche, dove tempi di ripristino più lunghi sono accettabili.
- Pilot Light: in questo approccio una versione minima dell'ambiente è sempre attiva sul cloud. Questo "Pilot Light" comprende gli elementi essenziali per mantenere il sistema in funzione, come il database e l'application server. In caso di disastro, attorno a questo nucleo vengono rapidamente provisionate le risorse necessarie a ripristinare l'intero sistema. Il tempo di ripristino è più breve rispetto al metodo Backup and Restore, perché richiede solo lo scaling di servizi già attivi. È però più costoso, perché impone di mantenere costantemente attiva una versione minima dell'ambiente. La strategia Pilot Light è indicata per le applicazioni critiche in cui contano tempi di ripristino brevi.
- Warm Standby: in questo approccio una versione ridotta di un ambiente pienamente funzionale è sempre attiva sul cloud. Questo ambiente, detto standby, rispecchia quello di produzione ed è pronto a subentrare in caso di disastro. In tale stato è in grado di scalare rapidamente per gestire il carico di produzione quando serve. La strategia Warm Standby offre un tempo di ripristino più breve rispetto a Backup and Restore e Pilot Light, perché basta scalare il sistema per gestire l'intero workload. Comporta però costi maggiori, dovuti alla necessità di mantenere costantemente attivo l'ambiente di standby.
- Multi-Site: prevede l'esecuzione simultanea di applicazioni e servizi in più siti, in genere in regioni geografiche differenti. Con questa strategia tutti i siti sono attivi e si dividono il carico durante il normale funzionamento. Se un sito si guasta, gli altri continuano a operare, garantendo la continuità del servizio. Il vantaggio principale del Multi-Site è offrire il tempo di ripristino più breve fra tutte le strategie di DR, grazie alla sua natura active-active. È però anche la più costosa, perché impone di mantenere più ambienti pienamente funzionanti. Si utilizza tipicamente per applicazioni mission-critical, in cui alta disponibilità e azzeramento dei tempi di inattività sono prioritari.
Ognuna di queste strategie ha vantaggi specifici e la scelta dipende dai requisiti del proprio workload. Due fattori critici in questo processo decisionale sono il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO).
L'RPO indica la quantità massima accettabile di perdita di dati misurata in tempo. Se un sistema ha un RPO di 60 minuti, ad esempio, le sue configurazioni e i suoi dati devono essere salvati in modo tale che, in caso di guasto, non si perdano più di 60 minuti di dati.
L'RTO, invece, è l'arco di tempo entro cui un processo aziendale deve essere ripristinato dopo un disastro per evitare conseguenze inaccettabili legate all'interruzione della continuità operativa. Se l'RTO è di 120 minuti, ad esempio, sistemi e applicazioni dovrebbero tornare operativi entro 120 minuti da un'interruzione.
La distinzione tra RPO e RTO è essenziale: l'RPO riguarda i dati e la perdita massima tollerabile, l'RTO il tempo necessario a rimettere in funzione il sistema.
Ecco una panoramica di come RPO e RTO si rapportano alle quattro strategie di disaster recovery descritte in precedenza:
- Backup and Restore:
- RTO: in caso di disastro, l'RTO della strategia Backup and Restore dipende dal tempo necessario per ripristinare i backup. Può variare in base a fattori quali la dimensione del backup, la velocità dello storage e la complessità del processo di ripristino. In genere va da alcune ore ad alcuni giorni.
- RPO: l'RPO per Backup and Restore è determinato dall'intervallo di tempo tra un backup e l'altro. Se i backup vengono eseguiti a cadenza regolare, l'RPO corrisponde alla durata che intercorre tra l'ultimo backup riuscito e il momento del disastro.
2. Pilot Light:
- RTO: la strategia Pilot Light mira a ridurre al minimo i tempi di inattività mantenendo già attiva nel cloud una versione minima dell'ambiente. L'RTO può essere relativamente breve, da pochi minuti ad alcune ore, a seconda del tempo necessario per scalare l'ambiente.
- RPO: l'RPO per la strategia Pilot Light dipende dalla frequenza di replica dei dati dall'ambiente principale alla versione minima nel cloud. Può variare, ma in genere si misura in minuti o ore.
3. Warm Standby:
- RTO: con una soluzione Warm Standby l'RTO è più breve rispetto al Pilot Light, dato che i sistemi sono già in esecuzione. In genere va da pochi minuti ad alcune ore, a seconda dei processi di scaling e sincronizzazione necessari.
- RPO: l'RPO per Warm Standby è determinato dalla frequenza di replica o sincronizzazione dei dati tra l'ambiente principale e quello di standby nel cloud. Come per il Pilot Light, l'RPO si misura tipicamente in minuti o ore.
4. Multi-Site:
- RTO: la strategia Multi-Site punta ad alta disponibilità e failover rapido eseguendo i workloads in parallelo in più siti o regioni AWS. L'RTO può essere molto breve, spesso misurabile in secondi o minuti, perché in caso di disastro il traffico viene rapidamente reindirizzato verso il sito alternativo.
- RPO: l'RPO per il Multi-Site dipende dal meccanismo di replica dei dati utilizzato tra i siti o le regioni. Con replica sincrona l'RPO può essere prossimo allo zero, con perdita di dati minima. La replica asincrona può introdurre un leggero ritardo, con un RPO che varia da secondi a minuti.
La scelta della strategia di disaster recovery dovrebbe essere allineata ai propri obiettivi di RPO e RTO, trovando il giusto equilibrio tra costo, complessità e requisiti di ripristino. Una strategia che riduce al minimo perdita di dati (RPO basso) e tempi di ripristino (RTO basso) può essere più complessa e costosa, ma diventa essenziale per workloads in cui downtime e perdita di dati hanno un impatto significativo sul business. Per workloads non critici, invece, può andare bene una strategia più semplice ed economica con RPO e RTO più elevati.
I principali servizi AWS per il Disaster Recovery
AWS offre una suite di servizi che è possibile sfruttare per un disaster recovery efficiente ed efficace. Eccone alcuni tra i più rilevanti:
AWS Elastic Disaster Recovery: è la soluzione pensata per garantire la resilienza dell'infrastruttura. Offre il ripristino automatizzato da diversi tipi di incidenti, come guasti dell'infrastruttura o delle applicazioni. Sfruttando la replica continua dei dati a livello di blocco, raggiunge RPO nell'ordine dei secondi. In più, replica i dati in modo continuo verso un'area di staging economica all'interno dell'ambiente AWS, riducendo in modo efficace il consumo di risorse. Grazie alla conversione automatica delle macchine e all'orchestrazione, può abbassare l'RTO a pochi minuti.
AWS Backup: AWS Backup è un servizio centralizzato che semplifica e automatizza il processo di backup su diversi servizi AWS, tra cui EBS, RDS, DynamoDB, EFS e AWS Storage Gateway. Questa integrazione riduce la complessità operativa e garantisce backup coerenti, contribuendo in modo significativo a una solida strategia di disaster recovery. Il servizio consente inoltre di creare piani di backup con policy che ne definiscono frequenza e periodo di conservazione, automatizzando ulteriormente il processo e riducendo il rischio di perdita di dati. AWS Backup gioca un ruolo cruciale nel raggiungere gli obiettivi di RPO e RTO: pianificando backup regolari è possibile ridurre al minimo la quantità di dati persi accettabile (RPO) e, grazie alla funzionalità di restore di AWS Backup, accorciare il tempo di recupero dopo un evento di perdita dati (RTO).
Amazon S3 Cross-Region Replication: questa funzionalità copia in modo automatico e asincrono gli oggetti tra bucket situati in regioni AWS differenti. In uno scenario di disaster recovery, il compito principale della Cross-Region Replication (CRR) è garantire che i dati restino disponibili e durevoli anche in caso di guasti regionali. L'obiettivo si raggiunge mantenendo un backup completamente replicato dei dati in una località geografica separata, non interessata dai disastri che colpiscono la sede originale.
Amazon RDS: consente di configurare, gestire e scalare con facilità un database relazionale nel cloud. RDS offre backup automatizzati, snapshot del database, read replica cross-region e, per alcuni tipi di database, anche funzionalità di DR, sfruttabili per il disaster recovery per garantire un rapido ripristino del database dopo un disastro.
Amazon Route 53: in ottica disaster recovery, una caratteristica chiave di Route 53 è il service level agreement (SLA) di disponibilità del 100%. Questa garanzia assicura che il servizio sia sempre operativo e fornisca un routing affidabile verso l'infrastruttura dell'applicazione. Le funzionalità di health check e failover DNS di Route 53 sono determinanti ai fini del DR. Il servizio monitora di continuo lo stato dell'applicazione e dei suoi componenti tramite health check. Se viene rilevato un guasto o un'anomalia in una particolare regione AWS, Route 53 reindirizza automaticamente il traffico verso le risorse in salute in un'altra regione. Questa capacità di failover a livello di DNS fa sì che, anche in caso di blocco di un'intera regione, l'applicazione resti disponibile per gli utenti. Permettendo un rilevamento e una risposta rapidi ai guasti, gli health check e il failover DNS di Route 53 contribuiscono a una solida strategia di disaster recovery, riducendo i tempi di inattività e mantenendo elevata la disponibilità dell'applicazione.
AWS Glacier: è un servizio di storage a basso costo per l'archiviazione dei dati. Per il disaster recovery, Glacier rappresenta una soluzione economica per conservare i backup di dati ad accesso poco frequente. In caso di disastro, è possibile recuperare questi dati, anche se con tempi superiori rispetto ad Amazon S3.
AWS CloudFormation: consente il provisioning e la gestione automatizzati delle risorse nell'ambiente cloud AWS. Permette di definire e distribuire l'infrastruttura come codice (IaC) tramite template CloudFormation. In una situazione di disaster recovery, i template possono essere utilizzati per ricreare rapidamente l'infrastruttura in un'altra regione, accelerando i tempi di ripristino e garantendo coerenza tra gli ambienti. Va sottolineato che questi template dovrebbero essere disponibili anche nella regione di disaster recovery, attraverso S3 Cross-Region Replication, per essere accessibili al momento del bisogno.
Combinando in una strategia di disaster recovery i servizi chiave appena descritti, le aziende possono dotarsi di meccanismi solidi, scalabili e ottimizzati per recuperare dati e applicazioni critici in caso di disastro.
Test proattivi di Disaster Recovery
Netflix ha introdotto Chaos Monkey, uno strumento di resilience testing, all'inizio degli anni 2010, nell'ambito della propria migrazione al cloud. Terminando in modo casuale istanze e servizi, Chaos Monkey simula potenziali guasti e fornisce informazioni preziose sulle reazioni del sistema durante interruzioni critiche. Questo approccio ha portato allo sviluppo della Chaos Engineering, una disciplina dedicata a individuare e correggere in modo proattivo i guasti di sistema per prevenire interruzioni del servizio. Chaos Monkey, insieme alla Chaos Engineering, gioca un ruolo cruciale nel disaster recovery, perché consente alle organizzazioni di valutare reazioni del sistema e processi di ripristino. Testando in modo controllato gli scenari di guasto è possibile individuare punti deboli o lacune nei piani di disaster recovery e apportare le correzioni necessarie. Pur introducendo una certa complessità iniziale, questo approccio aumenta il livello di preparazione, perché aiuta a comprendere le vulnerabilità del sistema e a costruire architetture più solide.
Un altro strumento, AWS Fault Injection Simulator (FIS), migliora la resilienza delle applicazioni grazie a esperimenti di iniezione di guasti controllati sulle risorse AWS. Generando interruzioni come blocchi di server o throttling delle API e osservando le risposte del sistema, FIS fornisce indicazioni utili sulle potenziali vulnerabilità. Nel contesto del disaster recovery, FIS aiuta a individuare i punti deboli nella resilienza del sistema, permettendo agli sviluppatori di intervenire in modo proattivo prima che generino interruzioni del servizio. Tramite esperimenti di iniezione di guasti che simulano potenziali disastri, i team possono valutare e migliorare le procedure di ripristino in condizioni controllate. Il risultato sono piani di disaster recovery più robusti e una migliore resilienza complessiva, con una minore probabilità di interruzioni del servizio in scenari di disastro reali.
Ottimizzare il Disaster Recovery con l'esperienza di DoiT
Sul fronte del disaster recovery, DoiT offre servizi di pianificazione e consulenza. Il nostro team di cloud architect esperti può aiutarLa a costruire un solido piano di disaster recovery, su misura per le specifiche esigenze della Sua azienda. Grazie alla nostra profonda conoscenza dei servizi e dell'infrastruttura AWS, possiamo consigliarLe best practice, procedure di ripristino e configurazioni ottimali per rafforzare la resilienza dei Suoi workloads.
Pianificare il disaster recovery va ben oltre la semplice configurazione di un sistema di backup. Richiede un'analisi approfondita dell'operatività aziendale, l'identificazione dei servizi critici e la definizione di recovery point e tempi accettabili. Il nostro team può accompagnarLa lungo questo percorso, definendo una strategia di disaster recovery completa e in linea con i Suoi obiettivi di business continuity.
I test regolari sono fondamentali per garantire che il piano funzioni come previsto e che il team sia pronto ad affrontare un evento reale. Possiamo affiancarLa nella progettazione e aiutarLa a identificare potenziali lacune e aree di miglioramento. In caso di problemi durante l'attivazione del disaster recovery, DoiT è pronta a intervenire. Sappiamo bene che, in questi scenari, ogni minuto conta. Il nostro team è in grado di reagire in modo tempestivo ed efficiente, aiutandoLa a ripristinare i servizi e a contenere i tempi di inattività. Che si tratti di risolvere un problema tecnico o di fornire indicazioni operative, ci impegniamo ad accompagnarLa attraverso la crisi. Il nostro coinvolgimento non si esaurisce con il ripristino: dopo l'evento, possiamo aiutarLa ad analizzare quanto accaduto, valutare l'efficacia del processo di recovery e fornire indicazioni tecniche e best practice.
In DoiT ci consideriamo il Suo partner per la continuità operativa e la resilienza. Dalla pianificazione al testing, dal ripristino all'apprendimento, siamo al Suo fianco in ogni fase del percorso di disaster recovery.
Conclusione
Il disaster recovery non è un elemento opzionale della strategia aziendale: è una componente critica che assicura la continuità operativa di fronte agli eventi imprevisti. Sfruttando la potenza e la flessibilità di AWS, le aziende possono costruire piani di disaster recovery solidi che riducono al minimo tempi di inattività e perdita di dati, garantendo la possibilità di riprendere rapidamente le operazioni quando si verifica un disastro. Una consulenza professionale aiuta a individuare le potenziali vulnerabilità dei sistemi e a suggerire i servizi AWS più adatti per affrontarle. Questa esperienza non solo Le permette di risparmiare tempo ed energie, ma aiuta anche a evitare gli errori più comuni e a costruire un piano di disaster recovery più robusto ed efficace. In sostanza, con AWS come piattaforma di disaster recovery e DoiT come partner di fiducia, ottiene la certezza che il Suo business sia in grado di resistere alle interruzioni e mantenere la continuità operativa. Ci impegniamo a offrire alla Sua azienda un ambiente cloud resiliente e sicuro, aiutandoLa a trasformare le potenziali avversità in una dimostrazione concreta della resilienza del Suo business.