DPM 2012 – Cuidado com o espaço no seu disco de log!

O System Center Data Protection Manager 2012 certamente é uma ferramenta muito boa para controlar os backups de um ambiente SQL Server, mas recentemente vi uma situação que merece um pouco de atenção para quem for implementar a ferramenta.

Ao configurar a proteção para um determinado banco de dados, aparentemente o DPM identifica a unidade de disco do arquivo de log e cria dentro dele o caminho:

UNIDADE:\DPM_SQL_PROTECT\SERVIDOR\INSTANCIA\BANCO_Log.ldf\Backup

Isso não é um problema por si só, mas imagine a situação onde há uma quantidade anormal de operações em seu banco de dados e seu arquivo de log é rapidamente “preenchido”.

Imagine então que você não tomou medidas reativas imediatamente e ficou “protegido” apenas pela frequência de seus backups incrementais (de log) do DPM, onde esses ao serem executados permitem a reutilização dos VLFs (dos “espaços”) em seu arquivo de log.

O problema nessa situação é que o DPM ao realizar seus backups incrementais gera um arquivo .log no caminho que mencionei mais acima, e este terá seu tamanho proporcional a quantidade de informação armazenada no arquivo de log.

Sendo assim, no momento em que seu arquivo de log está mais “cheio”, podendo até estar crescendo e ocupando mais espaço em sua unidade de disco, você precisará de mais espaço na mesma unidade para realizar seus backups.

O que pode ocorrer é que, em uma situação de pouco espaço no disco de log, quando você mais precisa realizar um backup incremental do DPM (de log) para liberar espaço no arquivo e evitar que ele cresça, esse seja exatamente o momento onde você não conseguirá realizar os backups, por falta de espaço, entrando assim em uma situação quase sem saída e bem desconfortável.

Obviamente que isso pode ser evitado com uma frequência bem planejado dos backups de log, com um disco para os arquivos de log com espaço devidamente planejado, mas nós sabemos que no mundo “real” as coisas nem sempre funcionam como deveriam (não lhe entregaram o disco que você pediu? houve falha no backup? etc…) e que esse cenário pode ocorrer.

E caso você se encontre nesse cenário, o que pode ser feito? Bem, ai você tem algumas opções.

Uma delas é adicionar um novo arquivo de log em um outro disco e então lidar com a situação com mais calma (nunca passei por essa situação, não sei se nesse caso ele criaria o caminho no outro disco e permitiria o backup, ou se faria o backup de cada arquivo de log em uma pasta no seu disco…).

Uma outra opção, mais traumática, seria realizar um backup de log diretamente por T-SQL enviando o conteúdo para o NUL device, dessa forma:

BACKUP LOG BANCO TO DISK = ‘NUL’

Onde o NUL é semelhante a ideia do /dev/null do linux (já escrevi sobre isso nesse post).

Com isso você consegue liberar espaço em seu arquivo de log, mas vai perder todo o conteúdo no mesmo, quebrando então a sequência de pontos de recuperação no DPM.

Caso opte por essa “solução” o recomendável é realizar um backup FULL do seu banco de dados logo em seguida.

Independente da solução adotada, o ideal é sempre controlar a frequência de seus backups incrementais no DPM e manter seu disco com espaço livre suficiente para que o SQL Server e o DPM operem sem problemas.

De qualquer forma, fica o aviso sobre o comportamento do DPM para que todos estejam cientes e não passem por esse tipo de situação.

Esse post foi publicado em Artigos, System Center, Virtual PASS BR. Bookmark o link permanente.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s