Esiste un buon modo per eseguire il backup di un petabyte di dati e archiviarlo?

Sto iniziando a vedere clienti con centinaia di terabyte di dati (nelle installazioni di SQL Server). Mentre il volume totale di dati in alcune aziende si avvicina a frazioni significative di un petabyte, mi piacerebbe tracciare la base di conoscenza collettiva là fuori per vedere cosa stanno facendo le persone con quella grandezza di dati per proteggerli.

Il problema ovvio è che l'archiviazione di più backup di molti dati è proibitivamente costosa, utilizzando l'archiviazione di classe enterprise, diamine, anche solo RAID-5.

Le opzioni che vedo sono le seguenti:

1. Crea una copia speculare dei dati in un altro centro dati e invia continuamente differenze (utilizzando qualsiasi meccanismo disponibile per l'origine dati, ad esempio invio di log o mirroring del database con SQL Server)
2. Esegui backup regolari utilizzando un pesante algoritmo di compressione (probabilmente adatto solo se i dati si prestano bene ad essere fortemente compressi)
3. Eseguire backup frammentari delle parti critiche / che cambiano i dati.
4. Non fare il backup dei dati e fidati degli dei della corruzione.

Sto vedendo l'opzione n. 4 essere adottata come predefinita e come esperto di HA / DR è davvero spaventoso, ma cosa posso consigliare in alternativa? Penso che il n. 1 sia l'approccio migliore, ma "Non credo" è la solita risposta quando vengono suggerite alternative diverse dal n. 4 e forse dal n. 3.

Ora, ovviamente, dipende dal tasso di variazione e dalla criticità dei dati. Non c'è bisogno di rispondere a questo dato che ero responsabile di tutte le funzionalità HA di SQL Server mentre lavoravo in Microsoft, quindi sono ben versato negli argomenti "dipende" - questa è la mia frase di parole :-)

Sarei molto interessato a conoscere le alternative che ho perso o a sentire che tutti gli altri sono nella stessa barca e non esiste alternativa realistica a spendere un sacco di soldi per più spazio di archiviazione.

Grazie in anticipo - verrà dato il dovuto credito a tutte le risposte ben ponderate ed espresse.

Off the wall idea: tutte le informazioni memorizzate sono necessarie o addirittura utili?

Quanto valgono effettivamente le informazioni? Sembra ovviamente ridicolo spendere di più per la manutenzione e la gestione di quanto valgano i dati.

I dati nel database sono appropriati per l'archiviazione in un database? Ad esempio, la conservazione di file core multi-gigabyte compressi nel database dell'organizzazione di supporto offre davvero vantaggi reali?

Ci sono molti dati duplicati nel database? Ad esempio, migliaia di persone conservano dieci copie ciascuna di una newsletter settimanale da 10 MB?

Alcuni dei dati hanno una "data di scadenza" dopo la quale non fornisce alcun valore? Tornando all'esempio dell'organizzazione di supporto, per vari motivi non vi è praticamente alcun vantaggio nel mantenere i file core dei clienti più di qualche mese dopo la consegna di una correzione.

Un altro pensiero: mantenere tanti dati che aprono l'azienda alle passività. Alcuni dati uno deve, per legge, conservare. Alcuni dati, tuttavia, dovrebbero essere "distrutti" a causa dei rischi presentati se vengono accidentalmente o intenzionalmente rilasciati a terzi inappropriati.

Sì, un'altra opzione è la virtualizzazione dello storage: un dispositivo che si trova tra i tuoi server e la SAN, come IBM SVC. SVC gestisce le copie da SAN a SAN e può eseguire la replica remota (anche se ovviamente è piuttosto doloroso a livello di petabyte a meno che non si disponga di tassi di modifica dei dati davvero bassi e larghezza di banda davvero elevata).

La parte liscia è che l'intero processo è invisibile ai server coinvolti. Se si utilizza SQL Server, si progettano i filegroup per tenere insieme le cose con un basso tasso di variazione (come archivi di vendita> 3 anni fa) e le cose con un alto tasso di variazione (come le vendite correnti) in un filegroup separato. Non devono nemmeno essere completamente di sola lettura: vuoi solo progettarlo in modo da poter utilizzare diversi metodi di replica per ogni filegroup. La SAN Gear può sincronizzare i Luns tramite rete, nastro o SAN: ciò significa che è possibile spedire parti della SAN avanti e indietro. Questo è più efficace con attrezzi come LeftHand's, in cui la SAN è composta da un pool di unità partecipanti.

Quindi è possibile sincronizzare automaticamente gli elementi a bassa velocità di cambio sul filo e sincronizzare l'alto tasso di cambio con sneakernet. (Sembra che l'ho fatto al contrario, ma è vero - non puoi sincronizzare le cose ad alta frequenza di cambio sul filo a causa del volume.) Anche alcuni degli ingranaggi di fascia bassa lo adattano ora: LeftHand ti consente di replicare ad altri Unità LeftHand nel tuo datacenter, quindi spedirle al tuo datacenter offsite. Collegali, uniscili al lato remoto modificando IP e gruppi e ora fanno parte della tua SAN di backup remoto. Il tono di vendita di LeftHand su questo è semplicemente geniale: configura le tue due SAN fianco a fianco nel tuo datacenter primario, sincronizzale, quindi puoi spedire parti di esse al datacenter remoto mentre alcune rimangono nel tuo attuale datacenter da mantenere sincronizzato. Sposta gradualmente "

