Skip to content Skip to footer

Scegliere la giusta strategia di backup per non rischiare il fermo

Una corretta strategia di backup è importante perché consente di proteggere i dati da possibili perdite a causa di incidenti, malfunzionamenti hardware, attacchi informatici, virus e altre minacce. In caso di perdita dei dati, la possibilità di recuperarli attraverso un backup può fare la differenza tra il ripristino rapido dei sistemi e la perdita permanente di informazioni importanti. Inoltre, una corretta strategia di backup consente di rispettare eventuali normative e requisiti di conformità aziendale.

Tuttavia, ci sono delle regole che vanno sempre tenute a mente e che portano ad uno studio di quello che si deve proteggere e come farlo. Cerchiamo di vedere assieme alcuni dei punti da analizzare, quando si parla di backup.

RPO e RTO

Quando si parla di backup, non si può non parlare di RPO ed RTO. In un mondo perfetto, questi due valori sarebbero prossimi allo zero e la cosa non sarebbe neppure impossibile, se questo non generasse un costo elevatissimo in termini di hardware e gestione operativa.

Le aziende sono diverse tra di loro, hanno esigenze diverse e quindi hanno requisiti diversi per i loro obiettivi di recupero. Tuttavia, una pratica comune consiste nel dividere applicazioni e servizi in diversi livelli e impostare i valori del tempo di ripristino e dell’obiettivo del punto (RTPO) in base agli accordi sul Service Level Agreement (SLA) a cui l’organizzazione si è impegnata.

Il punto di partenza è la classificazione della protezione dei dati, importante per determinare come archiviare, accedere, proteggere, recuperare e aggiornare i dati e le informazioni in modo più efficiente in base a criteri specifici. È essenziale analizzare le applicazioni e determinare quali di esse guidano la tua attività, generano entrate e sono indispensabili per rimanere operativi. Questo processo, essenziale per un buon piano di continuità aziendale, è chiamato analisi dell’impatto aziendale e stabilisce protocolli e azioni per affrontare un disastro.

Ad esempio, si può utilizzare un modello a tre livelli per progettare il piano di continuità aziendale:

  • Livello 1: applicazioni mission-critical che richiedono un RTPO inferiore a 15 minuti
  • Livello 2: applicazioni business-critical che richiedono un RTO di 2 ore e un RPO di 4 ore
  • Livello 3: applicazioni non critiche che richiedono un RTO di 4 ore e un RPO di 24 ore

È importante tenere presente che le applicazioni mission-critical, business-critical e non critiche variano a seconda dei settori e ciascuna organizzazione definisce questi livelli in base alle proprie operazioni e requisiti.

Il Recovery Point Objective (RPO) è uno dei parametri usati nell’ambito delle politiche di disaster recovery per descrivere la tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che deve intercorre tra la produzione di un dato e la sua messa in sicurezza (ad esempio attraverso backup) e, conseguentemente, fornisce la misura della massima quantità di dati che il sistema può perdere a causa di guasto improvviso.

Al diminuire dell’RPO desiderato/specificato si rendono necessarie politiche di sicurezza sempre più stringenti e dispendiose, che possono andare dal salvataggio dei dati su supporti ridondanti tolleranti ai guasti fino alla loro pressoché immediata replicazione su un sistema informatico secondario d’emergenza (soluzione in grado di garantire, in linea teorica, valori di RPO prossimi allo zero).

Il Recovery Time Objective (RTO) è il tempo necessario per il pieno recupero dell’operatività di un sistema o di un processo organizzativo in un sistema di analisi Business Critical System (ad esempio implementazioni di politiche di Disaster Recovery nei Sistemi Informativi). È in pratica la massima durata, prevista o tollerata, del downtime occorso.

Aspetto di primaria importanza riveste il fatto che il valore di RTO sia definito, conosciuto e verificato, tenendo presente che se un downtime lungo danneggia la possibilità di fruire del servizio più di uno breve, il danno maggiore deriva dall’inconsapevolezza di quanto possa essere il tempo previsto per il ripristino dei servizi danneggiati.

Impatto Economico

Un RPO molto spinto si traduce nella necessità di tanto spazio e performance elevate tra infrastruttura e la parte di backup. È importante valutare cos’è business critical e cosa non lo è. Ad esempio un database, o un file server, sono più importanti di una macchina virtuale con a bordo il solo software applicativo

Il metodo più efficace per raggiungere un basso RTO è avere un sito di Disaster Recovery che possa riportare lo stato dell’arte il più rapidamente possibile ma anche qui entra in gioco il concetto del RPO perchè se I siti sono distanti tra di loro geograficamente, lo spostamento del dato potrebbe richiedere investimenti elevati.

Dove Salvare?

I livelli di salvataggio sono sicuramente due: short-term e long-term. Nel primo caso si tratta dello storage locale che è quello che ci garantisce il ripristino immediato del dato; nel secondo caso si tratta di una scelta aziendale perchè potrebbe essere la classica tape, potrebbe essere il cloud, potrebbe essere un altro storage o un sito remoto.

Salvare su tape library ci permette di avere una copia offline e quindi di essere meno sensibili ad attacchi esterni ma genera anche un RPO molto alto, perchè il delta di dati persi potrebbe arrivare anche a 7 giorni (qualora il backup su tape fosse settimanale).

Salvare in cloud aiuta ad abbattere i costi e ci permette di avere un RPO corto ma sbilancia il valore di RTO perchè recuperare una VM dal cloud potrebbe richiedere molto più tempo del desiderato.

Un terzo scenario è dato dal salvare in locale i dati long-term, utilizzando uno storage immutabile, cosa che permette di evitare qualsiasi tipologia di corruzione del dato di backup anche in caso di attacco ransomware. Questo storage dovrebbe trovarsi in un ambiente isolato, fuori dal contesto di dominio, raggiungibile solo da VLAN o IP mirati.

Qualsiasi sia la vostra scelta è sempre bene adottare la regola del 3-2-1 che prevede almeno 3 copie del vostro dato, di cui due almeno in repository diversi, dove uno di questi si trova fuori dalla vostra organizzazione.

Conclusione

Tutto chiaro? La valutazione sull’impatto di un fermo è fondamentale per evitare danni economici molto più grandi rispetto a quello che potrebbe essere l’investimento iniziale, o annuale, nella protezione del proprio dato e del proprio business.

Il tutto si può riassumere in una semplice domanda: quanto costerebbe un’ora di fermo della tua azienda o di uno dei servizi core che vengono magari erogati ai tuoi utenti e clienti?