O menor backup possível… com o SQL Server

37

Diariamente, enviamos nossos backups do SQL Server pela WAN. Precisamos minimizar o tamanho desses backups para que não demore uma eternidade.

Não nos importamos se nosso processo de backup demorar um pouco mais; como está, precisamos mover 30gigs de backup compactado pela WAN que leva mais de 10 horas.

Existem duas opções para obter backups diários menores.

  1. Envio de logs, o que significaria que teríamos que reestruturar o processo de recuperação de desastres.
  2. Retire as informações do banco de dados e reconstrua do outro lado (elimine índices não agrupados em cluster, compacte índices agrupados em 100% - reconstrua do outro lado)

Ambos envolveriam uma quantidade razoável de trabalho de nossa parte. Estamos usando o SQL Server 2008 pro, todos os backups são compactados.

Existem produtos comerciais que podem nos fornecer tamanho de backup semelhante à opção (2)?

Existe um script abrangente por aí que nos permita realizar (2)? (manipulação de visualizações indexadas, índices filtrados, chaves estrangeiras e assim por diante)

Sam Saffron
fonte
2
Qual é a granularidade e a frequência atuais de backup (backups regulares de log? Diariamente cheios?) Você usa o Enterprise ou a edição padrão? Atualização: você é DR de pequena empresa no site alugado ou grande empresa com site de DR permanente? Se 1ª um, você tem um servidor de arquivos ou SQL Server em execução fora do local
GBN
@gbn, precisamos otimizar para a diária completa, usamos a empresa, o DR é todo local, com pessoas levando as coisas para fora do local. Os pequenos backups são necessários para os desenvolvedores e um segundo local externo que temos. note ... os desenvolvedores são externos, em outros países com largura de banda limitada, precisamos do tamanho mínimo de transferência dos servidores de NY para (por exemplo) a Austrália. Sincronizamos uma vez a cada poucos meses.
Sam Saffron
11
Para qualquer um que não percebem isso, este é para a equipe SO adequada;)
jcolebrand
11
@ Sam Saffron: algum feedback, por favor, sobre se você adotou algo como a minha sugestão?
gbn
@gbn ... ainda decidindo o que fazer, acho que o trabalho "regular" - de volta ao trabalho no Oregon é viável com a solução que você sugeriu. No entanto, o problema "Sam precisa fazer o download do SO db uma vez por mês ainda é muito doloroso. Preciso mudar 22gigs para a Austrália - quando a realidade é que as informações" reais "podem caber facilmente em 10 shows."
Sam Saffron

Respostas:

22

Primeiro pensamento baseado em comentários ...

Use backups diferenciais a cada, digamos, 6 horas, para reduzir o tamanho / tempo do backup + FTP. Em seguida, reduza seu backup completo + FTP apenas aos fins de semana. Isso evita a complexidade do envio de logs, simples de fazer e apenas adiciona uma leve complexidade ao DR

Sinto que os backups diferenciais são negligenciados ... Sugeri usá-los antes:

Edit: após o comentário de jcolebrand vou tentar explicar mais

Um backup diferencial leva apenas as páginas que foram alteradas. Fora de qualquer manutenção de índice (que pode afetar grande parte do banco de dados), apenas alguns% das páginas serão alteradas durante um dia. Portanto, um backup diferencial é muito menor que um backup completo antes de qualquer compactação.

Se você tiver um backup completo, digamos semanalmente, poderá fazer diferenciais diários e enviá-los para fora do local. Um backup completo diário com diferenciais ainda exigirá os dois arquivos fora do local.

Isso deve resolver o problema de obter dados de A para B, C e D rapidamente.

Você provavelmente precisará restaurar o diferencial completo e o mais recente para obter os dados mais recentes, mas talvez seja possível solucionar isso com o NORECOVERY e um arquivo STANDBY (eu não tentei com uma restauração diff por anos desde a última vez em um DBA puro trabalho).

Um bônus adicional é que os backups diferenciais não estão relacionados aos backups de log em andamento, para que você possa separar qualquer requisito de Alta Disponibilidade / DR do requisito "obter dados para os macacos de código".

Eu vejo alguns problemas se você tiver backups completos diários por política ou auditoria, mas a restauração diff pode ser aplicada antes que qualquer log seja restaurado para diminuir o tempo de recuperação. Diferentemente dos backups, as restaurações diff e log interagem.

Espero ter coberto a maioria das bases ...