Non l'ho ancora fatto a livello di petabyte. Sai cosa dicono: in teoria, in teoria e in pratica sono uguali. In pratica...

L'opzione 1 è il mirroring, che è quasi altrettanto grave di # 4: qualsiasi bug che corrompe i dati e non viene scoperto immediatamente, corromperà entrambe le copie.

Se i dati sono critici, prendere in considerazione soluzioni dedicate; leggi sui prodotti Shark di IBM, ad esempio, o prodotti concorrenti di EMS, ecc. Hanno funzionalità come Flash-copy, che ti consentono di creare istantaneamente una copia logica del file senza raddoppiare i requisiti del disco; e quindi è possibile eseguire il backup di questa copia su (es.) nastro. Cerca anche nel backup su nastro robotico.

Fai notare a coloro che vogliono archiviare un Petabyte di dati che l'archiviazione non è economico.

Sono così stufo delle persone che si lamentano di non avere un Terabyte in più di spazio di archiviazione online perché il disco è economico - il disco potrebbe esserlo, ma lo spazio di archiviazione gestito sicuramente non lo è.

Se l'archiviazione dei backup è proibitivamente costosa, l'archiviazione dei dati è proibitiva in modo sicuro, pertanto la soluzione proposta non è praticabile.

Uno dei motivi più importanti per avere i backup è la protezione dagli errori dell'utente (la maggior parte dei problemi di errore hardware può essere risolta da soluzioni hardware) ma anche il mirroring del database non è una protezione contro una tabella eliminata (OK, puoi proteggerti da questo, ma è ancora possibile ottenere guff inamovibili nel tuo DB - a meno che la ragione per cui il DB è così grande sia che emette solo inserti).

