Il backup più piccolo possibile ... con SQL Server


37

Ogni giorno spediamo i nostri backup di SQL Server attraverso la WAN. Dobbiamo ridurre al minimo le dimensioni di questi backup in modo che non durino per sempre.

Non ci importa se il nostro processo di backup richiede un po 'più di tempo; allo stato attuale è necessario spostare 30 GB di backup compresso sulla WAN che richiede più di 10 ore.

Sono disponibili 2 opzioni per ottenere backup giornalieri più piccoli.

  1. Log shipping, il che significherebbe che dovremmo ristrutturare il processo di DR.
  2. Rimuovi le informazioni dal db e ricostruiscile sull'altro lato (elimina gli indici non cluster, comprime gli indici cluster al 100% - ricostruisci sull'altro lato)

Entrambi richiederebbero una buona dose di lavoro da parte nostra. Stiamo usando SQL Server 2008 pro, tutti i backup sono compressi.

Ci sono prodotti commerciali che possono darci dimensioni di backup simili all'opzione (2)?

Esiste uno script completo che ci permetterà di realizzare (2)? (gestione di viste indicizzate, indici filtrati, chiavi esterne e così via)


2
Qual è la granularità e la frequenza del backup corrente, per favore (backup regolari del registro? Pieno al giorno?) Usi Enterprise o l'edizione standard? Aggiornamento: sei una piccola azienda DR nel sito noleggiato o una grande azienda con un sito DR permanente? Se è il primo, hai un file server o SQL Server in esecuzione fuori dal sito
gbn

@gbn, dobbiamo ottimizzare per il pieno quotidiano, usiamo le imprese, il DR è tutto locale con persone che prendono le cose fuori sede. I piccoli backup sono necessari per gli sviluppatori e un secondo offsite che abbiamo. nota ... gli sviluppatori sono fuori sede, in altri paesi con larghezza di banda limitata, abbiamo bisogno della dimensione minima di trasferimento dai server di New York (ad esempio) in Australia. Ci sincronizziamo una volta ogni pochi mesi.
Sam Saffron,

1
Per chiunque non se ne
accorga

1
@Sam Saffron: qualche feedback per favore se hai adottato qualcosa come il mio suggerimento?
gbn

@gbn ... sto ancora decidendo cosa fare, penso che il "normale" lavoro di back up fino all'Oregon sia fattibile con la soluzione che hai suggerito. Tuttavia, "Sam ha bisogno di scaricare SO db una volta al mese il problema è ancora molto doloroso perché devo spostare 22 GB in Australia - quando la realtà è che le informazioni" reali "potrebbero facilmente rientrare in 10 concerti".
Sam Saffron,

Risposte:


22

Primo pensiero basato sui commenti ...

Utilizzare backup differenziali ogni, diciamo, 6 ore, per ridurre le dimensioni / il tempo di backup + FTP. Quindi riduci il backup completo + FTP solo nei fine settimana. Questo evita la complessità della distribuzione dei log, semplice da fare e aggiunge solo una leggera complessità al DR

Sento che i backup differenziali sono trascurati ... Ho suggerito di usarli prima:

Modifica: dopo il commento di jcolebrand cercherò di spiegare di più

Un backup differenziale richiede solo pagine modificate. Al di fuori di qualsiasi manutenzione dell'indice (che può influire su gran parte del database), solo una piccola percentuale delle pagine cambierà durante il giorno. Quindi un backup differenziale è molto più piccolo di un backup completo prima di qualsiasi compressione.

Se si dispone di un backup completo, ad esempio settimanalmente, è possibile eseguire differenziali giornalieri e spedirli fuori sede. Un backup completo giornaliero con differenziali richiederà comunque entrambi i file fuori sede.

Ciò dovrebbe risolvere il problema di ottenere rapidamente i dati da A a B, C e D.