gbn
fonte
O Hyperbac é uma ferramenta de compactação muito inteligente, que permite compactar backups e manter todos os planos e tarefas de manutenção inalterados, porque lida com arquivos no nível do SO. Se eles não quiserem mudar nada, mas apenas adicionar uma nova ferramenta à caixa, eles definitivamente devem tentar. Eu sei que eu usei-o e amou-lo para SQL 2005. Mas, por mais compressão devem ainda fazer algum trabalho manual ...
Marian
@ Marian Estou ... tenho certeza que Brent O é apenas um consultor em necessidade.
jcolebrand
@ Marian: há um limite para a compactação e mais compactação = mais CPU / tempo. O menor backup será aquele com o menor número de entradas = diferencial, independentemente da ferramenta / formato de compactação. Fazer a ligação sobre o tempo / relação Um : você pode deu compressão extrema, mas é preciso mais tempo e para um 30 arquivo compactado GB que pode demorar mais tempo do que o FTP ...
GBN
Concordo com você, o fato é que as ferramentas comerciais têm melhores taxas de compactação do que a MS e são configuráveis ​​(por nenhuma das CPUs alocadas à operação), elas oferecem criptografia ... e outros recursos. Eu não necessariamente os elogio (eles não são muito baratos), eu apenas disse que alguns deles podem ser usados ​​em conjunto com os backups atuais do SQL Server (completo, diff, log) sem alterar o ambiente, o que os caras parecem precisa / quer. @jcolebrand: entendi, obrigado!
Marian
13

Existem produtos comerciais que podem ajudá-lo a compactar seus backups melhor do que a compactação nativa de 2008. Exemplos são RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .

Eles vêm com o custo adicional de CPU e tipos de arquivos altos que precisarão ser manipulados com ferramentas externas às fornecidas pela MS. Isso, com exceção da compactação Hyperbac (agora adquirida pela Redgate), que lida com arquivos de forma transparente e permite criar arquivos compatíveis com zip (e também não precisa de ferramentas de terceiros).

Mas não há ferramenta que ofereça um arquivo do tamanho que você obteria fazendo a limpeza manual. Consulte o artigo de Brent Ozar: Como realmente compactar seus backups do SQL Server , ele aconselhará a executar as mesmas etapas que você tem no ponto não. 2)

Marian
fonte
RedGate FTW !!!!
Hogan
@ Hogan: se você não pode vencê-los, compre-os. É um exemplo muito bom :-). De qualquer forma, os dois produtos que agora fazem parte do Redgate e lidam com a compactação de banco de dados podem coexistir com sucesso.
Marian
12

Pergunta 1: Existe um produto de backup comercial que fornecerá um tamanho de backup semelhante para remover dados não essenciais, como índices, do banco de dados?

Não. Existem muitos produtos de compactação de backup por aí (Quest LiteSpeed, Backup do Red Gate SQL, Idera SQLSafe, Hyperbac etc.), mas todos funcionam apenas compactando a saída do processo de backup regular do SQL Server. Alguns deles fazem isso de maneiras complicadas - a opção Engine do HyperBac e do LiteSpeed ​​são drivers de filtro do sistema de arquivos, o que significa que eles estão interceptando a saída no caminho para o disco - mas o resultado final de todos esses produtos é apenas uma saída de backup compactada.

Pergunta 2. Existe um script abrangente disponível para despejar todos esses dados extras?

Com o tempo, à medida que você mantém mais histórico no banco de dados (4, 5, 8, 10 anos), não deseja extrair todos os dados do índice e reconstruí-los no outro lado da WAN. Em vez disso, você deseja apenas transferir os dados modificados e é aí que entra o envio de logs.

Você não deveria fazer isso.

Mas se você realmente quer fazer isso (e não, eu não vou ajudá-lo), você pode fazer isso com backups de grupos de arquivos. Configure os grupos de arquivos do seu banco de dados da seguinte maneira:

  • Grupo de arquivos primário (obrigatório, mas deixe em branco)
  • Grupo de arquivos ClusteredIndex (coloque seus índices em cluster aqui)
  • Grupo de arquivos ExtruriousCrap (coloque todo o resto aqui)

