Backup de SQL Server: Boas Práticas para Empresas

Por que backup de SQL Server exige estratégia própria

Um banco de dados SQL Server não pode ser tratado como uma pasta comum de arquivos. Enquanto o backup de documentos aceita uma cópia diária simples, o arquivo .mdf de um banco em produção está permanentemente aberto e sendo modificado — páginas de dados são gravadas, transações ficam pendentes em memória e o log registra cada operação. Copiar esse arquivo com uma ferramenta genérica de backup, sem integração com o mecanismo do SQL Server, produz na melhor das hipóteses um arquivo inconsistente e, na pior, uma falsa sensação de proteção que só será descoberta no dia da restauração.

Por isso o SQL Server implementa seu próprio subsistema de backup, capaz de gerar cópias transacionalmente consistentes com o banco online, sem derrubar a aplicação. Esse subsistema entende o ciclo de vida das transações: ele sabe quais operações já foram confirmadas, quais estavam em andamento no momento da cópia e como reconciliar tudo isso durante o processo de recuperação. É essa inteligência que permite restaurar um banco de 400 GB para um ponto exato no tempo — algo impossível com uma cópia bruta de arquivo.

Na prática, a maioria das empresas que sofre perda de dados em SQL Server não perdeu por falta de backup. Perdeu porque o backup existia mas cobria apenas parte do necessário: só o full semanal, sem log; ou o log configurado mas nunca testado; ou a rotina apontando para um disco local que morreu junto com o servidor. Estratégia de backup de banco não é a escolha de uma ferramenta — é a definição de quanto dado a empresa aceita perder e a montagem do conjunto de cópias que garante esse número.

Recovery model: a decisão que define tudo o mais

Antes de agendar qualquer rotina, é preciso definir o recovery model do banco. Essa configuração determina como o SQL Server trata o log de transações e, por consequência, quais tipos de backup ficam disponíveis. São três opções, e escolher errado inviabiliza toda a estratégia posterior.

• SIMPLE — o log de transações é truncado automaticamente a cada checkpoint. O log nunca cresce descontroladamente, mas também não pode ser copiado. Consequência direta: você só consegue restaurar até o último backup full ou diferencial. Se o full foi às 22h e o banco morreu às 17h, perdeu 19 horas de trabalho.
• FULL — todas as transações ficam registradas no log até que este seja copiado por um backup de log. Permite restauração para qualquer ponto no tempo (point-in-time recovery). É o modelo obrigatório para qualquer banco transacional de produção — ERP, sistema financeiro, e-commerce, prontuário eletrônico.
• BULK_LOGGED — variação do FULL que reduz o volume de log em operações de carga em massa (BULK INSERT, criação de índices). Útil em janelas específicas de ETL, mas sacrifica o point-in-time durante essas operações. Usado pontualmente, nunca como padrão permanente.

O erro mais comum e mais caro do mercado é manter um banco de produção em SIMPLE por comodidade — porque assim "o log não enche o disco". O log enche o disco em modelo FULL exatamente quando ninguém está fazendo backup de log. A solução não é abandonar o modelo FULL; é implementar a rotina de log que já deveria existir. Trocar o recovery model para SIMPLE só para conter crescimento de log é trocar um problema de espaço por um problema de perda de dados.

Os três tipos de backup e como eles se combinam

O SQL Server trabalha com três tipos de backup que se complementam. Entender a mecânica de cada um é o que permite montar uma cadeia eficiente em vez de acumular cópias redundantes.

O backup full copia todas as páginas de dados usadas do banco, mais a porção do log necessária para deixá-lo consistente. É autossuficiente: com um full na mão, você restaura o banco inteiro. Também é o mais pesado — um banco de 500 GB gera um full de tamanho próximo a isso, e a leitura completa impacta I/O do servidor. Rodar full de hora em hora é inviável em qualquer volume relevante.

O backup diferencial copia apenas as extensões (blocos de 64 KB) modificadas desde o último backup full. Como o SQL Server mantém um mapa interno (DCM — Differential Changed Map) das extensões alteradas, o diferencial é rápido e enxuto logo após o full, mas cresce progressivamente conforme o banco é modificado. Ponto crítico frequentemente ignorado: o diferencial é sempre relativo ao último full. Se alguém rodar um full fora da rotina — uma cópia ad hoc para um ambiente de teste, por exemplo — os diferenciais seguintes passam a se referir a esse full avulso, e a cadeia de restauração quebra. Para cópias pontuais, use sempre a opção COPY_ONLY, que não interfere na cadeia.

O backup de log de transações copia todos os registros de log gerados desde o último backup de log, e em seguida trunca a porção já copiada, liberando espaço para reutilização. É o componente que entrega granularidade fina: um backup de log a cada 15 minutos significa que a perda máxima em um desastre é de 15 minutos de transações. É também o mecanismo que controla o crescimento do arquivo .ldf — sem ele, em modelo FULL, o log cresce até esgotar o disco.

Definindo RPO e RTO antes de agendar qualquer job

Toda a estratégia decorre de dois números que precisam ser definidos com a área de negócio, não pela TI isoladamente. O RPO (Recovery Point Objective) responde: quanto de dado a empresa aceita perder, medido em tempo? O RTO (Recovery Time Objective) responde: quanto tempo o sistema pode ficar indisponível durante a recuperação?

