Vincenzo Costantino, EMEA South Technical Services Director di Commvault, svela le best practice per una data protection efficace, tra snapshot e repliche remote. Vi sono molte aziende che si avvalgono degli snapshot per attività di data protection. Fino a qualche anno fa, le best practice prevedevano l’utilizzo di uno snapshot transiente che veniva cancellato immediatamente dopo l’uso – non uno snapshot per ogni volume; uno snapshot per l’intero array. I tempi sono cambiati e le tecnologie si sono evolute. Tuttavia non tutte le piattaforme storage sono uguali ed è importante comprendere i casi d’uso quando si vogliono considerare gli snapshot quale parte della funzione di data protection. Una singola operazione di data protection può comprendere molteplici tipologie di snapshot, che operano insieme, per ottenere il risultato desiderato. Quindi, anche se gli snapshot rappresentano un componente critico, sono anche parte di una soluzione completa che indirizza l’orchestrazione di dati e infrastruttura a diversi livelli.
Esiste un delicato equilibrio tra uno snapshot e uno snapshot application persistent dato che le attività di data protection e gli snapshot non sono intercambiabili. Infatti, in base a test da noi effettuati che confrontavano la protezione con soli snapshot nativi con quella dotata di orchestrazione in aggiunta agli snapshot nativi, nove volte su dieci il database non è tornato ‘pulito’ e tutte e 10 gli snapshot delle VM avevano problemi. Perché? Uno snapshot è valido tanto quanto i dati che vengono fotografati. Se i dati sono in fase di scrittura attiva, bisogna tenere conto anche di buffer e cache. Se poi ci aggiungiamo la virtualizzazione, sono numerosi i layer coinvolti, ecco perché un backup application consistent è così importante come punto di ripristino. L’utilizzo corretto degli snapshot rappresenta un’ottima linea di difesa, ma non dovrebbero essere l’unica. Cosa fare quindi? Creare una copia alternativa su disco? Inviarla nel cloud? Replica e poi cloud? Replica su un altro array?
Replicare su un altro array può estendere le funzionalità degli snapshot su un sito alternativo, ma è sempre sulla stessa piattaforma storage gestita da persone, che possono commettere errori. Rendere il processo di snapshot e replica una parte integrante della strategia di protezione e conservazione è importante, ma per farlo i dati devono essere coerenti e affidabili dall’inizio alla fine del processo. Accesso e recovery dei dati protetti è qualcosa che richiedono utenti finali, application owner e storage admin. Ma non si concede a un utente l’accesso diretto allo storage array per recuperare uno snapshot ed è qui dove si evidenzia un altro aspetto critico legato all’uso degli snapshot per scopi di data protection. Nel processo di ripristino è possibile accelerare l’RTO di un cliente eliminando una serie di passaggi. Tuttavia, se l’azienda ha un RPO/RTO di 15 minuti, soddisfare l’RPO con script può essere già difficile, farlo in 15 minuti quasi impossibile data la mole di richieste che gli storage manager ricevono. Consentire ai clienti di ripristinare i propri dati è fondamentale e gli snapshot devono quindi essere integrati nel sistema di data protection.
Anche gli script possono diventare ingestibili. Essere in grado di identificare automaticamente i dati, dove risiedono, e su quale infrastruttura storage è fondamentale per l’uso continuo degli snapshot. Modificare la classe di un array o cambiare il vendor può modificare il linguaggio o l’interfaccia. Gli snapshot possono quindi costituire una prima linea di difesa in uno scenario di data protection se usati nel modo giusto. Ovviamente, come per tutti i sistemi di protezione dati validi, sapere quali tecnologie offrono il ripristino migliore è critico e adottare un approccio stratificato per prevedere molteplici aspetti e scenari di malfunzionamento cruciale.
