Categories
CommVault

Come gli snapshot consentono di migliorare il backup

Roy Child, product specialist di Commvault

I punti di vista su snapshot e backup sono diversi. Alcuni sostengono che gli snapshot non possano avere da soli il ruolo del backup, e abbiano bisogno di integrarsi con il backup per assicurare il ripristino. Molte aziende hanno capito di aver bisogno di snapshot per risolvere le sfide di backup e ripristino dei dati critici, ma senza dotarsi di uno strumento di integrazione degli snapshot all’interno del ciclo di vita dei dati, si finisce per creare nuovi problemi invece di risolverli. In realtà, gli snapshot possono davvero migliorare il backup.

Riservare i server di produzione alla produzione effettiva
Gli snapshot apportano numerosi benefici. Sono in grado di eliminare i carichi di backup dai sistemi di produzione. Si effettuano in pochi secondi, in modo che le applicazioni di produzione principali non debbano sopportare per ore carichi di lavoro significativi. Carichi che possono essere trasferiti su un server proxy separato, che esegue il backup per conto della produzione. È possibile consolidare i backup di più server di produzione attraverso lo stesso proxy per incrementare l’efficienza.

Anche l’offload del backup crea nuove sfide  
È più semplice dirlo che farlo. Utilizzare strumenti separati per snapshot e backup conduce a una possibile disconnessione nell’ambiente di backup che porta con sé gravi implicazioni per la gestione e il ripristino. Se i backup avvengono sul server proxy, lo strumento di backup è a conoscenza solo di quello che succede sul proxy. Il server proxy, e quindi il tool di backup, non sono al corrente di quanto fanno i server di produzione, che conservano file importanti, e nemmeno di database o applicazioni che potrebbero esservi in esecuzione.
Perché questo è importante? Bisogna tenere in considerazione queste differenze. L’ambiente di produzione cambia e cresce, ed è quindi necessario mantenere aggiornati snapshot e backup. Quando si devono ripristinare i dati, si presentano alcune sfide aggiuntive. In primo luogo, bisogna sapere esattamente quali file recuperare per ogni database. È necessaria inoltre la presenza di un amministratore di database che lo ripristini e lo riporti in un determinato punto nel tempo, perché non è possibile utilizzare la funzionalità acquistata nel tool di backup.
Inoltre, per essere certi di effettuare il restore dei file corretti nella posizione giusta, serve conoscere esattamente l’origine di provenienza dei dati, tenendo in considerazione che il tool di backup non ha informazioni sulla produzione. Il monitoraggio diventerà quindi fondamentale all’interno della strategia di ripristino.
È un processo molto rapido. Ogni database, disco, VM, file system, server, sistemi storage e proxy che viene aggiunto allo snap rende la lista più lunga e la ricerca più difficile. Inoltre, è importante ricordare che bisogna aggiornare il monitoraggio dei dati ogni volta che l’ambiente cambia. In caso di ripristino su larga scala, sbloccare tutte le relazioni per realizzare il ripristino potrebbe aggiungere ore al tempo di inattività generale.
Un altro elemento che spesso si considera solo all’ultimo momento è la visibilità, specialmente quando si parla di soluzioni scripted. Lo strumento di backup fornisce report e alert per avvisare quando la situazione non sta funzionando in modo adeguato, ma è altrettanto importante che avvisi quando tutto funziona correttamente. La soluzione di gestione degli snapshot deve fare lo stesso.
Si tratta di problematiche dovute al mancato collegamento tra gli strumenti, indipendentemente dalla buona qualità di snapshot e backup. E sono problematiche che vanno affrontate.

Uno strumento unico per gestire snapshot e backup
Quando lo strumento di backup gestisce anche gli snapshot, tutta questa complessità svanisce. Il tool registra tutte le informazioni proxy, gestisce gli elementi di integrazione – OS, hypervisor, database – per assicurare il ripristino e consentire di recuperare un database sotto forma di database, anche in uno specifico momento nel tempo, senza necessità di un amministratore di database. È possibile standardizzare un processo di recovery per snapshot e backup e ottenere la visibilità operativa necessaria senza duplicare report o dover apprendere nuove capacità.
È importante notare che anche se il tool di backup gestisce gli snapshot, potrebbe comunque avere problemi nel backup se la soluzione non supporta tutte le applicazioni o lo storage. Bisognerà utilizzare script e processi manuali per risolvere ogni gap, con tutti i problemi descritti in precedenza.

Lo scripting non è la risposta
Si tratta di una situazione che ho vissuto in prima persona. Quando lavoravo come ingegnere IT, avevamo un’applicazione che doveva effettuare backup coordinati e coerenti su una coppia di server. I dati erano troppi e troppo complessi per poter eseguire i backup in produzione e restare nei tempi previsti. Avremmo avuto bisogno di snapshot, ma a quei tempi non esistevano soluzioni di gestione degli snapshot per il nostro storage. Ho dovuto fare lo script.
La soluzione scripted lavorava molto come ho descritto. Il backup degli snapshot avveniva attraverso un server proxy, senza consapevolezza dei database SQL o dei server di origine. Il ripristino è sempre stato un grosso problema, perché oltre a controllare le relazioni per essere certi che stessero recuperando i dati, l’amministratore doveva ripristinare il database e i file su entrambi i server nello stesso momento nel tempo.
Abbiamo dovuto lavorare con questo processo per molti anni, ed è stato complicato. Dovevamo aggiornare spesso i file di configurazione quando il team applicativo aggiungeva dischi e in più occasioni qualcuno dimenticava un aggiornamento e interrompeva il backup. Senza considerare migrazioni di server e storage che richiedevano modifiche di configurazione ancora più grandi e fasi di test impegnative. Cambiando soluzioni di backup, abbiamo dovuto rielaborare completamente il processo.
A causa della complessità, abbiamo sempre utilizzato la soluzione solo su due di queste coppie di server, e anche se l’ambiente era contenuto nelle dimensioni, il tempo necessario per la manutenzione e la risoluzione dei problemi del processo era tanto. Onestamente, non ce ne saremmo nemmeno preoccupati se non avessimo potuto trovare le finestre di backup in altro modo.
Se avessi potuto realizzare questo processo con una soluzione performante, non avrei dovuto scrivere script, né gestire file di configurazione, né avere conoscenza SQL e componenti da monitorare. La reportistica e gli alert avrebbero incluso backup e snapshot. Il ripristino sarebbe stato semplice e le migrazioni storage sarebbe state virtualmente un non-evento.
In breve, gli snapshot sarebbero stati così integrati con il backup da non accorgersi neanche della loro presenza, oltre a non appesantire ulteriormente l’ambiente di produzione. E questo livello di integrazione rappresenta il modo in cui gli snapshot migliorano il backup. In questa era di singole soluzioni “abbastanza efficaci”, è facile trascurare i costi nascosti e le sfide che da essi derivano, fino al momento in cui non ci si trova ad affrontarli, di solito nella peggiore occasione possibile.