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

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)

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:

• Come eseguire il backup di un piccolo database in SQL Server 2008 R2 Express Edition
  Utilizzando i backup DIFF per risolvere questo problema

  Vorrei mantenere tutto il più semplice possibile dal punto di vista del recupero, riducendo al minimo la quantità di dati persi in caso di guasto

• Pro e contro di SQL Server eseguono il backup delle strategie e dei relativi scenari di utilizzo
• Migrazione di database di grandi dimensioni
  Utilizzo di backup DIFF per accelerare una migrazione del server di backup / ripristino

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 ...

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.

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.

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

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

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.