Backup de SQL Server: como fazer, o que automatizar e por que o backup do servidor não basta

“O servidor tem backup toda noite.” É a resposta mais comum quando se pergunta a uma empresa como está o backup do banco do ERP. Às vezes está tudo certo. Muitas vezes, o que existe é uma cópia do disco que nunca foi testada como banco de dados, que não permite voltar a um horário específico do dia e que mora no mesmo servidor que ela deveria proteger.

A Global Data, empresa de TI em São Paulo, faz backup gerenciado de servidores e bancos de dados de pequenas e médias empresas. Este guia mostra, com a documentação da Microsoft, o que um backup de SQL Server precisa ter para restaurar de verdade, como fazer e automatizar no próprio SQL Server e onde uma solução gerenciada entra.

O backup que a empresa acha que tem

O SQL Server mantém os arquivos do banco abertos e trancados enquanto o serviço roda. A documentação do serviço SQL Writer explica que, sem esse serviço ativo, os programas de backup do Windows nem conseguem acessar os arquivos de dados, e que ferramentas baseadas em snapshot do VSS correm o risco de gerar backups de bancos inconsistentes. Uma cópia de arquivo .mdf feita por fora, sem conversar com o SQL Server, pode até terminar sem erro. Ela só não garante que o banco abre depois.

Há um segundo ponto, menos conhecido. Mesmo um backup de imagem bem feito, coordenado pelo VSS, não substitui o backup do próprio SQL Server. A mesma página da Microsoft informa que o SQL Writer não faz backup de log. E é o backup de log que permite restaurar o banco até as 14h37 de uma terça-feira, e não até a meia-noite anterior. Numa empresa que emite nota fiscal o dia inteiro, a diferença é um dia de lançamentos.

O que precisa ser copiado

O ponto de partida é o modelo de recuperação de cada banco, porque ele decide o que dá para restaurar. A tabela resume a documentação de modelos de recuperação:

Modelo de recuperação	Backup de log	O que dá para restaurar
Simples	Não suporta	Só até o fim do último backup full ou diferencial
Completo (full)	Obrigatório	Até um ponto exato no tempo, se a sequência de backups estiver completa
Bulk-logged	Obrigatório	Até o fim de qualquer backup; não permite ponto exato no tempo

Um detalhe pesa para a PME: segundo a Microsoft, as edições Enterprise e Standard criam bancos no modelo completo por padrão, e o SQL Server Express cria no modelo simples. Ou seja, um ERP rodando sobre Express provavelmente não tem backup de log nenhum, e o melhor que se consegue é voltar ao último backup completo.

Os três tipos de backup trabalham juntos:

• Full: a cópia inteira do banco. É a base de tudo.
• Diferencial: só o que mudou desde o último full. Restaura mais rápido do que uma longa sequência de logs.
• Log de transações: tudo o que foi registrado no log desde o backup de log anterior. Só ele restaura até um horário exato. Para bancos movimentados, a Microsoft considera que um backup de log a cada 15 a 30 minutos pode ser suficiente.

E não são só os bancos do sistema. A Microsoft orienta fazer backup sempre de master, msdb e model, os bancos de sistema da instância. O msdb guarda os jobs agendados e o histórico de backups, e o tempdb não tem backup, porque é recriado a cada reinício.

Como fazer no próprio SQL Server

Para um banco que precisa de restauração até um ponto exato no tempo, a sequência é esta:

1. Colocar o banco no modelo completo. Sem isso, não existe backup de log.
2. Fazer o primeiro backup full. Os backups de log só começam a valer depois de existir um full.
3. Agendar os diferenciais. Por exemplo, uma vez por dia, entre os fulls.
4. Agendar os backups de log. A frequência define quanto trabalho a empresa aceita perder.
5. Usar CHECKSUM em todos. Com essa opção, o SQL Server confere as páginas durante o backup e falha se encontrar uma página corrompida, em vez de copiar o problema para dentro do backup.
6. Gravar fora do disco do banco. A Microsoft recomenda colocar os backups em outro local físico ou outro dispositivo, e não só em outra letra de unidade, já que vários volumes lógicos podem estar no mesmo disco.
7. Levar uma cópia para fora da empresa. O backup que fica só no servidor some junto com ele num incêndio, num roubo ou num ransomware.