Probabilmente avrai bisogno di ripristinare sia il differenziale completo sia quello più recente per ottenere i dati più recenti, ma potresti forse aggirare questo problema con NORECOVERY e un file STANDBY (non lo provo con un ripristino diff da anni da quando sono stato l'ultimo in un DBA puro lavoro).

Un ulteriore vantaggio è che i backup differenziali non sono correlati ai backup dei log in corso, pertanto è possibile separare qualsiasi requisito di disponibilità elevata / DR dal requisito "get data to the code monkeys".

Vedo alcuni problemi se si dispone di backup completi giornalieri in base a criteri o audit, ma è possibile applicare il ripristino diff prima di ripristinare qualsiasi registro per ridurre i tempi di recupero. A differenza dei backup, i ripristini di diff e log interagiscono.

Spero di aver coperto la maggior parte delle basi ...


Hyperbac è uno strumento di compressione molto intelligente, che consente di comprimere i backup e lasciare invariati tutti i piani di manutenzione e tutti i lavori, poiché gestisce i file a livello di sistema operativo. Se non vogliono cambiare nulla, ma semplicemente aggiungono un nuovo strumento alla scatola, dovrebbero assolutamente provarlo. So di averlo usato e amato per SQL 2005. Ma per una maggiore compressione dovrebbero comunque fare un po 'di lavoro manuale ...
Marian,

@Marian Sono ... abbastanza sicuro che Brent O sia solo un consulente in difficoltà.
jcolebrand

@Marian: c'è un limite alla compressione e più compressione = più CPU / tempo. Il backup più piccolo sarà quello con il minimo input = un differenziale, indipendentemente dallo strumento / formato di compressione. Link su tempo / rapporto Uno : puoi dare una compressione estrema ma impiega più tempo e per un file compresso da 30 GB potrebbe richiedere più tempo dell'FTP ...
gbn

Sono d'accordo con te su questo, il fatto è che gli strumenti commerciali hanno tassi di compressione migliori di quelli MS e sono configurabili (senza CPU assegnate all'operazione), offrono la crittografia ... e altre funzionalità. Non li elogio necessariamente (non sono molto economici), ho appena detto che alcuni di essi possono essere utilizzati insieme agli attuali backup di SQL Server (full, diff, log) senza cambiare l'ambiente, che i ragazzi sembrano necessità / desidera. @jcolebrand: capito, grazie!
Marian,

13

Esistono prodotti commerciali che possono aiutarti a comprimere i tuoi backup meglio della compressione nativa del 2008. Esempi sono RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .

Vengono forniti con il costo aggiuntivo di CPU e tipi di file elevati che dovranno essere gestiti con strumenti esterni a quelli spediti da MS. Questo ad eccezione della compressione Hyperbac (ora acquisita da Redgate), che gestisce i file in modo trasparente e consente di creare file compatibili con zip (e inoltre non necessita di strumenti di terze parti).

Ma non esiste uno strumento che ti offrirà un file delle dimensioni che potresti ottenere eseguendo la pulizia manuale. Leggi l'articolo di Brent Ozar: Come comprimere veramente i tuoi backup di SQL Server , ti consiglierà di fare gli stessi passi che hai al punto n. 2.


RedGate FTW !!!!
Hogan,

@Hogan: se non puoi batterli, comprali. È un ottimo esempio :-). Ad ogni modo, entrambi i prodotti che ora fanno parte di Redgate e gestiscono la compressione del database possono coesistere con successo.
Marian,

12

Domanda 1: esiste un prodotto di backup commerciale che fornirà una dimensione di backup simile alla rimozione dei dati non essenziali come gli indici dal database?

No. Esistono molti prodotti di compressione di backup (Quest LiteSpeed, Red Gate SQL Backup, Idera SQLSafe, Hyperbac, ecc.) Ma funzionano tutti semplicemente comprimendo l'output del normale processo di backup di SQL Server. Alcuni lo fanno in modi complicati - L'opzione HyperBac e LiteSpeed ​​Engine sono driver di filtro del file system, il che significa che intercettano l'output sulla sua strada verso il disco - ma il risultato finale di tutti questi prodotti è solo l'output di backup compresso.

Domanda 2. Esiste uno script completo per scaricare tutti questi dati extra?

Nel tempo, man mano che mantieni più cronologia nel database (4, 5, 8, 10 anni) non vorrai estrarre tutti i dati dell'indice e ricostruirli sull'altro lato della WAN. Invece, vuoi semplicemente trasferire i dati modificati, ed è qui che entra in gioco il log shipping.

Non dovresti farlo.

Ma se davvero, davvero vuoi farlo (e no, non ti aiuterò), puoi farlo con i backup di filegroup. Imposta i tuoi filegroup di database in questo modo:

  • Filegroup primario (richiesto, ma lasciarlo vuoto)
  • Filegroup ClusteredIndex (inserisci qui gli indici cluster)
  • Filegroup ExtraneousCrap (inserisci qui tutto il resto)

