Le snapshot di NetApp possono essere utilizzate come backup?

Il nostro negozio fa molto affidamento sulle snapshot del volume di NetApp per i backup. Utilizziamo alcuni tradizionali backup su nastro basati su agenti per alcuni dei nostri dati, ma in generale facciamo affidamento sugli Snapshot per la maggior parte dei nostri sistemi. Inoltre non abbiamo una politica rigorosa di controllo delle modifiche o qualsiasi gestione della configurazione centralizzata in modo tuttodei nostri server, indipendentemente dal fatto che venga eseguito il backup dei dati forniti dai loro servizi, dovrebbe essere ricostruito da bare metal (e senza alcuna documentazione reale). Naturalmente, questo rende le snapshot una proposta molto interessante per la gestione perché possiamo semplicemente ripristinare l'intero server, i dati utente e la configurazione inclusi. Usiamo la Virtual Storage Console di NetApp per creare istantanee dei nostri datastore VMware basati su NFS e SnapDrive di NetApp per LUN (fisici) mappati su dispositivi grezzi che vengono presentati direttamente agli ospiti. Abbiamo snapshot di SnapMirror critici fuori sede a un altro Filer. Naturalmente testiamo regolarmente il nostro processo di ripristino.

Non posso fare a meno di sentirmi a disagio con la nostra dipendenza dalle istantanee sui backup. Per me, affinché una tecnologia sia considerata sufficiente come strategia di backup, deve soddisfare i seguenti criteri:

• Il backup deve essere atomico. Vale a dire, il backup non può fare affidamento su nient'altro per il suo recupero.
• Il backup deve essere separato dal sistema di cui è un backup (fuori banda).
• Il backup deve essere copiato o trasportato su un sito remoto (fuori sede)

Sono consapevole che le snapshot di NetApp funzionano secondo una metodologia di reindirizzamento su scrittura (RoW). Il layout del file WAFL utilizza una serie di puntatori (metadati?) Che in realtà fanno riferimento a ciascun blocco di archiviazione, ovunque esso sia. Per creare un'istantanea, il sistema prende semplicemente una copia dei metadati di un volume e lo memorizza nello spazio riservato di quel volume. Qualsiasi scrittura (creazioni / modifiche / cancellazioni) viene reindirizzata a nuovi blocchi. Questa dovrebbe essere la salsa speciale che rende WAFL di NetApp così eccezionale perché non devi fare la lettura e quindi scrivere i vecchi dati nello spazio riservato e quindi scrivere i tuoi nuovi dati sopra i vecchi come gli snapshot Copy-On-Write.

Ammetto pienamente che potrei non capire esattamente come funzionano gli snapshot di volume di NetApp, ma se la mia comprensione è più o meno corretta, gli snapshot di NetApp non soddisfano i miei criteri per i backup.

• Sono Non atomica. Lo "snapshot" è in realtà solo un insieme di puntatori ai dati originali. Se i dati originali non sono più presenti, i metadati sono inutili.
• L'istantanea non è separata dal sistema. Se qualcuno elimina il volume sbagliato, perdo l'istantanea. Se NetApp Filer esplode in piccoli gattini, perdo il backup. Posso usare SnapMirror per spostare le mie istantanee su un altro Filer ma, di nuovo, sta semplicemente spostando i metadati e non i blocchi effettivi. Se perdo il volume originale, non riesco a vedere come sarà utile un'istantanea copiata su un altro Filer.

Qualcuno può spiegare come gli snapshot di NetApp possono essere considerati backup? Sto cercando buone risposte soggettive, quindi per favore sostieni la tua posizione con fatti, riferimenti ed esperienza. Se la mia comprensione della tecnologia di base non è corretta, spiega dove e perché ciò modifica le mie conclusioni. Se il tuo negozio si affida alle snapshot di NetApp come backup, includi sufficienti informazioni contestuali in modo che le persone possano avere un'idea del tipo di politica di recupero che devi soddisfare.

I backup hanno due funzioni.

• Innanzitutto, sono lì per consentirti di recuperare i tuoi dati se non sono disponibili. In questo senso, le istantanee non sono backup. Se si perdono dati sul filer (eliminazione del volume, danneggiamento della memoria, errore del firmware, ecc.), Anche tutte le istantanee per tali dati andranno perse.
• In secondo luogo, e molto più comunemente, i backup vengono utilizzati per correggere cose di routine come eliminazioni accidentali. In questo caso d'uso, le istantanee sono backup. Sono probabilmente uno dei modi migliori per fornire questo tipo di recupero, perché rendono le versioni precedenti dei dati disponibili direttamente agli utenti o al loro sistema operativo come directory nascosta .snapshot da cui possono leggere direttamente il loro file.

