Una domanda comunemente posta sull'utilizzo delle istantanee come strategia di protezione dei dati è il fatto che i dati "reali" e i dati snapshot si trovano sulle stesse unità. La perdita di tali unità causerebbe la perdita sia dei dati primari che del backup.

Si tratta di un problema valido. Le snapshot locali vengono utilizzate per le esigenze di backup e ripristino quotidiane, e in questo senso la snapshot è un backup. Quasi il 99% di tutti gli scenari di ripristino in ambienti NetApp si affida alle snapshot per soddisfare anche i requisiti RTO più aggressivi.

Gli snapshot locali, tuttavia, non dovrebbero mai rappresentare l'unica strategia di backup, motivo per cui NetApp offre tecnologie come SnapMirror e la replica SnapVault per replicare in modo rapido ed efficiente le snapshot su un set indipendente di dischi. In una soluzione adeguatamente progettata con istantanee e replica snapshot, l'utilizzo del nastro può essere ridotto a icona in un archivio trimestrale o eliminato del tutto.

Le copie Snapshot di ONTAP sono disponibili diverse opzioni per la protezione dei dati, mentre le snapshot sono alla base di molte altre funzionalità di ONTAP, tra cui replica, disaster recovery e cloning. Una descrizione completa della tecnologia snapshot non rientra nell'ambito di questo documento, ma le sezioni seguenti forniscono una panoramica generale.

Esistono due approcci principali per creare uno snapshot di un dataset:

Un backup coerente con i crash di un set di dati si riferisce all'acquisizione dell'intera struttura di set di dati in un singolo point-in-time. Se il set di dati è memorizzato in un singolo volume, il processo è semplice ed è possibile creare una Snapshot in qualsiasi momento. Se un set di dati si estende tra i volumi, è necessario creare uno snapshot del gruppo di coerenza (CG). Esistono diverse opzioni per la creazione di snapshot CG, tra cui il software NetApp SnapCenter, le funzionalità native del gruppo di coerenza ONTAP e gli script gestiti dagli utenti.

I backup coerenti con i crash vengono utilizzati principalmente quando è sufficiente un ripristino point-of-the-backup. Quando è richiesto un ripristino più granulare, sono in genere necessari backup coerenti con l'applicazione.

La parola "coerente" in "coerente con l'applicazione" è spesso un nome scorretto. Ad esempio, l'inserimento di un database Oracle in modalità di backup viene definito backup coerente con l'applicazione, ma i dati non vengono resi coerenti o disattivati in alcun modo. I dati continuano a cambiare durante il backup. Al contrario, la maggior parte dei backup di MySQL e Microsoft SQL Server disattivano i dati prima di eseguire il backup. VMware può o non può rendere certi file coerenti.

Il termine "gruppo di coerenza" si riferisce alla capacità di un array di archiviazione di gestire più risorse di archiviazione come una singola immagine. Ad esempio, un database può essere composto da 10 LUN. L'array deve essere in grado di eseguire il backup, il ripristino e la replica delle 10 LUN in modo coerente. Il ripristino non è possibile se le immagini dei LUN non erano coerenti nel punto di backup. La replica di queste 10 LUN richiede che tutte le repliche siano perfettamente sincronizzate l'una con l'altra.

ONTAP è sempre stato in grado di acquisire immagini coerenti di dati locali e replicati. Sebbene i vari volumi su un sistema ONTAP AFF/FAS non vengano solitamente descritti formalmente come un gruppo di coerenza, di fatto lo sono. Uno snapshot di quel volume è un'immagine del gruppo di coerenza, il ripristino di quello snapshot è un ripristino del gruppo di coerenza ed entrambi SnapMirror e SnapVault offrono la replica del gruppo di coerenza.

I sistemi AFF includono anche una tipologia più ampia di gruppi di coerenza. Più volumi possono essere definiti come un CG all'interno di ONTAP. Snapshot, cloni e repliche possono quindi essere configurati a livello di CG. Ciò semplifica le strategie di protezione dei dati, poiché consente di impostare policy sui dataset, non solo sui singoli volumi o LUN. I CG sono presenti anche nei sistemi ASA. Più LUN o namespace possono essere raggruppati come un CG e quel CG può quindi essere protetto tramite snapshot, replicato, ripristinato o clonato.

Gli snapshot dei gruppi di coerenza (CG) sono un'estensione della tecnologia Snapshot di ONTAP. Un'operazione di snapshot standard crea un'immagine coerente di tutti i dati all'interno di un singolo volume AFF/FAS o LUN/namespace ASA, ma a volte è necessario creare un set coerente di snapshot su più risorse di storage e persino su più sistemi di storage. Il risultato è un set di snapshot che può essere utilizzato allo stesso modo di uno snapshot di un singolo volume. Possono essere utilizzati per recovery di dati, replicati per scopi di disaster recovery o clonati come un'unica unità coerente.

