SQL Server na prática

Recuperação pontual: escolher e comprovar o destino

Monte uma cadeia completa, escolha um destino STOPAT verificável e confira os dados de negócio antes de liberar a base recuperada.

Recuperar para um instante específico significa decidir quais transações pertencem à base resultante. "Logo antes da exclusão" ainda não é uma instrução executável. O operador precisa de um horário confiável, uma cadeia contínua e uma verificação de negócio que diferencie o estado correto de uma base apenas disponível. Este roteiro pressupõe recuperação completa e backups de log já estabelecidos.

Defina a fronteira de negócio

Imagine que uma implantação exclua as faturas erradas às 14:30. O log da aplicação pode registrar a chegada da requisição, embora a transação confirme depois. O navegador do cliente pode usar outro fuso. Correlacione evidências da base, identificadores de requisição e mudanças auditadas antes de escolher a fronteira. Preserve os dados originais em vez de sobrescrever imediatamente a base danificada.

Prefira restaurar em paralelo, com outro nome de banco e arquivos físicos separados. Isso mantém evidências para investigação e permite validar o resultado com o negócio. Reserve espaço e impeça que tarefas agendadas ou integrações tratem a cópia como produção. Restaurar o banco não desfaz um pagamento ou email já enviado por um sistema externo.

Registre a referência de horário adotada. O valor do exemplo representa a linha do tempo verificada do servidor, sem afirmar que seja UTC. Horários ambíguos na mudança sazonal precisam de ensaio específico. Escolher automaticamente o segundo anterior também pode excluir confirmações legítimas que exigirão conciliação.

Monte e aplique a cadeia

Comece com um backup completo cujo estado final preceda o destino. Acrescente um diferencial compatível se reduzir o trabalho sem ultrapassar a meta, e todos os logs necessários até aquele que contém o instante desejado. A fronteira segue a confirmação da transação. Uma transação iniciada antes, mas confirmada depois, não deve aparecer como trabalho confirmado.

Inspecione cabeçalhos e listas de arquivos reais. Nomes de arquivos e horários de conclusão não comprovam continuidade. Identifique posições dos conjuntos, todas as partes de backups distribuídos, chaves e nomes lógicos para MOVE. Um backup completo posterior ao erro não pode voltar no tempo com STOPAT em um log posterior.

O modelo pressupõe uma base isolada que já recebeu o backup completo correto e o diferencial opcional com NORECOVERY. Substitua os caminhos e repita para cada log necessário, na ordem. Use o mesmo destino em toda a sequência.

RESTORE LOG [RecoveryPractice]
FROM DISK=N'D:\Restore\required_log_001.trn'
WITH NORECOVERY, STOPAT='2025-05-12T14:29:59';
-- Repeat for every required log, with the same STOPAT.
-- Only after confirming that the target was reached:
-- RESTORE DATABASE [RecoveryPractice] WITH RECOVERY;

Enquanto a recuperação final não ocorrer, logs adicionais podem ser aplicados. Antes dessa etapa, confirme que a cadeia realmente alcança o instante solicitado. Se o destino estiver depois do último log disponível, procure os arquivos ausentes. Uma base ainda fechada não comprova sucesso nem perda definitiva. No modelo bulk-logged, operações minimamente registradas limitam a escolha de instantes dentro do backup correspondente.

Comprove o estado antes da liberação

Se a base original ainda estiver acessível, avalie um backup da cauda do log para preservar transações ainda não copiadas antes de qualquer restauração destrutiva. O procedimento depende do estado da base e do destino escolhido. Não improvise uma sobrescrita com WITH REPLACE durante o incidente.

Depois da recuperação, verifique integridade e invariantes de negócio: faturas afetadas presentes, alteração incorreta ausente, confirmações anteriores conhecidas preservadas e totais conciliados. Registre transações posteriores deliberadamente excluídas para repetição controlada. O estado ONLINE não demonstra essas condições.

Meça separadamente diagnóstico, obtenção dos arquivos, restauração, validação e reconexão da aplicação. Credenciais ausentes podem estourar o prazo mesmo com uma restauração rápida. Guarde a sequência exata dos arquivos e as consultas de verificação do ensaio, permitindo que outro operador reproduza a decisão sem depender da memória de quem participou.

Referências técnicas: Microsoft Learn: Point-in-time restore · Microsoft Learn: Tail-log backups.

Pergunte sobre este artigo

Tem alguma dúvida sobre este tema?

Conte o que você está avaliando ou onde encontrou dificuldades. Responderemos com uma recomendação prática.

Inquiries are not enabled in this preview.

Fazer uma pergunta sobre este artigo