Proteggere i dati con Nakivo – Introduzione
La “data-protection” in ambito aziendale è una tematica che riguarda non solo le grandi aziende, ma anche piccole e medie realtà. La scarsa consapevolezza nel problema della perdita dei dati è qualcosa che lascia ancora perplessi gli esperti del settore.
Ancora oggi mi capita di sentire testimonianze di consulenti e tecnici IT che si trovano spesso a fronteggiare situazioni paradossali dovute all’assenza di sistemi di protezione dei dati o alla presenza del classico script da “cantinaro” che a costo zero tenta di sostituirsi a un decente software di backup, con risultati nella maggior parte dei casi deludenti.
Ebbene ci troviamo ancora una volta di fronte ad un problema culturale, dove la scarsa valutazione del rischio unito a budget insufficienti potrebbe seriamente compromettere l’attività aziendale.
Durante i miei scouting tecnologici ho avuto modo di testare Nakivo, una soluzione di backup e replica per ambienti virtuali (VMware vSphere e Microsoft Hyper-V) e istanze pubbliche EC2 che girano in Amazon Cloud AWS.
L’installazione e la configurazione sono veramente semplici; ma in particolare ciò che rende accattivante questo prodotto è la possibilità di verificare l’integrità dei dati nelle macchine virtuali in modo automatico.
In breve, Nakivo fa il backup e ne verifica la consistenza! Perché non c’è cosa peggiore che scoprire di non avere dati utilizzabili al momento del bisogno.
Implementazione in pochi step
Nakivo è una soluzione software disponibile in diverse in diverse modalità: virtual appliance, pacchetto installabile in ambiente Windows o Linux, AMI in ambiente AWS. Per tutte le sopraddette versioni l’implementazione all’interno dell’ambiente virtuale richiede pochi e semplici passaggi.
(Fonte: documentazione ufficiale di Nakivo)
Gli elementi principali di un sistema basato su Nakivo sono:
- Il Backup server: il cosiddetto “director”, vale a dire l’elemento che coordina i job di backup, replica e restore.
- Il Transporter: che permette il trasferimento dei dati dall’infrastruttura virtuale al repository di backup.
- Il backup repository: uno spazio di archiviazione in grado di stoccare in maniera intelligente le macchine virtuali.
Rispetto agli altri software di backup, un sicuro punto di forza è la disponibilità dello stesso software come package installabile direttamente all’interno di alcune NAS che tipicamente vengono impiegate per depositare i dati di backup. Nelle piccole e medie realtà aziendali, basta una NAS Synology per avere backup server e repository in un’unica soluzione.
Attualmente le NAS che supportano nativamente i package di NAKIVO sono:
Al termine dell’installazione e della configurazione dell’utente di amministrazione, attraverso il semplice inserimento delle credenziali amministrative dell’infrastruttura virtuale, è possibile reperire la lista delle macchine virtuali da sottoporre a protezione.
La decisione su come salvare i backup merita qualche considerazione.
Nakivo permette sostanzialmente due modalità di esecuzione del backup:
- forever incremental: dopo il primo backup full le differenze rispetto ad esso vengono archiviate; in questo modo è possibile disporre dell’ultima copia di backup integra.
- incremental with full backups: vengono eseguiti backup full e incrementali; questo comporta solitamente che in un mese di backup vengono realizzate 4 backup full e 6 backup incrementali ogni settimana.
La modalità con cui il backup viene salvato su supporto disco, diventa poi argomento di discussione tecnica e soprattuto di budget da stanziare per l’acquisizione della NAS, del suo livello di protezione e delle performance. Ma la cosa più importante è assicurarsi che i dati siano coerenti al momento del bisogno; per questo motivo Nakivo grazie all’opzione di self healing è in grado di verificare la coerenza dei dati residenti nella repository di backup.
Per aumentare il livello di sicurezza a la corretta segregazione dei dati è possibile attivare la crittografia mediante password.
Il job di backup
La definizione dello scheduling del backup è un elemento decisionale importante, soprattutto per gli impatti sulle performance dei sistemi implicati nel processo di backup. La buona pratica suggerisce quindi di definire alcuni momenti “critici” a carico sia della piattaforma di backup, che dei sistemi coinvolti:
- Backup window: la finestra di backup vera e propria. A seconda della configurazione della repository di backup, della quantità e della variabilità di dati da proteggere, è possibile avere tempi di backup full lunghi e incrementali sempre più piccoli.
- Off peak windows: ovvero la finestra nella quale è possibile effettuare operazioni che posso impattare le performance dei sistemi. In questa finestra rientrano tutti gli aggiornamenti e operazioni impattanti.
- Black window: finestra di disservizio per attività manutentive impattanti. Nel caso del backup, questa potrebbe coincidere con il self healing.
- Restore test window: questa è una fase che sta diventando quasi una necessità all’interno delle aziende, dato che oltre a fornire garanzia di recupero determina anche se il processo di backup dell’applicazione o della macchina virtuale è valido, oppure occorre modificare/introdurre processi iniziali (detti di prejob) prima di eseguire il backup vero e proprio. Nakivo ha un sistema di verifica del backup automatico che prevede la possibilità di recuperare una o più istanze virtuali direttamente dalla repository di backup (per non impattare sulle capacità dello storage principale). In questo modo è possibile eseguire un controllo automatico e/o manuale sull’integrità dei dati.
Nakivo dispone di un sistema di scheduling molto versatile, capace di definire per gruppi di macchine virtuali diversi momenti in cui eseguire il backup e le eventuali operazioni di verifica.
La rete costituisce un altro elemento critico e decisionale sia in termini di design e sia in termini di impatti durante l’esecuzione del backup. Per questo motivo, accanto ad un’opportuna scelta dell’architettura di rete, è consigliabile dedicare almeno una VLAN al backup e alla replica, con gli opportuni QoS per garantire il rispetto degli RPO.
Anche in questo caso, soprattutto dove non è possibile dedicare reti o impostare QoS a livello di switch, Nakivo dispone di una opzione denominata “Bandwidth Throttling”, vale a dire impostare i limiti di utilizzo di banda.
La replica e il Disaster Recovery
Parlare di backup al giorno d’oggi, potrebbe risultare anacronistico.
In un trend di crescita esponenziale dei dati, non è possibile prescindere da sistemi di recovery in grado di ripristinare i servizi anche a seguito di eventi disastrosi. Grazie alle infrastrutture as-a-service, dotarsi di un sito di Disaster Recovery non costituisce più un costo proibitivo come in passato.
Ma in un progetto di DR i sistemi che si preoccupano di copiare i contenuti dal sito primario verso i siti secondari, rappresentano uno dei fattori critici di successo.
Considerare Nakivo solo un sistema di backup potrebbe risultare riduttivo, dato che sempre con lo stesso prodotto è possibile replicare le macchine virtuali verso un’infrastruttura virtuale remota. In aggiunta, mediante l’opzione ReIP, è possibile applicare una nuovo piano di indirizzamento alle macchine che vengono ripristinate.
Non dimenticate però che un sistema di Disaster Recovery non riguarda solo l’ambito dei sistemi, ma deve essere integrato da un piano di ripristino della connettività sia “locale” che verso Internet.
Infine, nell’ultima versione di Nakivo è presente un vero e proprio workflow che permette automatizzare le operazioni ripristino dei sistemi. In questo modo si dispone di uno strumento che permette di testare ed effettuare il failover dei sistemi protetti nel sito primario.
NAKIVO, Inc. is a privately-held company founded in 2012. NAKIVO develops a fast, reliable, and affordable data protection solution for VMware, Hyper-V, and cloud environments.
Download Free Trial here: https://www.nakivo.com/resources/download/trial-download/
This post is sponsored by Nakivo, Inc. Thoughts and experiences come from my own.