Backup SQL Server: .BAK, Full e Diferencial Sem Furo

Mas Maurício, o banco de dados tá sendo “feito backup” todo dia — aquele arquivo .mdf que a gente copia na pasta de backup. Tá certo, né?

Infelizmente, não. Essa é uma das ilusões mais comuns — e mais perigosas — que eu vejo nas empresas que atendem sistema ERP em SQL Server. O arquivo está na pasta, o tamanho bate, ninguém nunca reclamou… até o dia que o servidor queima ou o ransomware chega e você descobre, da pior forma possível, que aquela cópia não abre.

Vou te explicar o porquê e como se faz o backup SQL Server (ou becape do SQL Server) do jeito certo: arquivo .BAK, estratégia full mais diferencial e o caminho do dado até a nuvem, longe do servidor.

Se você ainda está construindo o conceito de backup de banco de dados em geral — Firebird, MySQL, PostgreSQL — recomendo ler primeiro o backup de banco de dados para ter o mapa completo. Aqui a gente vai fundo no SQL Server.

Por que copiar o .mdf com o banco no ar não é backup?

O SQL Server mantém três tipos de arquivo no disco: o .mdf (dados primários), o .ndf (dados secundários, opcional) e o .ldf (log de transações). Quando o serviço está rodando, esses arquivos estão em uso ativo — o SQL Server tem páginas de dados na memória, transações em aberto e o log ainda não foi completamente sincronizado com o arquivo em disco.

Quando você copia o .mdf com o banco no ar, você captura esse estado no meio do caminho. O resultado é um arquivo que, na melhor das hipóteses, abre com erro de integridade. Na pior, nem abre — e você descobre isso no dia do restore, não antes.

Copiar o .mdf com o serviço rodando não é backup. É um arquivo corrompido esperando a hora certa pra te decepcionar.

O mesmo vale para aquela ideia de “exportar tabela pra Excel” ou tirar print do relatório. Esses recursos servem pra análise pontual, não pra recuperação do banco. Se o sistema cair, você não vai conseguir recriar dois anos de nota fiscal a partir de uma planilha.

O que é o arquivo .BAK e como ele é gerado?

O .BAK é o arquivo de backup nativo do SQL Server. Ele é gerado pelo comando BACKUP DATABASE, que o SQL Server executa internamente de forma consistente e atômica — captura todos os dados e o estado correto das transações, mesmo com o banco 100% online. Nenhum downtime.

Esse arquivo é o único formato que o RESTORE DATABASE aceita nativamente. Sem o .BAK gerado pelo comando correto, você não tem backup SQL Server — tem uma ilusão de backup.

O comando básico para gerar o .BAK de um banco específico:

-- Backup FULL do banco "SistemaERP"
BACKUP DATABASE [SistemaERP]
TO DISK = 'C:\WSPEED\Backup\SistemaERP_Full.BAK'
WITH FORMAT, MEDIANAME = 'SistemaERP', NAME = 'SistemaERP Full Backup', COMPRESSION;

O parâmetro WITH FORMAT cria um novo conjunto de mídia (recomendado para overwrite intencional). O COMPRESSION reduz o tamanho do arquivo sem custo perceptível de CPU em servidores modernos.

Qual a diferença entre backup full e backup diferencial no SQL Server?

Essa é a estratégia que separa uma proteção real de uma proteção que falha no detalhe. Entender a diferença é fundamental para quem gerencia ERP em SQL Server.

A grande vantagem do diferencial sobre o incremental (comum em outros SGBDs): para restaurar, você precisa de apenas dois arquivos — o full mais recente e o diferencial mais recente. Não tem corrente de arquivos para montar. Isso acelera o restore e reduz a margem de erro na hora do aperto.

A estratégia padrão que recomendo: full toda sexta à noite (ou madrugada de domingo) e diferencial de segunda a quinta no final do expediente. Se o servidor cair na quinta à tarde, você tem o full de domingo mais o diferencial de quarta — perde, no máximo, o movimento do dia.

