'Limpar' um arquivo de banco de dados do SQL Server criado com a Inicialização Instantânea de Arquivos ativada?

8

Eu tenho a Inicialização Instantânea de Arquivos ativada em nosso SQL Server, para que a parte 'vazia' do arquivo de banco de dados não seja zerada antes de ser alocada. Meu entendimento é que isso significa que o arquivo pode conter dados 'excluídos'.

Então agora eu quero enviar uma cópia de um banco de dados (provavelmente um arquivo de backup) para fora da empresa. Mas há todos os dados 'excluídos' potencialmente sensíveis que ficam dentro do arquivo. Agora eu gostaria de zerar a parte não utilizada do arquivo.

Isso é possível? Eu imagino que eu poderia criar um novo banco de dados e copiar tudo, ou talvez restaurar uma cópia do banco de dados em outro servidor sem a Inicialização Instantânea de Arquivo ativada e, em seguida, ser agressivo com um comando ShrinkFile para remover a maior parte ou toda a parte não utilizada do arquivo de banco de dados. , mas existe um método menos manual e demorado? Idealmente, um comando para dizer ao SQL para zerar o arquivo, como faria se a Inicialização Instantânea de Arquivos não estivesse ativada.

sql-server sql-server-2008-r2

— paulH
fonte

Para referência geral, a inicialização instantânea do arquivo de dados pode ser temporariamente desabilitada sem mexer nas permissões da conta de serviço usando o sinalizador de rastreamento 1806, como Paul Randal postou aqui por blog .

— 22613 Jon Seigel

5

Um BACKUP do SQL Server faz backup apenas de extensões que estão sendo usadas para armazenar dados. As extensões não utilizadas são deixadas para trás pelo backup. Quando uma página é usada para dados, ela é formatada para uso conforme necessário, para que a página fique livre de dados antigos.

Portanto, tudo que você precisa fazer é fazer backup do banco de dados e restaurá-lo em outro lugar. Os arquivos restaurados terão o mesmo tamanho do banco de dados original, mas as extensões não utilizadas serão criadas usando os recursos do servidor de destino. Isso pode ser inicializado total ou instantaneamente, usando os blocos de disco no servidor de destino.

No entanto, como as extensões são o nível no qual os backups acontecem, as páginas não utilizadas na medida em que ainda podem ter potencial para expor alguns dados quando restauradas em outro servidor. Não tanto quanto poderia ser exposto no servidor de origem, pois as extensões não utilizadas não são restauradas.

— RLF
fonte

11

Extensões não utilizadas, na verdade. Teoricamente, mesmo algumas das extensões usadas ainda podem conter espaço com 'dados antigos', que são drible sem sentido para o SQLServer, mas podem ser um tesouro para um concorrente armado com um editor hexadecimal e muito tempo livre. Se seus dados são tão sensíveis, você não zeraria todos os arquivos?

— John Alan

@JohnAlan - Modificado para reconhecer a exposição em extensões.

— RLF 21/08

Os dados não são exatamente itens do GCHQ - são apenas dados básicos do cliente e assim por diante, por isso é improvável que alguém se esforce demais para recuperá-lo. Eu não tinha percebido que os backups funcionavam assim, embora faça sentido que deva. Se não houver outra solução rápida e simples, provavelmente isso funcionará.

— PaulH

1

Você já pensou em restaurar uma cópia dela, habilitando a TDE que forçará a 0 a sair e, em seguida, desabilitando a TDE novamente? Eu não testei isso, mas acho que vai funcionar, mas teremos que testá-lo.

Além disso, você já pensou em restaurar uma cópia dela com o IFI desativado, criar um novo grupo de arquivos com novos arquivos, presizer, reconstruir o cluster e outros índices no novo grupo de arquivos e descartar o grupo de arquivos existente (se for o grupo de arquivos principal) você precisará reduzi-lo, já que não pode abandonar o primário)

— Ali Razeghi
fonte

Usar o TDE parece uma abordagem interessante, embora não tenha certeza se ele removerá mais dados indesejados do que o método de backup e restauração. Se alguém souber mais informações sobre isso, eu estaria interessado em saber.

— PaulH