Nessuna politica di conservazione

Detto questo, mentre disponiamo di istantanee e le utilizziamo ampiamente, eseguiamo comunque incrementi notturni su Netbackup su nastro o dominio di dati. Il motivo è che le istantanee non possono sostenere in modo affidabile una politica di conservazione. Se dici agli utenti che potranno eseguire il backup da una granularità giornaliera per una settimana e poi da una granularità settimanale per un mese, non puoi mantenere questa promessa con le istantanee.

Su un volume Netapp con snapshot, i dati eliminati contenuti in un'istantanea occupano spazio "riserva di snap". Se il volume non è pieno e lo hai configurato in questo modo, puoi anche superare la riserva dell'istantanea e avere istantanee che occupano parte dello spazio dati inutilizzato. Se il volume si riempie, tuttavia, verranno eliminate tutte le istantanee tranne quelle supportate dai dati nello spazio riservato. L'eliminazione delle istantanee è determinata solo dallo spazio disponibile per le istantanee e, se è necessario eliminare le istantanee necessarie per il criterio di conservazione, lo farà.

Considera questa situazione:

• Un volume completo con istantanee regolari e un requisito di conservazione di 2 settimane.
• Supponiamo che metà della riserva in uso per le istantanee si basi sulla normale velocità di variazione.
• Qualcuno elimina molti dati (oltre alla riserva di istantanee), aumentando drasticamente la velocità di modifica, temporaneamente.

A questo punto, la tua riserva di snapshot è completamente utilizzata, così come la maggior parte dello spazio libero di dati che hai permesso a OnTap di utilizzare per le snapshot, ma non hai ancora perso alcuna snapshot. Non appena qualcuno riempie il volume di backup con i dati, tuttavia, perderai tutte le istantanee contenute nella sezione dati, che riporterà il tuo punto di ripristino indietro nel tempo subito dopo l'eliminazione grande.

Sommario

Le istantanee di Netapp non ti coprono dalla reale perdita di dati. Un volume cancellato errato o la perdita di dati sul filer richiederà la ricostruzione dei dati.

Sono un modo molto semplice ed elegante per consentire semplici ripristini di routine, ma non sono abbastanza affidabili da sostituire una vera soluzione di backup. Il più delle volte, renderanno i ripristini di routine semplici e indolori, ma quando non sono disponibili, sei esposto.

Sono un backup, sì. Li ho usati personalmente al posto degli incrementali giornalieri prima, ma abbiamo comunque fatto dei full settimanali su nastro.

Proteggono abbastanza bene da eventuali errori o problemi di utenti non amministratori di netapp (sistemi che accedono a volumi).