Inizia a fare backup compressi di filegroup solo dei primi due e copia quelli più piccoli sul tuo server DR. È possibile utilizzare il backup di filegroup di SQL Server 2008 e la funzionalità di ripristino per ripristinare solo i filegroup primari e ClusteredIndex, quindi saranno immediatamente disponibili per l'interrogazione. Non saranno davvero fattibili fino a quando non otterrai quel filegroup ExtraneousCrap online, ma c'è anche un brutto trucco per questo - nel libro MVP Deep Dives , c'è un capitolo sulla modifica delle tabelle di sistema per rendere il filegroup ExtraneousCrap e tutto degli indici associati scompaiono. Questo trucco è pericoloso, totalmente privo di supporto e una pessima idea - ma, ehi, te l'hai chiesto.


10

Consiglio di passare a qualcosa come il log shipping. In sostanza, se hai la possibilità di inviare 30 concerti in 24 ore rispetto all'invio a fine giornata in un intervallo di tempo più breve, la velocità della rete sarà meno problematica per te.

I tuoi sviluppatori sulla rete lenta saranno anche in grado di scaricare file di dimensioni più convenienti, tramite FTP o qualunque processo tu abbia in atto. Potrebbero anche impostare lavori che vengono scaricati durante il giorno.

Oltre alla compressione del server sql, è possibile implementare uno strumento di terze parti tale da avere una compressione maggiore come litespeed o redgate sqlbackup.

Inoltre, dal lato della rete è possibile installare dispositivi di rete in grado di ottimizzare il throughput sul sito DR. In passato ho usato con successo Riverbed Appliance per ottenere con successo 90 GB di backup da FL a VA in meno di 3 ore.

Un'altra opzione sarebbe quella di eseguire il backup di specifici gruppi di file, esclusi gli indici, ecc., Ma si è ancora bloccati con gli indici cluster e, a seconda della struttura del db, è possibile ottenere più costi / problemi che beneficiare di tale approccio.

Grazie


7

Se hai i soldi per questo e la tua architettura lo consente, controlla qualcosa come le tecnologie Riverbed (http://www.riverbed.com/us/). Un dispositivo come questo in combinazione con uno scenario di replica o di distribuzione dei log potrebbe essere la soluzione migliore.

In caso contrario, alcune domande. Se devi solo aggiornare ogni pochi mesi, perché preoccuparti della larghezza di banda? L'unica volta che dovresti preoccuparti del trasferimento è una volta, ottenere il backup completo laggiù per eseguire un ripristino localmente o mi sbaglio in quella configurazione?

Un'altra possibilità è invece quella di preoccuparsi di ottenere tutti quei dati, di impostare un ambiente Citrix e di averli in remoto. Con Citrix hai requisiti minimi di larghezza di banda tra client / host e hai la possibilità di fare ciò di cui hai bisogno localmente e non preoccuparti di dover replicare quei cambiamenti altrove. Solo i miei $ 0,02


Puoi spiegarlo più su questo? So che questo è per il team StackExchange corretto, quindi sono sicuro che
adorerebbero

Haha, c'è molto da considerare qui. Su quale punto vorresti esporre esattamente?
SQLChicken

La spedizione di replica / log era ciò che avevo in mente, ma era come due settimane fa, quindi dubito che sia altrettanto importante ora. Inoltre, ho appena riletto e visto la parte sulla Citrix, e avrei potuto dirti allora (come adesso) che non lo fanno. Fanno solo lo sviluppo locale usando un'infrastruttura DVCS e vogliono solo i dati per testare / giocare con / confermare. Forse anche per i dump dei dati.
jcolebrand

Gotcha. Quindi, come altri hanno già detto, i fornitori di terze parti come Redgate e Quest hanno ottimi strumenti di compressione del backup per aiutarti a soddisfare le loro esigenze. Un'altra potenziale soluzione è SQL Azure. In questo momento il limite delle dimensioni del database è di 50 GB, ma hanno aumentato i costi per i dati caricati, quindi potrebbe essere una soluzione economica.
SQLChicken

4

Vorrei usare la replica transazionale SQL. Il tuo caricamento iniziale richiederebbe un po 'di tempo, ma una volta che ti sei alzato e funzionante puoi solo inviare le informazioni che desideri. Ad esempio, se hai solo 3 o 4 tabelle che vengono aggiornate, puoi inviare solo quelle 3 o 4 tabelle.

Puoi anche scegliere cosa vuoi spedire. FK, indici cluster / non cluster, schemi di partizione di tabella, processi memorizzati e TON più.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Se questa non è un'opzione, è possibile utilizzare REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . L'ho usato prima e ho ottenuto livelli di compressione fino al 90%. Molto più piccolo di quello di SQL.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.