Servizi cloud e gestiti: dal cloud backup all’infrastruttura IT chiavi in mano
In generale affidarsi a dei servizi significa godere dei vantaggi delle migliori tecnologie, senza però
Quanti dati possiamo permetterci di perdere in caso di blocco dei sistemi informativi ed entro quanto tempo dobbiamo necessariamente ripartire?
Per Disaster Recovery Plan si intende comunemente l’insieme delle attività volte a far ripartire l’operatività dei sistemi informatici e a rendere nuovamente disponibili i dati aziendali a fronte di un evento che ha causato un fermo dei servizi IT e/o la perdita di dati.
Il Disaster Recovery Plan è parte di una più ampia strategia di Data Protection & Availability aziendale, volta ad assicurare integrità, riservatezza e disponibilità dei dati.
Prova il calcolatore RPO e RTO:
calcola i tuoi tempi e costi di recovery
Se stai leggendo questo articolo ti è probabilmente già chiaro che il funzionamento dei sistemi informatici e la disponibilità dei dati sono elementi imprescindibili per la tua attività aziendale. Vediamo quindi insieme come affrontare un piano di IT Disaster Recovery che tenga in considerazione gli aspetti di business.
Per prima cosa riflettiamo su quali dati/informazioni ci possiamo permettere di perdere e su quanto tempo possiamo far passare prima che i servizi siano ripristinati. I due fattori su cui stiamo riflettendo hanno un nome: RPO e RTO. Si tratta di due acronimi che significano rispettivamente e Recovery Point Objective (RPO) e Recovery Time Objective (RTO).
Si tratta sicuramente di una tematica tecnica, ma per analizzarla dobbiamo avere una visione globale dell’azienda, sia dal punto di vista dell’infrastruttura informatica, sia dal punto di vista dei processi e dei ruoli.
Con RTO intendiamo il tempo in cui un servizio può restare fermo o un dato può restare inaccessibile. Ossia quanto tempo ci possono mettere i nostri sistemi a ripartire dopo un “disastro”? Il valore dipenderà dal tipo di dato o servizio.
Se vivessimo in un mondo ideale, senza vincoli tecnici e di budget, diremmo tutti che RPO e RTO dovrebbero essere uguali a zero. Se però ci confrontiamo con la realtà e proviamo ad analizzare le reali esigenze, è evidente che il nostro obiettivo dipenderà dal tipo di business e varierà in funzione del servizio e del dato.
Per poter definire correttamente il nostro RTO è importante analizzare ruoli e processi aziendali, ma facciamo attenzione perché chiedere ai referenti che utilizzano i vari servizi le loro aspettative in termini di RTO potrebbe essere fuorviante. L’approccio più costruttivo è basarsi su dati oggettivi.
Per prima cosa facciamo un elenco di tutti i servizi, sistemi, applicazioni presenti in azienda e capiamo quale funzione svolgono e quali uffici/utenti sarebbero coinvolti da un loro blocco.
Calcoliamo poi l’impatto che un blocco di questi servizi comporterebbe, ovviamente questa analisi va fatta per ogni applicazione/servizio tenendo anche in considerazione l’eventuale stagionalità del nostro business: potrebbero ad esempio esserci particolari periodi dell’anno in cui un servizio è maggiormente strategico.
Ecco alcune domande a cui dobbiamo rispondere su ogni applicazione e su un suo eventuale fermo:
Se da questa analisi risulta che un’applicazione è particolarmente strategica, allora il nostro RTO dovrà coincidere con il tempo minimo necessario a ripristinare quest’ultima. Se da questa analisi risulta che tutte le applicazioni hanno un’incidenza simile sul business allora potremo calcolare una media matematica.
Ora confrontiamoci con la realtà e calcoliamo il nostro Recovery Time attuale (Recovery Time Actual -RTA) facendo un test di ripristino.
Se RTO ed RTA non si equivalgono dovremo correre ai ripari!
Con Recovery Point Objective (RPO) intendiamo la perdita di dati ammissibile.
La nostra situazione attuale (RPA: Recovery Point Actual) potrebbe discostarsi dal nostro obiettivo, ossia dal nostro RPO.
Se la nostra possibilità di ripristino dipende dai backup e questi sono giornalieri, allora il nostro RPA è di 24 ore. Corrisponde al nostro obiettivo?
Ipotizziamo ad esempio che siano le 17:00 e il nostro sistema vada in fiamme. Possiamo permetterci di perdere tutti i dati prodotti a partire dalle 20.00 di ieri sera (orario in cui è stato eseguito il backup giornaliero), quindi 21 ore fa?
Se la risposta è no, allora il nostro RPA e il nostro RPO non coincidono e dovremo porre rimedio. Nel farlo ricordiamoci che mettere in atto un IT Disaster Recovery Plan con un RPO uguale a zero potrebbe essere costoso. Accertiamoci quindi che sia realmente necessario.
Procediamo per gradi effettuando prima un’analisi accurata che ci permetta di determinare un RPO realistico. Proprio come abbiamo fatto per determinare il nostro RTO, anche nel calcolo del nostro RPO analizziamo le diverse tipologie di dato della nostra azienda e per ognuna chiediamoci se una perdita di dati nel corso della giornata può essere ragionevolmente neutralizzata dal backup del giorno prima. Quest’analisi ci aiuterà a capire quanto il nostro RPO debba realmente essere vicino allo zero.
Abbiamo già avuto modo di riflettere sulla correlazione tra business e IT in termini di dati e servizi e abbiamo visto come procedere nel definire RTO e RPO.
Se abbiamo la possibilità di estendere la visione ad un campo aziendale più ampio, coinvolgere tutti i reparti nell’esecuzione di una Business Impact Analysis è sicuramente un modo più corretto di procedere, che vede l’inserimento del nostro piano di IT Disaster Recovery all’interno di una strategia più completa di Business Continuity aziendale.
La BIA ci permette infatti di:
Un’analisi così strutturata ci permette di sensibilizzare il management aziendale e di portare il nostro IT Disaster Recovery Plan ad un livello più strategico dell’organizzazione.
In generale affidarsi a dei servizi significa godere dei vantaggi delle migliori tecnologie, senza però
I dati sono stati definiti il nuovo petrolio, non c’è azienda od organizzazione che possa
Scopriamo insieme cosa sono i parametri RPO e RTO e perché sono imprescindibili nell’elaborazione di
Business Continuity e Disaster Recovery: due approcci complementari al tema della data protection & availability.<br
Indipendentemente dal settore in cui opera la nostra azienda, quando si verifica un evento imprevisto
Chi non si è mai chiesto cosa potrebbe accadere se l’azienda in cui lavoriamo dovesse
Com’è noto, per backup si intende una copia di sicurezza di una parte o di
Sappiamo tutti che non esiste più un’azienda in grado di operare senza una infrastruttura informatica.
Quando si progetta un sistema di backup occorre prendere in considerazione diversi aspetti e analizzare
Nell’ambito di una più ampia strategia di Business Continuity Aziendale il reparto IT è chiamato
Cookie | Durata | Descrizione |
---|---|---|
ASP.NET_SessionId | session | Issued by Microsoft's ASP.NET Application, this cookie stores session data during a user's website visit. |
cookielawinfo-checkbox-advertisement | 1 year | Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category . |
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
CookieLawInfoConsent | 1 year | Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie. |
elementor | never | This cookie is used by the website's WordPress theme. It allows the website owner to implement or change the website's content in real-time. |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
_GRECAPTCHA | 5 months 27 days | This cookie is set by the Google recaptcha service to identify bots to protect the website against malicious spam attacks. |
Cookie | Durata | Descrizione |
---|---|---|
__cf_bm | 30 minutes | This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. |