Como configurar o job de backup no SQL Server?

Na prática, o jeito mais seguro é criar um script .sql com os comandos e agendar via SQL Server Agent. Assim o backup roda automático, sem depender de ninguém lembrar.

Script para backup full de todos os bancos do servidor (salve como BackupFull.sql):

DECLARE @path NVARCHAR(512) = 'C:\WSPEED\Backup\'
DECLARE @name NVARCHAR(256)
DECLARE @fileName NVARCHAR(512)
DECLARE @fileDate NVARCHAR(40)

SELECT @fileDate = CONVERT(NVARCHAR(20), GETDATE(), 112) -- formato AAAAMMDD

DECLARE db_cursor CURSOR READ_ONLY FOR
  SELECT name FROM master.sys.databases
  WHERE name NOT IN ('master','model','msdb','tempdb')
    AND state = 0          -- banco online
    AND is_in_standby = 0  -- não em modo standby

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name

WHILE @@FETCH_STATUS = 0
BEGIN
  SET @fileName = @path + @name + '_Full_' + @fileDate + '.BAK'
  BACKUP DATABASE @name
    TO DISK = @fileName
    WITH FORMAT, MEDIANAME = @name, NAME = @name, COMPRESSION
  FETCH NEXT FROM db_cursor INTO @name
END

CLOSE db_cursor
DEALLOCATE db_cursor

Para o diferencial, o script é quase idêntico — só muda o sufixo e o WITH DIFFERENTIAL:

-- Backup DIFERENCIAL (rode com o mesmo cursor, trocando o bloco interno)
BACKUP DATABASE [SistemaERP]
TO DISK = 'C:\WSPEED\Backup\SistemaERP_Dif.BAK'
WITH DIFFERENTIAL, MEDIANAME = 'SistemaERP', NAME = 'SistemaERP Diferencial', COMPRESSION;

Para chamar o script via linha de comando (útil em scripts .bat agendados pelo Windows Task Scheduler, como alternativa ao SQL Server Agent):

@echo off
set SERVIDOR=NOME-DO-SERVIDOR\INSTANCIA
set USUARIO=usuario_backup
set SENHA=SuaSenha

SQLCMD -S %SERVIDOR% -U %USUARIO% -P %SENHA% -b -i C:\Scripts\BackupFull.sql

:: Para autenticação Windows integrada (sem login/senha explícito):
:: SQLCMD -S %SERVIDOR% -E -b -i C:\Scripts\BackupFull.sql

Como restaurar um banco a partir do .BAK?

Mas Maurício, e na hora de restaurar — como funciona na prática?

Primeiro, uma consulta útil para confirmar o conteúdo do .BAK antes de restaurar:

-- Verifique o que tem dentro do arquivo .BAK
RESTORE HEADERONLY
FROM DISK = 'C:\WSPEED\Backup\SistemaERP_Full.BAK';

-- Confirme os caminhos dos arquivos .mdf e .ldf originais
RESTORE FILELISTONLY
FROM DISK = 'C:\WSPEED\Backup\SistemaERP_Full.BAK';

Com os nomes de arquivo confirmados, o restore completo (full + diferencial) segue esta ordem:

-- Passo 1: Restaure o FULL com NORECOVERY (deixa o banco em standby pra aplicar o diferencial)
RESTORE DATABASE [SistemaERP_Restaurado]
FROM DISK = 'C:\WSPEED\Backup\SistemaERP_Full.BAK'
WITH MOVE 'SistemaERP'     TO 'C:\SQLServer\Data\SistemaERP_restore.mdf',
     MOVE 'SistemaERP_log' TO 'C:\SQLServer\Log\SistemaERP_restore.ldf',
     NORECOVERY, REPLACE;

-- Passo 2: Aplique o DIFERENCIAL e finalize com RECOVERY
RESTORE DATABASE [SistemaERP_Restaurado]
FROM DISK = 'C:\WSPEED\Backup\SistemaERP_Dif.BAK'
WITH RECOVERY;

