{"id":5882,"date":"2023-05-26T09:00:00","date_gmt":"2023-05-26T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5882"},"modified":"2023-06-23T17:39:53","modified_gmt":"2023-06-23T15:39:53","slug":"disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","title":{"rendered":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity"},"content":{"rendered":"\n<p><a href=\"https:\/\/blog.besharp.it\/it\/disaster-recovery-ibrido-linee-guida-strategiche\/\" target=\"_blank\" rel=\"noreferrer noopener\">Leggi Parte 2<\/a> | <a href=\"https:\/\/blog.besharp.it\/it\/best-practices-per-strategie-di-disaster-recovery-da-aws-verso-aws\/\" target=\"_blank\" rel=\"noreferrer noopener\">Leggi Parte 3<\/a><\/p>\n\n\n\n<p>Ormai non \u00e8 pi\u00f9 una citazione, ma un mantra:<\/p>\n\n\n\n<p>\u201cEverything fails, all the time\u201d &#8211; Werner Vogels<\/p>\n\n\n\n<p>Questo principio ha condizionato la metodologia con cui si progetta infrastrutture in Cloud. Bisogna valutare le diverse tipologie di fallimento prima di progettare. Non tutti i disastri, per\u00f2, sono uguali. Proviamo a darne una classificazione:<\/p>\n\n\n\n<ul>\n<li>Eventi su piccola scala: per esempio quando <strong>un server o una VM<\/strong> vanno offline<\/li>\n\n\n\n<li>Eventi su grande scala: nel mondo AWS possiamo immaginare un fallimento di <strong>molteplici risorse di una singola Availability Zone<\/strong> all\u2019interno di una singola Region.<\/li>\n\n\n\n<li>Eventi colossali: il fallimento comporta il mancato servizio di molti sistemi e affligge tutti gli utenti. Il disastro colpisce <strong>la Region nella sua interezza<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>Per rispondere in maniera efficace a queste tre tipologie di disastro bisogna progettare e pianificare in tre maniere diverse:<\/p>\n\n\n\n<ul>\n<li><strong>High Availability<\/strong>: l&#8217;alta disponibilit\u00e0 fornisce ridondanza e tolleranza ai guasti. Un sistema \u00e8 altamente disponibile quando \u00e8 in grado di <strong>resistere al fallimento di uno o pi\u00f9 componenti individuali<\/strong> (ad esempio, dischi rigidi, server o connettivit\u00e0 di rete). I sistemi di produzione di solito hanno requisiti definiti per l&#8217;uptime.<\/li>\n\n\n\n<li><strong>Backup<\/strong>: il backup \u00e8 fondamentale per proteggere i dati e <strong>garantire la continuit\u00e0 aziendale<\/strong>. Tuttavia, pu\u00f2 essere difficile da implementare. \u00c8 essenziale tenere i dati critici salvati, in caso di disastro.<\/li>\n\n\n\n<li><strong>Disaster Recovery (DR)<\/strong>: un disastro \u00e8 qualsiasi <strong>evento che ha un impatto negativo sulla continuit\u00e0 aziendale<\/strong> o sulle finanze di un&#8217;azienda. Tali eventi includono il fallimento di hardware o software, un&#8217;interruzione di rete, un&#8217;interruzione di alimentazione o danni fisici a un edificio (come un incendio o un&#8217;alluvione). La causa pu\u00f2 essere un errore umano o qualche altro evento significativo. Il ripristino dopo un disastro \u00e8 un insieme di politiche e procedure che consentono il recupero o la continuazione delle infrastrutture tecnologiche e dei sistemi vitali dopo qualsiasi disastro.<\/li>\n<\/ul>\n\n\n\n<p>In questa serie di articoli ci concentreremo in particolare sul Disaster Recovery, dalla sua definizione, fino alle tecniche di ripristino e come l\u2019ecosistema di servizi AWS ci pu\u00f2 aiutare a garantire la continuit\u00e0 del business in qualunque situazione.<\/p>\n\n\n\n<p>Il Disaster Recovery (DR) \u00e8 un processo fondamentale per garantire la continuit\u00e0 delle operazioni aziendali in caso di disastri informatici. Esistono diverse tecniche di DR, e tutte mirano a ripristinare le applicazioni, i dati e le infrastrutture IT il pi\u00f9 rapidamente possibile dopo un evento avverso.<\/p>\n\n\n\n<p>In ambito Cloud, il DR \u00e8 ancora pi\u00f9 importante, poich\u00e9 le applicazioni e i dati sono ospitati in remoto su server e infrastrutture che possono essere soggette a interruzioni di servizio a causa di problemi di connettivit\u00e0, guasti hardware, attacchi informatici o disastri naturali.<\/p>\n\n\n\n<p>Ogni volta che si affronta questo argomento e per garantire un DR efficace \u00e8 necessario partire da due acronimi che sono fondamentali per la selezione della miglior strategia di DR:<\/p>\n\n\n\n<ul>\n<li>RPO (<strong>Recovery Point Objective<\/strong>) per definire questo KPI dobbiamo rispondere ad una semplice domanda: quanti dati possiamo permetterci di perdere?<strong><br><\/strong>RPO definisce ogni quanto tempo replicare i dati per assicurarsi il giusto lasso di tempo tra l\u2019ultima replica e l\u2019evento disastroso. Pi\u00f9 \u00e8 frequente \u00e8 la replica meno sar\u00e0 l\u2019eventuale perdita massima di dati.<\/li>\n<\/ul>\n\n\n\n<p>RTO<strong> <\/strong>(<strong>Recovery Time Objective<\/strong>), in questo caso la domanda a cui dobbiamo rispondere \u00e8: per quanto tempo possiamo lasciare i nostri sistemi non funzionanti prima di tornare operativi?<strong><br><\/strong>Il concetto di RTO si riferisce quindi al tempo che intercorre tra il disastro e il completo ripristino dei sistemi.<\/p>\n\n\n\n<p><\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"430\" src=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR-1024x430.png\" alt=\"explanation of rto and rpo in DR\" class=\"wp-image-5884\" srcset=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR-1024x430.png 1024w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR-400x168.png 400w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR-768x323.png 768w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR-1536x646.png 1536w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/rto_rpo_DR.png 1801w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Courtesy of AWS (https:\/\/aws.amazon.com\/it\/blogs\/architecture\/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud\/)<\/figcaption><\/figure><\/div>\n\n\n<p><\/p>\n\n\n\n<p>In sintesi, il DR \u00e8 un processo fondamentale per garantire la continuit\u00e0 delle operazioni aziendali in caso di disastri informatici, e la sua efficacia dipende dall&#8217;obiettivo RTO\/RPO e dal giusto equilibrio tra consistenza, disponibilit\u00e0 e tolleranza ai guasti.<\/p>\n\n\n\n<p>Esistono diversi approcci per il Disaster Recovery, e la scelta dipende da fattori come il budget, la criticit\u00e0 dei dati e delle applicazioni, il tempo di ripristino accettabile (RTO) e il punto di ripristino accettabile (RPO).<\/p>\n\n\n\n<p>Tra i metodi pi\u00f9 comuni per il DR troviamo:<\/p>\n\n\n\n<ol>\n<li>Backup and Restore: questa \u00e8 una delle tecniche pi\u00f9 comuni di disaster recovery. Coinvolge il regolare backup dei dati critici e dei sistemi, che vengono successivamente ripristinati in caso di interruzione. Si creano copie dei dati e delle applicazioni su un supporto separato, come dischi rigidi esterni o servizi di archiviazione cloud. Nel caso di un disastro, i dati vengono recuperati dal backup e ripristinati sui sistemi riparati o sostituiti.<\/li>\n\n\n\n<li>Pilot Light: la tecnica del &#8220;Pilot Light&#8221; coinvolge la creazione di un&#8217;infrastruttura di base, essenziale per far funzionare le applicazioni critiche. Si tratta di avere un ambiente di backup parzialmente configurato, che pu\u00f2 essere rapidamente scalato e attivato in caso di emergenza. Di solito, vengono replicati solo i componenti chiave del sistema, mentre il resto dell&#8217;infrastruttura viene creato al momento del ripristino.<\/li>\n\n\n\n<li>Warm Standby: la tecnica del &#8220;Warm Standby&#8221; coinvolge la creazione di una replica dell&#8217;ambiente di produzione, in modo che sia pronto per essere attivato in caso di emergenza. L&#8217;ambiente di standby viene mantenuto aggiornato con i dati e le configurazioni pi\u00f9 recenti, ma i servizi non vengono eseguiti in tempo reale. Quando si verifica un disastro, il sistema di produzione viene interrotto e il sistema di standby viene attivato per riprendere le operazioni.<\/li>\n\n\n\n<li>Multi-site: la tecnica del &#8220;Multi-site&#8221; coinvolge la distribuzione dei sistemi e dei dati su pi\u00f9 sedi geograficamente distinte. Le sedi possono essere situate in aree separate, consentendo di evitare che un singolo evento danneggi tutte le infrastrutture contemporaneamente. In caso di disastro, il traffico e i servizi possono essere reindirizzati verso le sedi alternative per mantenere la continuit\u00e0 delle operazioni.<\/li>\n<\/ol>\n\n\n\n<p><\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"461\" src=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2-1024x461.png\" alt=\"DR Strategies\" class=\"wp-image-5886\" srcset=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2-1024x461.png 1024w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2-400x180.png 400w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2-768x346.png 768w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2-1536x691.png 1536w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Figure-2.png 1820w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Courtesy of AWS (https:\/\/aws.amazon.com\/it\/blogs\/architecture\/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud\/)<\/figcaption><\/figure><\/div>\n\n\n<p><\/p>\n\n\n\n<p>Per quanto riguarda l&#8217;applicazione delle tecniche di DR in realt\u00e0 di diverse dimensioni, possiamo dire che ogni organizzazione deve scegliere il metodo pi\u00f9 adatto alle proprie esigenze e risorse. Le aziende di grandi dimensioni spesso hanno budget pi\u00f9 elevati e possono permettersi di investire in infrastrutture costose come repliche attive e in costante sincronizzazione.<\/p>\n\n\n\n<p>Le piccole e medie imprese, invece, possono optare per soluzioni pi\u00f9 economiche e flessibili, come la replica dei dati nel cloud.<\/p>\n\n\n\n<p>In sintesi, la scelta del metodo di Disaster Recovery dipende dalle esigenze dell&#8217;organizzazione, dal budget e dalla criticit\u00e0 dei dati e delle applicazioni.<\/p>\n\n\n\n<p>Fin qui sembra tutto chiaro e lineare. Durante la replica dei dati per il disaster recovery, per\u00f2, ci sono diversi fattori tecnici che devono essere presi in considerazione e che possono condizionare RPO\/RTO. Tra i principali si annoverano:<\/p>\n\n\n\n<ul>\n<li>Latenza: la latenza \u00e8 il ritardo temporale tra la scrittura dei dati nel sistema di produzione e la loro replica nel sito di ripristino. \u00c8 importante valutare la latenza per garantire che i dati siano replicati in modo tempestivo e che non si verifichino perdite di dati significative in caso di interruzione.<\/li>\n\n\n\n<li>Consistenza: \u00e8 essenziale garantire che i dati replicati siano <strong>coerenti<\/strong> e <strong>integri<\/strong>. Ci\u00f2 significa che i dati devono essere replicati in un ordine coerente e che le operazioni di scrittura devono essere applicate in modo consistente su entrambi i siti. La mancanza di coerenza dei dati potrebbe portare a risultati imprevisti o alla perdita di dati.<\/li>\n\n\n\n<li>Scalabilit\u00e0: durante la replica dei dati, \u00e8 importante considerare la capacit\u00e0 di gestire volumi di dati crescenti nel tempo. La soluzione di replica dovrebbe essere in grado di scalare in modo efficiente per gestire l&#8217;aumento delle dimensioni dei dati senza compromettere le prestazioni complessive.<\/li>\n\n\n\n<li>Sicurezza: la sicurezza dei dati \u00e8 fondamentale durante la replica per il disaster recovery. I dati replicati devono essere protetti da accessi non autorizzati e da minacce alla sicurezza. Ci\u00f2 pu\u00f2 richiedere l&#8217;implementazione di meccanismi di crittografia, controlli di accesso adeguati e misure di protezione fisica sia nel sito di produzione che in quello di ripristino.<\/li>\n\n\n\n<li>Test e verifica: \u00e8 importante eseguire regolarmente test e verifiche per garantire che il processo di replica dei dati funzioni correttamente e che i dati siano ripristinabili in modo efficace. I test di ripristino dei dati possono aiutare a identificare eventuali problemi o lacune nel processo e consentono di apportare le necessarie correzioni.<\/li>\n\n\n\n<li>Automazione: l\u2019automazione della replica dei dati pu\u00f2 semplificare il processo e ridurre gli errori umani. L&#8217;implementazione di strumenti e processi automatizzati pu\u00f2 consentire di gestire in modo efficiente la replica dei dati, migliorando la coerenza e l&#8217;affidabilit\u00e0 complessiva.<\/li>\n\n\n\n<li>Capacit\u00e0 di ripristino: durante la replica dei dati, \u00e8 importante valutare la capacit\u00e0 di ripristinarli nel sito di destinazione. Ci\u00f2 pu\u00f2 richiedere l&#8217;implementazione di procedure di ripristino adeguate, la disponibilit\u00e0 di risorse hardware e software consone e la capacit\u00e0 di testare e verificare il processo di ripristino.<\/li>\n<\/ul>\n\n\n\n<p>Ovviamente la coperta \u00e8 sempre troppo corta e dobbiamo essere consapevoli che il disaster recovery deve necessariamente essere un compromesso. A sostegno di questo vorrei riportare un teorema fondamentale per i sistemi distribuiti: il CAP theorem.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Il Teaorema CAP<\/h3>\n\n\n\n<p>Il teorema <strong>CAP<\/strong> <strong>(Consistency, Availability, Partition tolerance)<\/strong>, che riguarda normalmente i sistemi di database distribuiti, pu\u00f2 essere applicato in modo analogo al contesto del Disaster Recovery (DR), sebbene con alcune considerazioni aggiuntive. Noto anche come teorema di Brewer, afferma che \u00e8 impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie:<\/p>\n\n\n\n<ol>\n<li>Coerenza (Consistency): la coerenza dei dati nel contesto del DR si riferisce alla garanzia che i dati replicati siano coerenti tra il sito di produzione e il sito di ripristino. In altre parole, i dati replicati dovrebbero riflettere le ultime modifiche effettuate nel sistema di produzione. Tuttavia, durante un evento di interruzione e durante il ripristino, potrebbe essere accettato un breve periodo di inconsistenza dei dati tra i due siti per garantire la continuit\u00e0 operativa. Pertanto, il DR potrebbe sacrificare temporaneamente la coerenza a breve termine per garantire la disponibilit\u00e0 e la tolleranza alla partizione.<\/li>\n\n\n\n<li>Disponibilit\u00e0 (Availability): l&#8217;obiettivo principale del DR \u00e8 garantire la disponibilit\u00e0 dei servizi e dei dati critici in caso di interruzione. Ci\u00f2 significa che il sistema di ripristino dovrebbe essere in grado di fornire servizi essenziali in modo tempestivo, anche se il sito di produzione \u00e8 compromesso. La disponibilit\u00e0 nel contesto del DR pu\u00f2 essere ottenuta sacrificando la coerenza dei dati a breve termine o utilizzando tecniche come il ripristino da backup o l&#8217;utilizzo di risorse di ripristino dedicate.<\/li>\n\n\n\n<li>Tolleranza alla partizione (Partition tolerance): la tolleranza alla partizione nel contesto del DR \u00e8 fondamentale. Si riferisce alla capacit\u00e0 del sistema di continuare a funzionare anche quando si verificano interruzioni o partizioni nella comunicazione tra il sito di produzione e il sito di ripristino. La replica dei dati e delle risorse in siti separati geograficamente contribuisce a garantire la tolleranza alla partizione. In caso di interruzione della comunicazione tra i siti, il sistema di ripristino dovrebbe essere in grado di operare autonomamente fino a quando la comunicazione viene ripristinata.<\/li>\n<\/ol>\n\n\n\n<p>Quando si applica il teorema CAP al DR, spesso si fa una scelta consapevole per bilanciare la coerenza, la disponibilit\u00e0 e la tolleranza alla partizione in base alle esigenze specifiche del business e alle conseguenze delle interruzioni. Ad esempio, in un ambiente di ripristino prioritario, si potrebbe dare priorit\u00e0 alla disponibilit\u00e0, sacrificando temporaneamente la coerenza dei dati. Al contrario, in un ambiente altamente sensibile alla coerenza, si potrebbe priorizzare la coerenza sacrificando temporaneamente la disponibilit\u00e0.<\/p>\n\n\n\n<p>Tutto questo solo per capire come si fa disaster recovery, come si passa da produzione al nostro sito secondario. Ma c\u2019\u00e8 un punto della questione che \u00e8 essenziale e che viene trascurato sempre da tutti, ovvero progettare <strong>come si torna in produzione dopo che l\u2019evento disastroso \u00e8 rientrato<\/strong>. Insomma, ci si dimentica sempre di definire come si \u201ctorna indietro\u201d.<\/p>\n\n\n\n<p>Anche in questo caso \u00e8 importante seguire un processo ben pianificato per garantire una transizione sicura e senza intoppi.&nbsp;<\/p>\n\n\n\n<p>Prima di tutto bisogna fare una valutazione del ripristino. Prima di tornare alla produzione normale, \u00e8 necessario valutare attentamente lo stato del sistema e dell&#8217;ambiente di produzione. <strong>Verificare che il problema o l&#8217;evento di interruzione sia stato risolto completamente e che l&#8217;ambiente sia pronto per il ripristino.<\/strong> In questo caso \u00e8 fondamentale avere dei buoni sistemi di monitoring per rilevare eventuali anomalie o problemi. L\u2019utilizzo di strumenti di monitoraggio e avvisi \u00e8 utile per identificare e risolvere tempestivamente qualsiasi problema che possa verificarsi durante la transizione al ritorno in produzione. Repetita iuvant: il <strong>monitoring<\/strong> \u00e8 fondamentale anche <strong>post-ripristino<\/strong> per consentirci di individuare eventuali problemi residui o effetti collaterali che potrebbero emergere e intervenire tempestivamente per risolverli.<\/p>\n\n\n\n<p>Non basta che l\u2019ambiente di produzione sia finalmente disponibile, ma vanno eseguiti test e convalide. Ci\u00f2 pu\u00f2 includere test funzionali, test di carico e altri test appropriati per garantire che tutto funzioni correttamente come previsto. Verificare che i dati siano coerenti e integri.<\/p>\n\n\n\n<p>In alcuni casi, potrebbe essere necessario eseguire un rollback delle modifiche apportate durante il processo di DR. Questo pu\u00f2 coinvolgere il ripristino delle configurazioni, delle modifiche applicative o delle versioni precedenti dei dati. \u00c8 importante pianificare il rollback in modo da minimizzare l&#8217;impatto sulle operazioni e garantire la coerenza dei dati.<\/p>\n\n\n\n<p>Da non sottovalutare nelle situazioni emergenziali \u00e8 la <strong>comunicazione con gli utenti e gli stakeholder coinvolti<\/strong>. Le persone coinvolte devono essere rese consapevoli delle modifiche apportate e dei passaggi necessari per tornare alla produzione normale.&nbsp;<\/p>\n\n\n\n<p>Per rendere edotte le persone coinvolte \u00e8 necessario documentare le nostre procedure, ovvero registrare tutti i passaggi, le modifiche apportate e le azioni intraprese durante il processo di DR. Ci\u00f2 aiuter\u00e0 a ricostruire l&#8217;evento di interruzione e ad analizzare in seguito per migliorare le future strategie di DR.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusioni<\/h2>\n\n\n\n<p>Siamo giunti al termine della prima tappa del nostro viaggio nel Disaster Recovery in Cloud. Dopo averne definito i macro concetti e averne compreso la dinamiche, \u00e8 il momento di entrare nel vivo dell\u2019implementazione delle tecniche di DR in scenari aziendali complessi.<\/p>\n\n\n\n<p>Cominceremo approfondendo nel prossimo articolo le migliori tecniche di DR per i contesti di tipo ibrido on-prem to Cloud per poi parlare di DR per la Business Continuity in ambito Cloud-to-Cloud nel terzo articolo della nostra mini-serie.<\/p>\n\n\n\n<p>Pronti?<\/p>\n\n\n\n<p>Ci vediamo tra 14 giorni su Proud2beCloud!<\/p>\n\n\n\n<p><a href=\"https:\/\/blog.besharp.it\/it\/disaster-recovery-ibrido-linee-guida-strategiche\/\" target=\"_blank\" rel=\"noreferrer noopener\">Leggi Parte 2<\/a> | <a href=\"https:\/\/blog.besharp.it\/it\/best-practices-per-strategie-di-disaster-recovery-da-aws-verso-aws\/\" target=\"_blank\" rel=\"noreferrer noopener\">Leggi Parte 3<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h4 class=\"wp-block-heading\">About Proud2beCloud<\/h4>\n\n\n\n<p>Proud2beCloud \u00e8 il blog di&nbsp;<a href=\"https:\/\/www.besharp.it\/\" target=\"_blank\" rel=\"noreferrer noopener\">beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all&#8217;avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Leggi Parte 2 | Leggi Parte 3 Ormai non \u00e8 pi\u00f9 una citazione, ma un mantra: \u201cEverything fails, all the [&hellip;]<\/p>\n","protected":false},"author":5,"featured_media":5905,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[650,654],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v21.9.1 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Disaster Recovery in Cloud: tecniche efficaci per la Business continuity - Proud2beCloud Blog<\/title>\n<meta name=\"description\" content=\"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity\" \/>\n<meta property=\"og:description\" content=\"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/\" \/>\n<meta property=\"og:site_name\" content=\"Proud2beCloud Blog\" \/>\n<meta property=\"article:published_time\" content=\"2023-05-26T07:00:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-06-23T15:39:53+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Copertina-blog-26-05-23_12-05-23-social-eng.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"628\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Nicola Ferrari\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity\" \/>\n<meta name=\"twitter:description\" content=\"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Copertina-blog-26-05-23_12-05-23-social-eng.png\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Nicola Ferrari\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/\",\"url\":\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/\",\"name\":\"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity - Proud2beCloud Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\"},\"datePublished\":\"2023-05-26T07:00:00+00:00\",\"dateModified\":\"2023-06-23T15:39:53+00:00\",\"author\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/c7a43fb4eda911877f8ce2702c09706f\"},\"description\":\"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.besharp.it\/it\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\",\"url\":\"https:\/\/blog.besharp.it\/it\/\",\"name\":\"Proud2beCloud Blog\",\"description\":\"il blog di beSharp\",\"alternateName\":\"Proud2beCloud Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.besharp.it\/it\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/c7a43fb4eda911877f8ce2702c09706f\",\"name\":\"Nicola Ferrari\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/cdf6121b27aba78c0e1b61f1d5888325?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/cdf6121b27aba78c0e1b61f1d5888325?s=96&d=mm&r=g\",\"caption\":\"Nicola Ferrari\"},\"description\":\"Cloud Infrastructure Line Manager @ beSharp and AWS authorized instructor champion. I live my life one level at a time getting superpowers by collecting caffeine hidden here and there in my daily map. I\u2019m a hardened internet surfer (yes, I surfed the whole internet\u2026 twice!) and tech-addicted with a passion for computers and networking. Building great IT things all nice and tidy contribute to achieving my main goal: the pursuit of perfection!\",\"url\":\"https:\/\/blog.besharp.it\/it\/author\/ferro\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity - Proud2beCloud Blog","description":"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","og_locale":"it_IT","og_type":"article","og_title":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity","og_description":"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.","og_url":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","og_site_name":"Proud2beCloud Blog","article_published_time":"2023-05-26T07:00:00+00:00","article_modified_time":"2023-06-23T15:39:53+00:00","og_image":[{"width":1200,"height":628,"url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Copertina-blog-26-05-23_12-05-23-social-eng.png","type":"image\/png"}],"author":"Nicola Ferrari","twitter_card":"summary_large_image","twitter_title":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity","twitter_description":"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.","twitter_image":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/05\/Copertina-blog-26-05-23_12-05-23-social-eng.png","twitter_misc":{"Scritto da":"Nicola Ferrari","Tempo di lettura stimato":"14 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","url":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","name":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity - Proud2beCloud Blog","isPartOf":{"@id":"https:\/\/blog.besharp.it\/it\/#website"},"datePublished":"2023-05-26T07:00:00+00:00","dateModified":"2023-06-23T15:39:53+00:00","author":{"@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/c7a43fb4eda911877f8ce2702c09706f"},"description":"Disaster Recovery in Cloud: dalla definizione, fino alle tecniche di ripristino per garantire la Business Continuity aziendale.","breadcrumb":{"@id":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.besharp.it\/it\/"},{"@type":"ListItem","position":2,"name":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity"}]},{"@type":"WebSite","@id":"https:\/\/blog.besharp.it\/it\/#website","url":"https:\/\/blog.besharp.it\/it\/","name":"Proud2beCloud Blog","description":"il blog di beSharp","alternateName":"Proud2beCloud Blog","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.besharp.it\/it\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"it-IT"},{"@type":"Person","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/c7a43fb4eda911877f8ce2702c09706f","name":"Nicola Ferrari","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/cdf6121b27aba78c0e1b61f1d5888325?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/cdf6121b27aba78c0e1b61f1d5888325?s=96&d=mm&r=g","caption":"Nicola Ferrari"},"description":"Cloud Infrastructure Line Manager @ beSharp and AWS authorized instructor champion. I live my life one level at a time getting superpowers by collecting caffeine hidden here and there in my daily map. I\u2019m a hardened internet surfer (yes, I surfed the whole internet\u2026 twice!) and tech-addicted with a passion for computers and networking. Building great IT things all nice and tidy contribute to achieving my main goal: the pursuit of perfection!","url":"https:\/\/blog.besharp.it\/it\/author\/ferro\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/5882"}],"collection":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/comments?post=5882"}],"version-history":[{"count":0,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/5882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media\/5905"}],"wp:attachment":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media?parent=5882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/categories?post=5882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/tags?post=5882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}