Backups do SQL Server usando cópia de sombra de volume

9

Muitos utilitários de backup conhecidos do Windows usam o Serviço de Cópia de Sombra de Volume incorporado às versões mais recentes do Windows para criar um instantâneo point-in-time do disco para fazer backup de arquivos abertos com segurança.

Mas quão bem esse mecanismo funciona com o SQL Server? Sei que existe um gravador VSS do SQL Server para ajudar os sistemas de backup a interoperarem com o SQL Server, mas nem todos os sistemas de backup conhecem o SQL Server e aproveitam a API relacionada ao backup que ele fornece.

Então, minha pergunta é: e os programas que não sabem nada sobre o SQL Server?

Presumivelmente, eles obtêm uma captura instantânea dos arquivos MDF e LDF no momento em que existiam em um único instante. E, presumivelmente, o formato de dados do SQL Server é robusto o suficiente para garantir que esse instantâneo seja consistente e utilizável.

É assim que as coisas funcionam, ou estou perdendo alguma coisa? Existem "truques" sobre o uso desse mecanismo de backup ou eu estaria seguro?

windows sql-server backup vss tylerl
fonte

Respostas:

8

Resposta curta: eles não funcionam muito bem juntos, a menos que você tenha o SQL Server configurado adequadamente (e mesmo assim eu não o recomendaria).

Há muitas informações sobre o VSS e o MSSQL sendo executados juntos aqui:
MSKB919023: conectividade do SQL Server 2005 e VSS (Volume Shadow Copy Service) .

Uma palavra de aviso:

presumivelmente, o formato de dados do SQL Server é robusto o suficiente para garantir que esse instantâneo seja consistente e utilizável

Essa é uma grande suposição, e que nem sempre é segura de se fazer, infelizmente. É por isso que seus planos de manutenção MSSQL são essenciais para garantir que você possa se recuperar de desastres.

Mark Henderson
fonte
6

Você nunca faz backup de arquivos MDF e LDF.

Você executa backups (planos, SQL, SMO, o que for) e depois faz backup desses arquivos de backup.

Francamente, não entendo o que qualquer fornecedor diz sobre o VSS. Também não gosto de nenhum fornecedor que tenha um plug-in do SQL Server para backups. Você usa apenas backups nativos do SQL Server

FYI: você também exclui MDFs e LDFs da verificação de vírus também.

gbn
fonte
2

Se você não possui um software que possua uma "opção" SQL, então:

Crie planos de manutenção SQL ou tarefas de backup agendadas para os bancos de dados, despeje-as em disco e faça backup do servidor. Ou, ao despejá-los, despeje-os diretamente no local de backup em disco, se você tiver um.

O limpador
fonte
2

O principal problema com o backup do VSS é causado pelo armazenamento em cache no servidor sql.

O estado atual no seu disco nem sempre contém todas as alterações no banco de dados. O software de backup deve estar ciente disso para garantir que o servidor sql grave todos os caches antes de tirar um instantâneo.

Dito isto: o método mais seguro ainda é fazer backup no gerenciamento sql / com ferramentas de servidor sql.

E você deve excluir todos os dados do servidor sql e arquivos de backup dos virusscanners (.bak, .mdf, .ldf).

Andreas Rehm
fonte
3
Todo o objetivo da arquitetura VSS Requestor \ Writer é garantir que o aplicativo confiável (por exemplo, seu aplicativo de Backup) possa instruir o proprietário (SQL Server \ Exchange etc) a liberar todos os dados em cache e abrir transações e, em seguida, liberar o cache de disco do SO antes fazendo o instantâneo. Se funciona bem é outra questão, mas a arquitetura faz o máximo possível para garantir que os arquivos sejam consistentes.
Helvick 18/09/10
2
hum não. a menos que você tenha feito uma alteração louca na configuração, uma vez que uma transação é confirmada, ela está no disco. não há nada confirmado no cache que também não esteja confirmado no disco.
longneck