Em T-SQL, os comandos seguem a sintaxe do BACKUP documentada pela Microsoft. Troque o nome do banco e o caminho de destino:

-- 1. Modelo completo (necessário para backup de log)
ALTER DATABASE ERP SET RECOVERY FULL;
GO

-- 2. Backup full
BACKUP DATABASE ERP
TO DISK = 'E:\Backup\ERP_full.bak'
WITH CHECKSUM;
GO

-- 3. Backup diferencial (o que mudou desde o último full)
BACKUP DATABASE ERP
TO DISK = 'E:\Backup\ERP_diff.bak'
WITH DIFFERENTIAL, CHECKSUM;
GO

-- 4. Backup de log de transações
BACKUP LOG ERP
TO DISK = 'E:\Backup\ERP_log.trn'
WITH CHECKSUM;
GO

Dois cuidados com esse roteiro. O primeiro: no modelo completo, o arquivo de log continua crescendo até haver um backup de log. Quem muda o modelo e esquece de agendar o log descobre o problema quando o disco enche. O segundo: o RESTORE VERIFYONLY confere se o arquivo de backup está completo e legível, mas, segundo a própria Microsoft, não verifica a estrutura dos dados lá dentro. A documentação de backup e restauração é direta: não existe estratégia de restauração enquanto os backups não forem testados, restaurando e rodando DBCC CHECKDB no banco restaurado.

Como automatizar

Nas edições Standard e Enterprise, o agendamento fica no SQL Server Agent, com jobs próprios ou planos de manutenção, que a Microsoft descreve como pacotes executados por um job do Agent.

O SQL Server Express é o caso típico da PME, e ele não tem SQL Server Agent. A Microsoft publica um artigo específico para isso, agendar e automatizar backups no SQL Server Express, com o caminho oficial: um procedimento armazenado que faz backup full, diferencial ou de log, chamado pelo sqlcmd e agendado no Agendador de Tarefas do Windows. O próprio artigo deixa os limites claros:

• O sqlcmd precisa rodar com a opção -b. Sem ela, ele devolve sucesso mesmo quando o backup falha, e o Agendador de Tarefas mostra a tarefa como concluída.
• O procedimento não apaga backups antigos. Sem limpeza, o disco enche.
• Bancos offline são ignorados sem aviso.
• O método não tem histórico de execução, nova tentativa nem alerta de falha.

Na prática, o backup automatizado no Express funciona, mas ninguém fica sabendo quando ele para de funcionar. É exatamente o problema que o monitoramento do job de backup resolve: o alerta precisa vir do resultado do backup, porque o “concluído” do agendador não prova nada.

O que uma solução gerenciada resolve

O script caseiro resolve o comando de backup. O que fica de fora é tudo o que acontece em volta dele, e é aí que os backups de banco costumam falhar.

Consistência sem depender de quem escreveu o script. Soluções de backup com suporte a aplicação trabalham junto com o SQL Server. No Acronis Cyber Protect, a documentação descreve dois caminhos: o backup de banco de dados, que copia os bancos e seus metadados, e o backup com reconhecimento de aplicação (application-aware), que é um backup de disco que também coleta os metadados do SQL Server. Em máquinas físicas, isso exige o Agent for SQL junto com o Agent for Windows, e o serviço SQL Writer ativo. Se o SQL Writer falhar, o backup falha, em vez de gerar uma cópia inconsistente.

Restauração do banco sem restaurar a máquina. Segundo a Acronis, a partir desse backup é possível recuperar bancos do SQL Server direto numa instância ativa ou como arquivos, sem restaurar o servidor inteiro.

Cópia fora do servidor e imutável. O backup vai para outro lugar automaticamente, e não para uma pasta do mesmo disco. Com retenção imutável, nem um administrador comprometido consegue apagar. Esse é o ponto do backup imutável contra ransomware, e é a lógica da estratégia 3-2-1 aplicada ao banco.

Alerta quando falha. Quem acompanha o job recebe o aviso no dia em que o backup não rodou, e não no dia em que precisou dele.

