Início / dba / Perguntas / 117028
Accepted
BradC
Asked: 2015-10-06 06:31:05 +0800 CST

Compreendendo o impacto/risco de desativar "verificar a integridade do backup" no backup do SQL

  • 772

Atualmente usamos planos de manutenção padrão para backups nos servidores SQL Server 2005/2008/2008R2/2012 em nosso ambiente, e a caixa "Verificar integridade do backup" sempre foi marcada.

Alguns dos backups são muito demorados, por isso recomendei desativar essa opção, mas o gerenciamento precisa que eu documente o impacto e os riscos dessa alteração.

Entendo o uso e o histórico dessa opção, apenas me parece desnecessário dobrar o tempo para a tarefa de backup quando (na minha opinião) qualquer erro que possa ocorrer ocorreria durante a etapa de backup , não durante a verificação.

Estou errado? É um risco mínimo desligar isso, se eu estiver fazendo backup em disco e não em fita de streaming ou algo assim? (Fazemos backup pela rede para um dispositivo de backup EMC DD-800, se for relevante.)

Existe alguma recomendação oficial da MS para quando é seguro desligar isso?

Você executa "verificar" em cada backup em seu ambiente? Você os verifica?

EDIT : Para esclarecer, quando você verifica "verificar a integridade do backup" no plano de manutenção, o SQL fará uma RESTORE VERIFYONLY completa em cada banco de dados imediatamente após cada backup. Isso é tão intensivo em dados/IO quanto o backup original e (basicamente) dobra o tempo total da tarefa de backup. Isso não é o mesmo que habilitar a opção "soma de verificação" no backup (o que não pode ser feito no assistente, até onde eu sei).

sql-server backup

3 respostas

  1. Best Answer

    Estou errado? É um risco mínimo desligar isso, se eu estiver fazendo backup em disco e não em fita de streaming ou algo assim?

    Não, tens razão :-)

    RESTORE VERIFYONLYonly não garantirá que você será capaz de recuperar seu banco de dados em caso de corrupção. Por natureza, ele não executará nenhuma verificação de integridade.

    Uma maneira melhor será fazer backups periodicamente e fazer uma restauração válida em um servidor diferente e executar DBCC CHECKDB nele.

    Esse é um dos motivos pelos quais não sou um grande fã de planos de manutenção, já que a GUI não expõe muitas opções como as backup .. with CHECKSUMque podem ser alcançadas pelo T-SQL.

    Do blog Myth de Paul Randal

    24p) usando RESTORE … WITH VERIFYONLY valida todo o backup

    Não. Usar VERIFYONLY apenas valida se o cabeçalho de backup se parece com um cabeçalho de backup. É somente quando você faz o backup usando WITH CHECKSUM e RESTORE … WITH VERIFYONLY e usando WITH CHECKSUM que a restauração faz verificações mais extensas, incluindo a soma de verificação em todo o backup.

    Você executa "verificar" em cada backup em seu ambiente? Você os verifica?

    Eu não executo o VERIFYONLY. Em vez disso, faço backup com CHECKSUM e os restauro + CHECKDB'ed em um servidor diferente. Você pode seguir a abordagem de amostragem estatística para verificação de backups de banco de dados se quiser ser criativo.

    Isso não é o mesmo que habilitar a opção "soma de verificação" no backup (o que não pode ser feito no assistente, até onde eu sei).

    Você pode habilitar o Trace Flag 3023 para que a CHECKSUMopção seja habilitada automaticamente para o comando BACKUP. Como sempre, teste o comportamento de quaisquer sinalizadores de rastreamento em seu ambiente!

    O resultado final é - abandone os planos de manutenção e use uma solução de backup mais sensata (dica: a solução de backup da Ola) que permitirá que você a personalize com base em suas necessidades.

    (Fazemos backup pela rede para um dispositivo de backup EMC DD-800, se for relevante.)

    Faça backup localmente no disco e, em seguida, faça um trabalho de transferência do PowerShell que copiará o backup localmente do servidor para um compartilhamento de rede (servidor de backup). Isso será mais rápido do que copiar diretamente para um compartilhamento de rede.

    Além disso, habilite a inicialização instantânea do arquivo, que ajudará no crescimento automático dos arquivos de dados, bem como na redução do tempo de restauração (no caso de você precisar restaurar seus bancos de dados). É sempre bom ter opções à mão.

    Uma boa leitura será: Backups: planejando uma estratégia de recuperação

    • 5

  2. O ponto principal é que, a menos que você faça uma restauração do banco de dados em algum lugar, não poderá ter certeza absoluta de que um determinado arquivo de backup é bom.

    O teste ideal para verificar seus backups é configurar um ambiente onde os backups de banco de dados e os backups de log do banco de dados sejam restaurados o tempo todo como parte do seu processo diário. Esta é uma das vantagens de usar o log-shipping...

    Se você ainda quiser ficar com a verificação, você pode configurar um ambiente especificamente apenas para fazer isso. Isso descarregaria o trabalho do seu (presumivelmente) servidor de produção e reduziria o tempo de trabalho.

    Por fim, você já pensou em abandonar os planos de manutenção? Scripts como os scripts de Ola são exceto para backups e manutenção: https://ola.hallengren.com/

    • 2

  3. Tecnicamente, a versão de restauração é como executar uma restauração, no entanto, não há melhor verificação do que restaurar o banco de dados para verificar se é um backup válido. Tivemos uma instância em que a verificação foi aprovada, mas o banco de dados não foi restaurado devido à corrupção, meu ponto é não contar com isso como uma verificação de que o backup está ok. Agora desenvolvemos um sistema que restaura todos os nossos bancos de dados em uma instância separada para verificar sua validade, obviamente isso nem sempre é possível, então tente amostrar determinados bancos de dados por semana. O longo e o curto não confiam na verificação apenas 100%.

    • 1

relate perguntas