Dal mio punto di vista, il nastro non è più una soluzione praticabile: ora è più economico lavorare con gli array di dischi (sebbene l'archiviazione fisica possa essere scomoda). Quindi penso che la tua unica opzione sia un metodo per suddividere i dati in blocchi abbastanza piccoli da poter essere ripristinati in un lasso di tempo ragionevole e poi trasferirli su memoria del disco su base regolare (e qui le soluzioni di tipo EMS possono aiutare, se hai il denaro contante).

Video interessanti che descrivono l'architettura di myspace.com (backend SQL2005). Non sono sicuro se hanno singoli db petabyte mentre si espandono con più dbs. Usano i backup di snap SAN.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Certo, è ancora all'inizio, ma ci sono un certo numero di aree in cui ZFS è progettato per gestire proprio questo genere di cose. Prima di tutto è la capacità di gestire una grande quantità di dati, nonché una moltitudine di diversi dispositivi di archiviazione (locale, SAN, fibra, ecc.), Il tutto mantenendo i dati al sicuro con checksum e consapevolezza del "livello di violazione" della salute del dispositivo e fallimenti. In che modo questo aiuta a risolvere il backup di questi dati?

Un metodo consiste nell'utilizzare le istantanee. Scatta un'istantanea, inviala su nastro / disco / rete per il trasferimento al sito remoto. Le istantanee successive inviano solo i dati inviati e, se necessario, è possibile conservare i dati in tempo reale su entrambe le estremità.

L'altro è utilizzare il software Solaris Cluster in cui (purché si disponga di una larghezza di banda di rete sufficiente) è possibile avere un mirroring live tra due server e se uno si interrompe, il secondo può subentrare. È più adatto all'uso in cui l'alta disponibilità (HA) è importante, ma immagino che la maggior parte dei luoghi con così tanti dati vogliano l'HA.

E dici che ZFS non è supportato su Windows, il solito posto dove potresti trovare sqlserver, forse esegui Sun / ZFS sul backend e ti connetti via iSCSI. Forse è anche un'idea orribile, ma almeno vale la pena pensarci in modo da sapere cosa non fare.

Hai esaminato Amazon Glacier come opzione?

IMO, a meno che tu non abbia un qualche tipo di hardware a livello godzilla, se hai così tanti dati dovresti usare una tecnologia di compressione del backup. Conosco molto bene LiteSpeed, ma ci sono prodotti simili di altri fornitori e (ovviamente) una funzionalità simile è integrata in SQL2008. È possibile che non si ottenga una compressione da 10 a 1, ma riduce i requisiti di archiviazione per il backup e può anche ridurre i requisiti della finestra di backup. Se il tuo obiettivo è mantenere più set di backup (ieri più il giorno prima, più uno della scorsa settimana e uno dell'ultimo mese, o una serie di differenziali più fulls, che possono diventare molto grandi se cambi molti dati in il database), è una semplice questione di spazio di archiviazione.

Il backup basato su filegroup (IOW, inserisce dati non volatili su alcuni FG e il backup raramente) non sembra mai volare perché gli sviluppatori o gli utenti non decideranno o quali dati sono volatili e cosa no, e in brownfield scenari che spesso non puoi correre rischi.

Se un sito di failover è un requisito, oltre a pensare a Database Mirror), potresti voler parlare con il fornitore di archiviazione dei tuoi clienti per vedere se offrono qualcosa come SRDF, che è una tecnologia di replica dei dati basata su hardware. Naturalmente, la replica (di qualsiasi tipo, ma particolarmente la replica in tempo reale o quasi in tempo reale) non sostituisce i backup.

Non credo che tu abbia molta scelta qui su nastro v. Disco. Il nastro probabilmente non lo taglierà in una normale finestra di backup a meno che non lo si rimuova e non sono sicuro che l'affidabilità sia lì.

Quindi sei nei backup del disco. Stai eseguendo il versioning? Significato ti preoccupi di tornare al backup 2 (backup db meno 2 backup correnti)? O backup 3? In tal caso, potresti avere problemi, ma probabilmente ciò che devi gestire sono i backup dei log, non così tanti backup dei dati.

Se puoi dividere alcuni dei dati come di sola lettura / non modificabili, allora forse hai dimensioni / finestre di backup gestibili. O almeno speri che la tecnologia di backup e la larghezza di banda stiano raggiungendo la crescita dei dati.

Non penso che tu stia eseguendo il backup tanto quanto stai conservando una seconda copia per recuperare da problemi con il tuo primario. Ciò significa hardware, corruzione, ecc. E preghi ogni giorno che gli errori non vengano inviati alla seconda copia. Molto probabilmente le copie vengono realizzate in SAN-SAN, con alcune tecnologie di snap-shot. anche se la copia originale potrebbe essere tramite Fed-Ex piuttosto che attraverso il filo. La larghezza di banda per spostare 100 TB non è facile da trovare per nessuno.

Penso che sia necessaria una combinazione di 1, 2 e 3 (non 4), con un'eccellente gestione del backup del registro.

In realtà penso che in qualsiasi momento tu stia davvero guardando 3 copie dei tuoi dati. Esecuzione di CHECKDB su 1 delle copie mentre la seconda copia viene utilizzata per ricevere effettivamente le modifiche. Quindi fai un'istantanea della seconda copia alla prima e continua. Con così tanti dati, immagino che avresti bisogno di un po 'di diligenza qui. Paul, come funziona checkdb su un db multiutente da 100 TB online?

Come accennato, i backup dei log e probabilmente un lettore di log non sono fondamentali? Non è necessario ripristinare tabelle di eliminazione / errore utente dai registri anziché un backup? Puoi potenzialmente abbreviare questo inviando copie SAN attraverso qualche ritardo, ma non ho visto quella tecnologia. Una SAN di log shipping che può ritardare le modifiche di 4 ore (o un certo intervallo) per consentire il recupero da problemi prima di sovrascrivere i dati. O qualche strumento per la modifica dei log-reader-of-SAN-block-changes? Senza questo, è necessario gestire quei registri delle transazioni, che potrebbero essere un altro livello di tracciamento di quei backup su vari file system per alcune ore xxx per consentire all'utente di recuperare potenzialmente da errori non fatali.

Tecnicamente, lo spazio di archiviazione è economico, ma a livello di petabyte, non così tanto. Dipende molto dall'applicazione, ma direi che una combinazione di strategia n. 2 e n. 3 sarà la risposta, con il n. 2 un dato e il n. 3 a seconda di quanto investimento è possibile effettuare nello storage e del tipo di archiviazione e potenza di elaborazione / I / O che ti permetteranno di cavartela con il minimo incrementalismo e il più discreto e completo backup possibile.

In alternativa, qualcosa come Amazon S3 potrebbe anche entrare in gioco a seconda della larghezza di banda e della quantità di modifiche apportate ai dati: a questo volume, inserendone almeno una parte sui server di qualcun altro e lasciandoli preoccupare della ridondanza diventa sempre più conveniente.

Parla con il tuo fornitore di archiviazione, avranno un prodotto di deduplicazione che hanno usato in precedenza, combinato con una compressione regolare spesso puoi ridurre il footprint dei dati del 70%. Ovviamente, chiunque abbia i soldi da spendere per un petabyte di spazio di archiviazione probabilmente avrà anche il budget per acquistare una soluzione di backup decente - se non lo ha fatto, è sufficiente chiedere loro quanto sarebbe costato perdere quel petabyte.

In un grande data warehouse aziendale, gran parte dei dati proviene da origini di cui è già stato eseguito il backup. Ho lavorato su installazioni Teradata e ODW in cui hanno preso l'opzione 4, ma sapevo che potevano ripristinare un giorno o due di dati transazionali e trasformarli dai sistemi di origine.

Ad un cliente al dettaglio (all'epoca avevano uno dei primi 5 DW più grandi al mondo, a circa 200 TB ... ti dà un'idea di quanto tempo fa), sono andati con l'opzione # 1 dopo aver acquistato un nuovo Petabyte -class server Teradata. I vecchi nodi sarebbero stati usati per un'istantanea del sistema del giorno precedente, mentre quello nuovo ha mantenuto quello esistente. Anche questo era bello dal punto di vista del failover: ogni tanto smettevano di occuparsi della manutenzione e passavamo all'utilizzo del vecchio server lento con dati vecchi.

Onestamente, però, mi è sembrato un grande spreco di elaborazione / archiviazione / ecc. Per continuare la cosa ... soprattutto quando il più grande vantaggio era che i loro amministratori e tecnici NCR dovevano lavorare meno serate per eseguire la manutenzione irregolare.