O menor backup possível… com o SQL Server

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)

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:

• Como fazer backup de um pequeno banco de dados no SQL Server 2008 R2 Express Edition
  usando backups DIFF para resolver isso

  Gostaria de manter tudo o mais simples possível do ponto de vista da recuperação, minimizando a quantidade de dados perdidos em caso de falha

• Prós e contras das estratégias de backup do SQL Server e seus cenários de uso apropriados
• Migrando banco de dados grande
  Usando backups DIFF para acelerar uma migração de servidor de backup / restauração

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

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)

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.

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

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

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.