Non proteggono da guasti hardware catastrofici dello stesso netapp. La mia comprensione è che SnapMirror copia tutti i dati (nell'istantanea) sull'altro filer [1], quindi SnapMirroring su un altro filer dovrebbe proteggere quel set di dati dall'errore catastrofico di un singolo filer.

L'unico problema principale, ovviamente, è che se qualcuno che gestisce netapp cancella il volume, tutte le istantanee vanno con esso. SnapMirror su un altro filer dovrebbe proteggerlo adeguatamente.

Se tutti i tuoi filer NetApp si trovano nello stesso data center, allora non hai nulla che copra un grave disastro, come ti darebbero i backup su nastro spediti fuori sede.

Otterrai backup migliori delle tue VM e di qualsiasi database (o cose simile al database) se usi l'agente SnapManager appropriato, che coordinerà la sospensione dei dati brevemente quando viene eseguita l'istantanea. Se una determinata VM e i suoi dati sono contenuti interamente in un singolo volume NetApp, l'istantanea di tale VM dovrebbe essere coerente con gli arresti anomali. Cioè, dovrebbe essere buono come se avessi staccato la spina su un server e immaginato l'unità, il che significherebbe in genere controlli del filesystem ed equivalenti del database. Se i dati di un database vengono suddivisi tra LUN, sembra che ci sia un rischio significativo di corruzione dei dati.

Se fossi in me, imposterei tutti i database per eseguire backup regolari sul disco locale e impostare quei lavori per conservare una o due copie. Questo ti dà una garanzia molto migliore di recuperabilità.

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

Dovresti andare a leggere l'eccellente risposta di @Basil in questo momento, ma ecco i miei due centesimi:

Le istantanee non sono a conoscenza dell'applicazione

Solo perché si acquisisce un'istantanea del volume di archiviazione sottostante non significa che i dati su quel volume siano recuperabili. MS SQL ne è un ottimo esempio: è necessario assicurarsi che il database sia coerente con le transazioni prima di eseguire l'istantanea dello spazio di archiviazione che utilizza altrimenti, poiché @freiheit ha indicato che non è meglio che recuperare da un errore grave . Gli amministratori di database adorano utilizzare LUN diversi per parti diverse di SQL per utilizzare meglio il sistema di archiviazione, i database temporanei su archiviazione veloce, i database di sistema su archiviazione più lenta, i dati di sola lettura o archiviati sull'archiviazione di massa e i dati di lavoro nel mezzo. Se stai semplicemente eseguendo un'istantanea di quei volumi, è altamente improbabile che sarai in grado di recuperare il tuo database.

NetApp fornisce una serie di strumenti Snap per rendere consapevole l'applicazione degli snapshot. SnapManager per SQL fornisce questa consapevolezza. Nell'ecosistema Microsoft credo che ci siano anche strumenti SnapManager per Exchange e SharePoint. SnapDrive non ha questa consapevolezza dell'applicazione. Fornisce semplicemente un metodo conveniente per gestire l'archiviazione all'interno del guest.

Se si memorizzano tutti i dati IIS e la configurazione su LUN e si esegue l'istantanea di tali LUN direttamente, non è possibile garantire che i dati siano recuperabili. Chiedimi come lo so ...

Più tipi di archiviazione possono avere pianificazioni di istantanee diverse

Se si sta presentando spazio di archiviazione ai server in modi diversi, ciò può complicare l'immagine di snapshot e di ripristino. ONTAP di NetApp è un'offerta multiprotocollo ed è molto probabile che tu stia utilizzando più di un metodo o tipo di archiviazione per un determinato server. Nel nostro negozio alcuni dei nostri server ottengono la loro unità C: \ su un archivio dati basato su NFS e le loro unità di "archiviazione" su LUN Raw Device Mapped. Stavamo scattando delle istantanee dei LUN RDM ma non dei datastore basati su NFS. Ciò ha reso difficile il ripristino del server .

Le istantanee non hanno una politica di conservazione garantita

Ancora una volta, @Basil lo copre davvero bene, ma vale la pena ripeterlo . È possibile riempire la tua riserva di riserva in modo tale che la cancellazione automatica di Snpashot rimuova le istantanee che non sono invecchiate naturalmente alla cancellazione. Ancora. Questo può essere davvero negativo se tu o i tuoi clienti prevedete che siano disponibili tre settimane di istantanee.

Le istantanee sono in linea

Questo è lo svantaggio dello storage integrato ... è ben ... integrato. Le tue istantanee risiedono sulla stessa piattaforma di cui stai eseguendo il backup. Se il volume o il Filer su cui è attivo scompare, anche il backup. Puoi mitigarlo in qualche modo copiando le istantanee su un altro Filer usando SnapMirror come ho erroneamente affermato nella mia domanda che la copia di SnapMirror non è una copia completa.

Le istantanee consentono alle pratiche operative errate di continuare

Una cosa che ho notato è che le istantanee consentono ai manager e ai clienti di continuare a comportarsi in modo terribile. Nel nostro ambiente abbiamo pratiche di gestione della configurazione e della documentazione molto scadenti. Ciò significa che la maggior parte dei server inizia con la stessa base (un modello o un'immagine) ma viene quindi configurata manualmente da diversi gruppi di persone. Mentre continuano la loro vita, i server divergono sempre più dal modello in modi che generalmente non sono documentati o implementati con la gestione della configurazione.

E poi arrivano le istantanee! Non abbiamo bisogno di fare un passo indietro e affrontare alcune delle nostre pratiche operative fondamentali perché possiamo semplicemente snapshot tutti i nostri server! E possiamo usare SnapMirror per spostare quelle istantanee fuori sede in modo da poterle usare come backup!

Penso che questa sia la lezione sbagliata da imparare qui. Una lezione migliore da imparare è che è necessario eseguire il backup del framework di gestione della configurazione, anche se semplice come un log delle modifiche, ai fini del ripristino bare metal. Le istantanee sono uno strumento fantastico, ma posso tentare di fare eccessivamente affidamento su di esse per scoraggiare importanti fondamenti.