Gli snapshot CG offrono un'ottima scalabilità. Il più grande utilizzo noto di uno snapshot CG riguarda un ambiente database di circa 1PB distribuito su 12 controller. Gli snapshot CG creati su questo sistema sono stati utilizzati per backup, recovery e clonazione.

Nella maggior parte dei casi, quando un set di dati si estende su volumi AFF o LUN/namespace ASA e l'ordine di scrittura deve essere preservato, è sufficiente definire un gruppo di coerenza ONTAP e gestire il gruppo di volumi, LUN o namespace in modo nativo per creare snapshot. Se si utilizza un software di gestione, questo dovrebbe rilevare la necessità di snapshot del gruppo di coerenza e richiamare le API necessarie.

In questi casi non è necessario comprendere i dettagli tecnici degli snapshot CG. Tuttavia, esistono situazioni in cui requisiti complessi di protezione dei dati richiedono un controllo dettagliato sul processo di protezione e replica dei dati. I flussi di lavoro automatizzati o l'utilizzo di script personalizzati per richiamare le API degli snapshot CG sono alcune delle opzioni. Per comprendere l'opzione migliore e il ruolo degli snapshot CG è necessaria una spiegazione più dettagliata della tecnologia.

La creazione di un set di snapshot di consistency group è un processo in due fasi:

Il fencing di scrittura viene stabilito in modo seriale. Ciò significa che, man mano che il processo di fencing viene impostato su più destinazioni di storage, l'I/O di scrittura viene bloccato sul primo oggetto della sequenza e continua a essere bloccato sulle destinazioni che compaiono successivamente nell'elenco. Inizialmente, questo potrebbe sembrare violare il requisito di preservazione dell'ordine di scrittura, ma ciò si applica solo all'I/O che viene eseguito in modo asincrono sull'host e non dipende da altre scritture.

Ad esempio, un database potrebbe eseguire numerosi aggiornamenti asincroni del file dati, consentendo al sistema operativo di riordinare l'i/o e completarli in base alla propria configurazione dell'utilità di pianificazione. L'ordine di questo tipo di i/o non può essere garantito perché l'applicazione e il sistema operativo hanno già rilasciato il requisito di mantenere l'ordine di scrittura.

A titolo di controesempio, la maggior parte delle attività di logging del database è sincrona. Il database non procede con ulteriori scritture di log finché l'I/O non viene confermato e l'ordine di tali scritture deve essere preservato. Se un'I/O di log arriva su una LUN isolata, non viene confermata e l'applicazione si blocca durante le scritture successive. Allo stesso modo, l'I/O dei metadati del file system è solitamente sincrono. Ad esempio, un'operazione di eliminazione di un file non deve andare persa. Se un sistema operativo con un file system xfs elimina un file e l'I/O che aggiorna i metadati del file system xfs per rimuovere il riferimento a quel file arriva su una LUN isolata, allora l'attività del file system si interrompe. Ciò garantisce l'integrità del file system durante le operazioni di CG.

Una volta configurato il write fencing tra i target, questi sono pronti per la creazione degli snapshot. Gli snapshot non devono necessariamente essere creati contemporaneamente, poiché lo stato dei target viene congelato dal punto di vista della scrittura dipendente. Per proteggersi da eventuali vulnerabilità nell'applicazione che crea gli snapshot del gruppo di coerenza, il write fencing iniziale include un timeout configurabile in cui ONTAP rilascia automaticamente il fencing e riprende l'elaborazione di scrittura dopo un numero definito di secondi. Se tutti gli snapshot vengono creati prima dello scadere del timeout, il set di snapshot risultante costituisce un gruppo di coerenza valido.

Esistono due approcci principali ai backup basati su snapshot:

Un backup coerente con il crash di un database si riferisce all'acquisizione dell'intera struttura del database, inclusi datafile, redo log e file di controllo, in un singolo point-in-time. Se il database è memorizzato in un singolo volume, LUN o namespace, il processo è semplice; è possibile creare uno snapshot in qualsiasi momento. Se un database si estende su volumi AFF o LUN/namespace ASA, è necessario creare uno snapshot di un gruppo di coerenza (CG). Esistono diverse opzioni per la creazione di snapshot CG, tra cui NetApp SnapCenter software, funzionalità native dei gruppi di coerenza ONTAP e script gestiti dall'utente.

I backup snapshot coerenti con il crash vengono utilizzati principalmente quando è sufficiente il recovery point-in-time del backup. I log di archivio possono essere applicati in alcune circostanze, ma quando è richiesto un recovery point-in-time più granulare, un backup online è preferibile.