O NORECOVERY no primeiro passo é fundamental: ele deixa o banco em estado intermediário, pronto para receber o diferencial. Sem ele, o banco é finalizado antes do diferencial ser aplicado e você perde o movimento do período.

Se for restaurar só com o full (sem diferencial), use WITH RECOVERY direto no primeiro comando — o banco já sobe pronto.

O job parou e ninguém viu: o risco invisível do backup silencioso

Esse é o ponto que mais me preocupa. O script roda hoje, amanhã, na semana que vem… e um dia para. O SQL Server Agent falha, a pasta de destino fica sem espaço, a instância muda de nome depois de um update do Windows. O arquivo .BAK deixa de ser gerado — e ninguém percebe.

Semanas depois, o servidor vai ao ar. Aí você vai restaurar e descobre que o último backup válido tem 23 dias.

Duas medidas simples que evitam esse pesadelo:

• Alertas de falha no SQL Server Agent: configure notificação por e-mail no evento OnFailure de cada job de backup. Parece óbvio, mas a maioria dos servidores que visito não tem isso configurado.
• Verificação externa do arquivo: uma ferramenta de backup em nuvem que monitora a pasta e alerta se nenhum arquivo novo aparecer no horário esperado. Confirmação dupla — o job avisou que rodou, a nuvem confirmou que chegou um arquivo.

Essa é uma das razões pelas quais o discurso de “tenho job de backup no SQL Server Agent” não me tranquiliza sem confirmar os dois pontos acima. Já cheguei em servidor onde o job tinha parado faz semanas — e o técnico responsável não sabia, porque o script “sempre rodou”. Quando descobriram, era tarde demais pra não perder dados.

O .BAK na pasta local não é backup off-site — e isso importa muito

Você configurou o job, os alertas funcionam, o .BAK é gerado toda noite. Ótimo. Mas se esse arquivo está só na mesma máquina — ou num HD externo plugado no servidor — você ainda tem um ponto único de falha.

Ransomware (sequestro de dados) cifra o servidor e a pasta de backup local juntos. Incêndio, enchente ou roubo levam o hardware e os arquivos na mesma viagem. Na enchente do Rio Grande do Sul de 2024, eu recolocei 9 clientes de pé em dias — porque os dados deles estavam na nuvem, longe da inundação. Quem só tinha cópia local perdeu tudo.

O .BAK precisa sair do servidor e ir para fora. O fluxo completo seguro é:

1. SQL Server Agent gera o .BAK na pasta local.
2. Solução de backup em nuvem monitora a pasta e envia cada novo arquivo para a nuvem criptografada.
3. Nuvem retém versões por 7, 15 ou 30 dias — você escolhe.
4. Restore testado mensalmente em ambiente separado.

Aqui na WSpeed, o Backblaze B2 é o nosso armazenamento primário — especializado em backup, mais econômico que outros provedores. O AWS S3 fica disponível como opção adicional. Os arquivos chegam criptografados com AES-256, sem ação manual da sua parte.

E tem mais: o backup em nuvem para empresas da WSpeed vem com garantia em contrato. Não é promessa de marketing — é cláusula de multa se não recuperarmos os seus dados. Simples assim: se errarmos, vai machucar a gente também. Isso nos obriga a fazer direito — e nos obriga a testar.

Se você é o TI que cuida de vários clientes com SQL Server e quer montar isso como serviço gerenciado, vale conhecer as nossas soluções para empresas de TI.

E se ainda está construindo a base de entendimento sobre o que é backup antes de partir pro técnico, esse post é o ponto de partida certo.

Agora me conta nos comentários: qual foi o backup de SQL Server mais doloroso que você já viu falhar? Job silencioso? .mdf copiado no ar? Restore que não subiu? Pode contar — aqui a gente aprende junto.

Abraço e até o próximo artigo ou vídeo.