Backup SQL Server: estratégia com RPO e RTO

Pergunte a qualquer empresa se ela faz backup do banco de dados e a resposta será “sim”. Agora pergunte quando foi a última vez que esse backup foi restaurado com sucesso e quanto tempo isso levou. Nesse momento, a resposta costuma mudar.

Ter arquivos de backup não é o mesmo que ter uma estratégia de backup SQL Server. Estratégia significa saber quanto dado a empresa aceita perder, quanto tempo pode ficar parada e ter certeza de que a recuperação funciona.

Comece pelo negócio: RPO e RTO

Antes de falar em tipos de backup, duas perguntas precisam ser respondidas pela gestão, não só pelo TI:

• RPO (Recovery Point Objective): quanto dado a empresa pode perder? 24 horas? 1 hora? 15 minutos?
• RTO (Recovery Time Objective): quanto tempo o sistema pode ficar fora do ar até ser recuperado?

Um e-commerce que perde uma hora de pedidos tem um prejuízo muito diferente de um sistema interno de cadastro que é atualizado uma vez por semana. A estratégia de backup precisa refletir essa realidade.

Os tipos de backup no SQL Server

Backup Full

Cópia completa do banco de dados. É a base de qualquer restauração.

Backup Diferencial

Contém tudo o que mudou desde o último backup full. Reduz o tempo de restauração, porque você aplica o full mais o último diferencial, em vez de todos os logs do período.

Backup de Log de Transações

Registra as transações desde o último backup de log. É o que permite recuperar o banco até um ponto específico no tempo (por exemplo, até 10h42, um minuto antes de alguém apagar uma tabela por engano). Só está disponível no modelo de recuperação FULL ou BULK_LOGGED.

Um exemplo de estratégia

Para um banco crítico com RPO de 15 minutos, uma estratégia comum seria:

• Backup full semanal (por exemplo, domingo de madrugada).
• Backup diferencial diário.
• Backup de log a cada 15 minutos.
• Cópia dos arquivos para um local fora do servidor (outro storage, outro site ou a nuvem).
• Retenção definida de acordo com as necessidades legais e do negócio.

Essa é uma referência. O desenho ideal depende do tamanho do banco, da janela de manutenção, do volume de alterações e do RTO desejado.

A regra 3-2-1

Uma boa prática consagrada em proteção de dados:

• 3 cópias dos dados;
• em 2 mídias ou tipos de armazenamento diferentes;
• com 1 cópia fora do local principal.

Backup guardado no mesmo disco do banco de dados não protege contra falha de disco, nem contra ransomware, nem contra a perda do servidor.

Ransomware: o backup também é alvo

Ataques de ransomware costumam procurar e criptografar os backups antes de atacar os dados principais. Por isso, considere:

• Cópias imutáveis ou isoladas (offline ou com bloqueio contra exclusão).
• Credenciais separadas para o repositório de backup.
• Criptografia dos arquivos de backup (Backup Encryption).
• Backup para o Azure Blob Storage com políticas de retenção protegidas.

O passo mais esquecido: testar a restauração

O backup só tem valor no momento do restore. Uma estratégia madura inclui:

• Restaurações periódicas de teste em um ambiente separado.
• DBCC CHECKDB no banco restaurado, para garantir que não há corrupção.
• Medição do tempo de restauração, para comparar com o RTO prometido.
• Procedimento documentado, para que a recuperação não dependa da memória de uma pessoa.

Em vários ambientes que analisei ao longo da carreira, o backup “funcionava” havia anos, mas ninguém tinha restaurado uma única vez. Esse é o tipo de risco que só aparece no pior momento possível.

Backup não é alta disponibilidade

Backup protege contra perda de dados. Alta disponibilidade reduz o tempo parado. São coisas complementares. Se o RTO é de poucos minutos, restaurar um banco grande a partir de backup pode não ser suficiente, e entram soluções como Always On Availability Groups, Log Shipping ou recursos nativos do Azure SQL.

E no Azure?

No Azure SQL Database e no Azure SQL Managed Instance, os backups automáticos são gerenciados pela plataforma, com restauração para um ponto no tempo dentro do período de retenção configurado. Ainda assim, é preciso definir retenção de longo prazo, testar restaurações e entender os limites de cada serviço. Em SQL Server rodando em máquina virtual, a responsabilidade continua sendo sua.

Checklist rápido

• Todos os bancos têm backup de acordo com o modelo de recuperação?
• Os backups estão fora do servidor?
• Existe cópia protegida contra ransomware?
• Há alerta quando um backup falha?
• A última restauração de teste foi há menos de um mês?
• O tempo de restauração atende ao RTO?

Se alguma resposta foi “não” ou “não sei”, vale a pena revisar a estratégia.

Perguntas frequentes

Backup da máquina virtual substitui o backup do SQL Server?

Não necessariamente. O backup de VM pode não garantir consistência transacional nem permitir restauração a um ponto específico no tempo. O ideal é ter backup nativo do SQL Server ou uma ferramenta que integre corretamente com ele.

Vocês revisam a estratégia de backup existente?

Sim. A revisão de backup faz parte do Health Check e do serviço de DBA Remoto da FABRIDATA.