La procedura di base per un backup online basato su snapshot è la seguente:

Questa procedura produce una serie di istantanee contenenti file di dati in modalità backup e i registri di archivio critici generati in modalità backup. Questi sono i due requisiti per il ripristino di un database. I file come i file di controllo dovrebbero essere protetti per comodità, ma l'unico requisito assoluto è la protezione per i file di dati e i registri di archivio.

Sebbene i diversi clienti possano avere strategie molto diverse, quasi tutte queste strategie si basano in ultima analisi sugli stessi principi delineati di seguito.

Quando si progettano le configurazioni di storage per i database Oracle, la prima decisione da prendere riguarda se utilizzare la tecnologia NetApp SnapRestore basata sui volumi (VBSR), che è la tecnologia sottostante utilizzata per il ripristino dei volumi AFF e dei LUN/namespace ASA.

VBSR consente di ripristinare i dati a un punto precedente nel tempo in modo quasi istantaneo. Poiché tutti i dati vengono ripristinati, VBSR potrebbe non essere appropriato per tutti i casi d'uso. Ad esempio, se un intero database, inclusi datafile, redo log e archive log, è memorizzato su un singolo AFF volume e questo volume viene ripristinato con VBSR, i dati andranno persi perché i dati di archive log e redo più recenti verranno scartati. Lo stesso vale per i dati ASA. Se l'intero database è stato memorizzato in un singolo ASA consistency group e quel CG è stato ripristinato a uno stato precedente, alcuni dei dati di archive log e redo più recenti andranno persi.

VBSR non è necessario per il ripristino. Molti database possono essere ripristinati utilizzando il ripristino a file singolo basato su file SnapRestore (SFSR) o semplicemente clonando i file dallo snapshot nel file system attivo.

VBSR è preferibile quando un database è molto grande o quando deve essere ripristinato il più rapidamente possibile, e l'utilizzo di VBSR richiede l'isolamento dei datafile. In un ambiente NFS, i datafile di un determinato database devono essere archiviati in volumi dedicati non contaminati da altri tipi di file. In un ambiente SAN, i datafile devono essere archiviati in LUN o namespace dedicati. Se si utilizza un volume manager (incluso Oracle Automatic Storage Management [ASM]), anche il disk group deve essere dedicato ai datafile.

Isolando i file di dati in questo modo, è possibile ripristinarli a uno stato precedente senza danneggiare altri file system.

Per ogni volume con dati Oracle in un ambiente AFF SAN, il percent-snapshot-space dovrebbe essere impostato a zero perché riservare spazio per uno snapshot in un ambiente LUN non è utile. Se la riserva frazionaria è impostata a 100, uno snapshot di un volume con LUN richiede abbastanza spazio libero nel volume, escludendo la riserva di Snapshot, per assorbire il 100% di turnover di tutti i dati. Se la riserva frazionaria è impostata su un valore inferiore, è richiesta una quantità di spazio libero corrispondentemente inferiore, ma esclude sempre la riserva di Snapshot. Ciò significa che lo spazio di riserva di Snapshot in un ambiente LUN viene sprecato.

In un ambiente NFS, esistono due opzioni:

Con la prima opzione, percent-snapshot-space è impostato su un valore diverso da zero, in genere intorno al 20%. Questo spazio viene quindi nascosto all'utente. Tuttavia, questo valore non crea un limite di utilizzo. Se un database con una prenotazione del 20% registra un fatturato del 30%, lo spazio snapshot può crescere oltre i limiti della riserva del 20% e occupare spazio non riservato.

Il vantaggio principale dell'impostazione di una riserva a un valore come 20% è verificare che una parte di spazio sia sempre disponibile per gli snapshot. Ad esempio, un volume da 1TB TB con una riserva del 20% consentirebbe all'amministratore di database (DBA) di memorizzare 800GB TB di dati. Questa configurazione garantisce almeno 200GB GB di spazio per il consumo di snapshot.

Quando percent-snapshot-space è impostato su zero, tutto lo spazio nel volume è disponibile per l'utente finale, il che garantisce una migliore visibilità. Un DBA deve capire che, se rileva un volume di 1TB GB che sfrutta le snapshot, questo 1TB GB di spazio viene condiviso tra i dati attivi e il turnover di Snapshot.

Non esiste una chiara preferenza tra l'opzione 1 e l'opzione 2 tra gli utenti finali.

Oracle Doc ID 604683,1 illustra i requisiti per il supporto di snapshot di terze parti e le varie opzioni disponibili per le operazioni di backup e ripristino.

Il fornitore di terze parti deve garantire che le istantanee dell'azienda siano conformi ai seguenti requisiti:

I prodotti di gestione ONTAP e NetApp di Oracle sono conformi a questi requisiti.