Comece a fazer backups de grupos de arquivos compactados apenas dos dois primeiros e copie os menores para o servidor de recuperação de desastres. Você pode usar o recurso de backup e restauração de grupos de arquivos do SQL Server 2008 para restaurar apenas os grupos de arquivos Primary e ClusteredIndex e, em seguida, eles estarão disponíveis imediatamente para consulta. Eles realmente não serão viáveis ​​até que você obtenha o grupo de arquivos ExtraneousCrap on-line, mas também há um truque desagradável - no livro MVP Deep Dives , há um capítulo sobre a edição das tabelas do sistema para criar o grupo de arquivos ExtraneousCrap e tudo dos índices associados desaparecem. Esse truque é perigoso, totalmente sem suporte e uma péssima idéia - mas, ei, você pediu.

Brent Ozar
fonte
10

Eu recomendo mudar para algo como envio de logs. Essencialmente, se você tiver a opção de enviar 30 Gigs por 24 horas ou enviar no final do dia em uma janela de tempo mais curta, a velocidade da rede será um problema menor para você.

Seus desenvolvedores na rede lenta também poderão baixar arquivos de tamanho mais conveniente, via FTP ou qualquer processo que você tenha implementado. Eles também podem configurar tarefas que são baixadas ao longo do dia.

Além da compactação do servidor sql, você pode implementar uma ferramenta de terceiros que possui uma compactação mais alta, como litespeed ou redgate sqlbackup.

Além disso, no lado da rede, você pode instalar dispositivos de rede que podem otimizar sua taxa de transferência para o site de recuperação de desastres. No passado, usei com sucesso o Riverbed Appliance para obter um backup de 90 GB de FL para VA em menos de 3 horas.

Outra opção seria fazer backup de grupos de arquivos específicos, excluindo os índices, etc., mas você ainda está preso aos índices clusterizados e, dependendo da estrutura do banco de dados, pode obter mais custo / aborrecimento do que se beneficiar dessa abordagem.

obrigado

johndacostaa
fonte
7

Se você tem o dinheiro para isso e sua arquitetura permite, verifique algo como as tecnologias da Riverbed (http://www.riverbed.com/us/). Um dispositivo como esse em conjunto com um cenário de replicação ou envio de logs pode ser sua melhor aposta.

Se não, então algumas perguntas. Se você só precisa fazer uma atualização a cada poucos meses, por que a preocupação com a largura de banda? A única vez em que você precisa se preocupar com a transferência é uma vez, obtendo o backup completo por lá para fazer uma restauração localmente, ou estou enganado por ser sua configuração?

Outra possibilidade é, em vez de se preocupar em obter todos esses dados, configurar um ambiente Citrix e mantê-los remotos em você. Com o Citrix, você tem requisitos mínimos de largura de banda entre cliente / host e tem a capacidade de fazer o que precisa localmente e não se preocupa em ter que replicar essas alterações em outro lugar. Apenas meus $ 0,02

SQLChicken
fonte
Você pode explicar mais sobre isso? Eu sei que isto é para a equipe Stackexchange adequada, então eu tenho certeza que eles vão adorar um passo a passo mais aprofundada;)
jcolebrand
Haha, há muito a considerar aqui. Em que ponto exatamente você gostaria que eu expusesse?
SQLChicken
A replicação / envio de logs era o que eu tinha em mente, mas isso foi há duas semanas, então eu duvido que seja tão importante agora. Além disso, eu apenas reli e vi a parte sobre o Citrix, e eu poderia ter dito a você (como agora) que eles não fazem isso. Eles apenas desenvolvem localmente usando uma infraestrutura DVCS e querem apenas os dados para testar / brincar com / confirmação. Também talvez para os despejos de dados.
Jcolebrand
Peguei vocês. Então, como outros já disseram, os fornecedores de terceiros, como Redgate e Quest, têm ótimas ferramentas de compactação de backup para ajudá-lo a atender às suas necessidades. Outra solução potencial é o SQL Azure. No momento, o limite de tamanho do banco de dados é de 50 GB, mas eles aumentaram as cobranças de todos os dados que estão sendo carregados, portanto pode ser uma solução econômica.
SQLChicken
4

Eu usaria replicação transacional SQL. Seu carregamento inicial levaria algum tempo, mas, uma vez instalado e funcionando, você só poderia enviar as informações desejadas. Por exemplo, se você tiver apenas 3 ou 4 tabelas atualizadas, poderá enviar apenas essas 3 ou 4 tabelas.

Você também pode escolher o que deseja enviar. FKs, índices agrupados / não agrupados, esquemas de partição de tabela, procs armazenados e TONS mais.

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

Se isso não for uma opção, você poderá usar o REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Eu usei isso antes e obtive níveis de compressão de até 90%. Muito menor que o SQL.

SqlSandwiches
fonte