Teste de restauração periódico. Restaurar o banco num ambiente separado e conferir se ele abre é o teste que prova que o backup existe.

Um cuidado técnico, se a empresa combinar os dois mundos: no Acronis, a opção de truncamento de log vem ligada por padrão, e a documentação orienta desligá-la quando os backups de log são feitos pelo próprio SQL Server. Com as duas ferramentas cortando o log, a sequência de backups de log se quebra.

Critério	Script caseiro	Solução gerenciada
Consistência do banco	Depende do script e do SQL Writer	Backup com reconhecimento de aplicação, falha se o SQL Writer falhar
Restaurar até um horário exato	Possível, se os backups de log estiverem agendados e íntegros	Possível, conforme a configuração de backup de log
Cópia fora do servidor	Exige rotina extra de cópia	Automática, para outro local
Proteção contra exclusão	Arquivos apagáveis por quem tem acesso ao servidor	Retenção imutável disponível
Aviso de falha	Inexistente no Express sem monitoramento	Alerta por job
Teste de restauração	Manual, quando alguém lembra	Rotina periódica
Limpeza de backups antigos	Script à parte	Política de retenção

Quando o script caseiro basta

Há casos em que o backup nativo do SQL Server, bem agendado, resolve.

Um banco pequeno, de sistema que não é crítico e que pode voltar à noite anterior sem prejuízo real, funciona bem com um backup full diário, gravado fora do servidor e com uma cópia externa. Se a empresa tem alguém que confere o resultado todos os dias e testa a restauração de tempos em tempos, o risco fica controlado.

O script deixa de bastar quando o banco é o ERP, quando perder um dia de lançamentos tem custo e quando ninguém da empresa tem como acompanhar o backup todo dia. Nesse cenário, o que pesa é saber, toda manhã, que ele rodou, que a cópia saiu do servidor e que ela restaura.

Como a Global Data faz

No backup em nuvem para empresas da Global Data, o banco do ERP entra com rotina própria: modelo de recuperação revisado, backup com reconhecimento de aplicação, cópia fora do servidor e retenção definida pela necessidade da empresa. Operamos com Acronis Cyber Protect, acompanhamos os jobs e fazemos testes periódicos de restauração. Quando o problema é lentidão, e não backup, o caminho é o monitoramento de desempenho do banco de dados.

Perguntas frequentes

Copiar os arquivos .mdf e .ldf é backup?

Só se a cópia for coordenada com o SQL Server. Com o serviço rodando, o SQL Server mantém os arquivos trancados, e uma cópia feita por fora, sem o SQL Writer e o VSS, não garante que o banco abra depois. O caminho seguro é o comando BACKUP do próprio SQL Server ou uma solução de backup com reconhecimento de aplicação.

Qual a diferença entre backup full, diferencial e de log?

O full copia o banco inteiro. O diferencial copia só o que mudou desde o último full. O de log copia as transações registradas desde o backup de log anterior e é o único que permite restaurar até um horário exato. O backup de log só existe nos modelos de recuperação completo e bulk-logged.

Como agendar backup no SQL Server Express?

O Express não tem SQL Server Agent. A Microsoft orienta usar um procedimento armazenado de backup chamado pelo sqlcmd e agendado no Agendador de Tarefas do Windows, sempre com a opção -b para que a falha apareça. Esse método não tem alerta de falha nem limpeza de arquivos antigos, que precisam ser resolvidos à parte.

O backup do servidor inteiro já cobre o banco?

Cobre parcialmente. Um backup de imagem coordenado pelo VSS gera uma cópia consistente do banco no momento do backup, mas não produz backups de log. Sem eles, a restauração volta ao horário do último backup, e não a um ponto exato do dia.

Com que frequência testar a restauração?

Com a frequência que a empresa aceitaria descobrir que o backup não funciona. A Microsoft afirma que não existe estratégia de backup enquanto a restauração não for feita com sucesso, e recomenda rodar DBCC CHECKDB no banco restaurado. Para o banco do ERP, um teste periódico agendado é o mínimo.

Se a sua empresa não sabe até que horário conseguiria restaurar o banco do ERP hoje, a avaliação começa pelo modelo de recuperação e pelo último teste de restauração. Quero avaliar o backup do nosso SQL Server