RPO é definido pelo negócio, não pela TI. Se o financeiro emite 200 notas por hora, um RPO de 4 horas significa aceitar o retrabalho de 800 notas. Essa conta precisa ser feita com quem responde pelo processo — e assinada.

O RPO determina a frequência do backup de log, de forma direta: RPO de 15 minutos exige log a cada 15 minutos, RPO de 1 hora permite log de hora em hora. Já o RTO determina a arquitetura da cadeia. Restaurar um full de domingo seguido de 6 dias de logs a cada 15 minutos significa aplicar centenas de arquivos sequencialmente — pode levar horas. Inserir um diferencial diário reduz drasticamente esse tempo: restaura-se o full, depois um único diferencial, depois apenas os logs do dia corrente.

Uma configuração equilibrada para a maioria dos ambientes corporativos de médio porte fica assim:

1. Full — semanal, na madrugada de domingo, fora da janela operacional.
2. Diferencial — diário, na madrugada, de segunda a sábado.
3. Log — a cada 15 a 30 minutos durante o horário de operação; a cada hora no período noturno.
4. Retenção — 4 semanas em disco rápido, 12 meses em armazenamento secundário ou nuvem.
5. Cópia externa — replicação diária para site remoto ou object storage, atendendo à regra 3-2-1.

Essa combinação entrega RPO de 15 minutos com um consumo de storage muito inferior ao de fulls diários, e mantém o RTO controlado porque a restauração nunca precisa encadear mais de um dia de logs.

Storage, compressão e verificação: onde a economia é real

O medo de inflar o storage costuma ser o motivo pelo qual empresas reduzem a frequência de backup — e é um medo mal calibrado. A compressão nativa de backup do SQL Server, disponível nas edições Standard e Enterprise, reduz o tamanho dos arquivos tipicamente entre 60% e 80%, dependendo da natureza dos dados. Habilitá-la é uma linha na instrução de backup e reduz simultaneamente espaço em disco, tempo de gravação e tráfego de rede para o destino remoto.

Backups de log, por sua vez, são naturalmente pequenos. Um banco com carga transacional moderada gera talvez algumas dezenas de megabytes de log a cada 15 minutos. Multiplicado por 96 execuções diárias, ainda representa uma fração do tamanho de um único full. O argumento de que "log a cada 15 minutos vai lotar o storage" quase nunca se sustenta quando os números são efetivamente medidos.

Mais relevante que o volume é a integridade. Um backup nunca verificado é uma hipótese, não uma proteção. Duas práticas são obrigatórias: usar CHECKSUM na gravação do backup, para que o SQL Server valide as páginas durante a cópia e falhe imediatamente se detectar corrupção; e executar RESTORE VERIFYONLY após cada job, confirmando que o arquivo é legível e está completo. Ambas custam pouco e capturam o problema no dia em que ele nasce, não seis meses depois.

Acima disso está o teste de restauração real. Ao menos uma vez por trimestre, o backup deve ser restaurado em um servidor de homologação, com o banco aberto, consultas executadas e o resultado conferido. É esse exercício que revela os problemas que nenhuma verificação automática detecta: a senha do service account que ninguém lembra, o job que copia o banco mas não os logins, o certificado de TDE que ficou apenas no servidor original.

Quanto à localização, vale a regra 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, com uma delas fora do site. Backup gravado no mesmo servidor — ou pior, no mesmo array — não protege contra falha de hardware, incêndio ou ransomware. Ataques modernos procuram ativamente por arquivos .bak na rede e os criptografam junto com os dados originais. Cópia offsite com imutabilidade deixou de ser luxo e virou requisito básico.

Como a Duk estrutura o backup de SQL Server dos clientes

Ao longo de mais de 18 anos atendendo empresas de todos os portes, a Duk Informática & Cloud consolidou um método que começa antes de qualquer configuração técnica: o levantamento do RPO e do RTO com as áreas de negócio. Só depois de ter esses números validados é que a arquitetura de backup é desenhada — recovery model, frequência de cada tipo de cópia, retenção, destino primário e destino externo.

Como Microsoft Gold Partner, trabalhamos com as ferramentas nativas do SQL Server integradas a soluções corporativas de proteção de dados, com replicação para nosso data center próprio em Alphaville e opção de cópia imutável contra ransomware. O monitoramento é contínuo: cada job de backup é acompanhado, falhas geram alerta imediato e os testes de restauração entram no calendário de manutenção preventiva, com relatório entregue ao cliente.

São mais de 550 empresas atendidas, muitas delas com bancos críticos onde uma hora de indisponibilidade tem custo direto mensurável. A experiência acumulada nesses ambientes mostra sempre o mesmo padrão: a diferença entre um incidente contornado em 40 minutos e uma crise de três dias raramente está na ferramenta contratada — está em ter a cadeia de backup desenhada corretamente e testada antes de precisar dela.

Se a sua empresa opera SQL Server e não tem certeza de qual é o RPO real hoje — ou nunca restaurou um backup para validar —, vale uma avaliação da estratégia atual. É um diagnóstico rápido que costuma revelar lacunas simples de corrigir agora e muito caras de descobrir depois.