SQL Server na prática

Log shipping: medir recuperação, não apenas tarefas verdes

Separe atrasos de backup, cópia e restauração e ensaie a troca de função com uma estimativa comprovável da possível perda de dados.

Log shipping pode oferecer uma cópia de recuperação com componentes relativamente simples. A principal armadilha operacional é interpretar uma tarefa bem-sucedida como prova de atendimento ao objetivo de recuperação. Uma cópia pode terminar corretamente quando o primário já parou de gerar backups. Uma restauração pode funcionar enquanto o arquivo mais recente permanece em outro servidor. O que importa é a distância entre a base recuperável e o trabalho do negócio.

Acompanhe um arquivo pelas três etapas

Siga um backup específico do log: criação no primário, chegada ao secundário e aplicação ao banco. Registre identidade e horários de cada etapa. Se backups são recentes, mas arquivos copiados são antigos, investigue compartilhamento, armazenamento e processo de cópia. Se arquivos chegam sem aplicação, procure erros, predecessores ausentes, leitores interferindo ou capacidade insuficiente de restauração.

Em uma instância configurada como monitor, o procedimento administrativo abaixo apresenta um resumo somente de leitura. Execute com as permissões necessárias. Analise resultados do primário e secundário juntos e confirme que o monitor recebe informações recentes.

USE master;
EXEC sys.sp_help_log_shipping_monitor;

Um registro antigo pode representar falha de telemetria. Confirme histórico local e arquivos reais antes de intervir. Por outro lado, essa hipótese não justifica descartar todos os alertas. Defina a idade máxima aceitável e teste a entrega da notificação, não apenas a existência da configuração.

Com backups a cada cinco minutos, cópias a cada dois e restaurações a cada dois, uma transação confirmada logo após o backup espera o próximo ciclo. Depois ainda pode aguardar as duas etapas seguintes. Esses horários não garantem cinco minutos máximos de perda. Execução real, falhas, filas e arquivos acessíveis depois do incidente determinam o resultado.

Torne atraso e retenção explícitos

Um atraso proposital pode manter a cópia anterior a uma exclusão acidental por tempo suficiente para intervir. Essa proteção depende da descoberta antes da aplicação do erro. Ela não substitui backups preservados de forma independente: a descoberta pode chegar tarde e um comprometimento compartilhado pode atingir várias cópias.

Separe a idade do último arquivo copiado da idade do último restaurado. O alerta de restauração deve considerar o atraso configurado e uma tolerância operacional justificada. A cópia ainda precisa avançar. Uma exceção geral para ambientes atrasados pode esconder uma cadeia realmente parada.

A retenção deve cobrir atraso, interrupções plausíveis e tempo para diagnosticar e recuperar a fila. Se a limpeza apagar um log necessário, um arquivo posterior válido não preenche a lacuna. Coordene outras ferramentas de backup. Um backup comum de log feito por outro produto pode criar um arquivo obrigatório que o processo nunca copia. Defina quem responde pela sequência inteira.

Ensaie a mudança de função

A troca é manual e controlada. Primeiro impeça que o antigo primário aceite gravações conflitantes. Se estiver acessível, avalie um backup final do log, copie e aplique todos os arquivos necessários disponíveis. Se não estiver, documente o último estado recuperável e a incerteza sobre transações posteriores.

Não execute a recuperação final apenas para verificar se a base abre. Depois disso, a sequência anterior não pode simplesmente continuar. Restabelecer proteção requer planejamento. Defina quando parar de esperar arquivos, quem aceita a possível perda e como os clientes serão redirecionados.

STANDBY pode oferecer leitura entre restaurações, mas leitores podem atrapalhar o calendário sem uma política de desconexão. Teste o modo escolhido e a combinação de versões suportada. Confira logins, tarefas, conexão da aplicação e dependências externas depois da troca. Meça até a primeira operação de negócio correta e guarde a sequência dos arquivos e o tempo observado como evidência operacional.

Referências técnicas: Microsoft Learn: Log shipping overview · Microsoft Learn: Monitor summary · Microsoft Learn: Manual failover.

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