SQL Server Log Shipping: Guia completo para DBA [2026]

SQL Server O envio de logs é uma solução automatizada de recuperação de desastres que mantém cópias de espera ativa dos seus bancos de dados de produção. Essa tecnologia transfere backups de logs de transações de um banco de dados primário em uma instância de servidor primário para um ou mais bancos de dados secundários em instâncias de servidor secundárias separadas, garantindo que seus bancos de dados secundários permaneçam sincronizados com o banco de dados primário e fornecendo proteção contra perda de dados e falhas de servidor.

1.2 Objetivo e benefícios do transporte de toras

O envio de logs serve a vários propósitos críticos na administração de bancos de dados:

Sua principal função é a recuperação de desastres, fornecendo um destino de failover confiável quando seu servidor principal fica indisponível devido a falha de hardware, corrupção de software ou eventos catastróficos que afetam seu centro de dados.
Também é uma opção economicamente viável. solução de alta disponibilidadeAo contrário dos recursos de nível empresarial que exigem licenciamento caro, o envio de logs funciona com SQL Server Edição padrão, tornando-a acessível para organizações com restrições orçamentárias.
Bancos de dados secundários em modo de espera oferecem valor adicional além da recuperação de desastres. Os administradores de banco de dados podem usá-los para geração de relatórios somente leitura, descarregando as cargas de trabalho de consultas do servidor de produção.
O recurso de restauração atrasada oferece proteção contra modificações acidentais de dados. Ao configurar um atraso na restauração, você cria uma janela de tempo para se recuperar de erros do usuário antes que alterações destrutivas atinjam seu banco de dados secundário.

2. SQL Server Componentes e fluxo de trabalho do Log Shipping

O transporte de toras de madeira consiste nos seguintes componentes:

Servidor primário e banco de dados primário: O servidor primário representa sua produção. SQL Server instância que executa o banco de dados primário.
Compartilhamento de backup: Local intermediário para armazenar e transferir os backups do log de transações do servidor primário para os servidores secundários.
Servidores secundários e bancos de dados secundários: Os servidores secundários hospedam as cópias de espera ativa do seu banco de dados primário.
Servidor de monitoramento (opcional): Este servidor rastreia o histórico e o status de todas as operações de backup, cópia e restauração em toda a sua topologia de envio de logs.
Tarefas do agente: Incluindo tarefas de backup, cópia, restauração e alerta, automatizando todo o processo de envio de logs.

O fluxo de trabalho de automação é o seguinte:

A tarefa de backup é executada no servidor primário e cria backups do log de transações do banco de dados primário no compartilhamento de backup.
A tarefa de cópia é executada em cada servidor secundário e transfere os arquivos de backup de log do compartilhamento de backup para o(s) servidor(es) secundário(s).
A tarefa de restauração é executada em cada servidor secundário e aplica backups copiados do log de transações ao banco de dados secundário.
A tarefa de alerta é executada no servidor de monitoramento e verifica se as operações de backup e restauração foram concluídas dentro dos prazos aceitáveis.

3. Pré-requisitos e Requisitos

3.1 SQL Server Requisitos da versão

O envio de toras de madeira está disponível desde SQL Server 2000 e continua sendo suportado em todas as versões subsequentes a partir de 2000. SQL Server De 2005 a 2025. Esse suporte de longa data demonstra a estabilidade e a relevância contínua da tecnologia.

3.2 SQL Server Requisitos de edição

O envio de logs funciona com as edições Standard, Workgroup, Enterprise e Developer do [nome do produto/serviço]. SQL ServerEste amplo suporte a edições torna o envio de logs acessível para organizações sem licenças da Enterprise Edition, ao contrário de recursos como... Grupos de Disponibilidade Always On que requerem edições Enterprise ou de avaliação.

Observação: a Express Edition não oferece suporte ao envio de toras de madeira.

3.3 Requisitos do Modelo de Recuperação de Banco de Dados

O envio de logs exige que o banco de dados primário utilize o modelo de recuperação completa ou o modelo de recuperação com logs em massa. O modelo de recuperação simples não é suportado porque SQL Server Trunca automaticamente os registros de transações, interrompendo a cadeia contínua de registros necessária para o envio de logs.

Para obter mais detalhes sobre os modelos de recuperação, consulte nosso guia completo sobre SQL Server backup.

4. Configurando o Log Shipping usando o SSMS

4.1 Criar pasta para compartilhamento de backup

Antes de configurar o envio de logs, prepare a pasta compartilhada de backup onde os backups dos logs de transação serão armazenados e transferidos.

No servidor principal ou em um servidor de arquivos dedicado, crie uma pasta (por exemplo, C:\Backup)
Clique com o botão direito na pasta e selecione Propriedades
Clique na compartilhando aba
Clique Compartilhamento avançado
Verifique Compartilhe essa pasta
Clique Permissões e conceder Controle total permissão para o SQL Server conta de serviço Serviço NT\MSSQLSERVER.
Clique OK aplicar.
Documente o caminho de rede (UNC) (por exemplo, \\NOME-DO-SERVIDOR\Backup)

4.2 Habilitar e configurar o envio de logs

Clique com o botão direito do mouse no banco de dados principal e selecione Propriedades.
De acordo com o relatório Propriedades do banco de dados diálogo, selecione o Registro de transações de envio página no painel esquerdo.
Verifique Habilite este banco de dados como primário em uma configuração de envio de logs. Para ativar o envio de logs.
Em seguida, você pode configurar as opções de backup, o servidor secundário e o servidor de monitoramento nesta página de propriedades. Abordaremos esses recursos nas subseções a seguir.

4.2.1 Configurar as definições de backup

Clique na Configurações de backup botão
De acordo com o relatório Configurações de backup do log de transações diálogo, sob Caminho de rede para a pasta de backup campo, insira o caminho UNC (ex: \\NOME-DO-SERVIDOR\Backup)
Se a pasta de backup estiver localizada no servidor primário, insira o caminho local (por exemplo, C:\Backup)
Configure outras definições, como o período de retenção de backups, o limite de alertas, a tarefa de backup e a compressão.
Clique OK Para confirmar as configurações e fechar a caixa de diálogo.

4.2.2 Configurar instância de servidor secundário e banco de dados

Clique Adicione para Instâncias de servidor secundárias e bancos de dados
De acordo com o relatório Configurações do banco de dados secundário diálogo, clique em Conecte-se para conectar-se à instância do servidor secundário.
De acordo com o relatório Banco de dados secundário No menu suspenso, selecione um banco de dados existente ou digite o nome de um novo banco de dados.
De acordo com o relatório Inicializando o banco de dados secundário guia, selecione Sim, gere um backup completo do banco de dados primário e restaure-o no banco de dados secundário (e crie o banco de dados secundário, se ele não existir).
Clique na Copiar arquivos aba
De acordo com o relatório Pasta de destino para arquivos copiados (Essa pasta geralmente está localizada no servidor secundário)Insira o caminho local da pasta de destino no servidor secundário.
Certifique-se de que a pasta existe e que... SQL Server A conta de serviço possui permissões de escrita.
Clique OK Para confirmar as configurações e fechar a caixa de diálogo.

4.2.3 Configurar servidor de monitoramento

Verifique Use uma instância de servidor de monitoramento.
Clique Configurações
Clique Conecte-se para conectar-se à instância do servidor de monitoramento
Conjunto Excluir histórico após Para especificar o período de retenção em horas.
Clique OK Para confirmar as configurações e fechar a caixa de diálogo.

4.2.4 Revisão e Conclusão da Configuração

Analise todas as configurações em Registro de transações de envio página
Verifique as configurações de backup, as configurações do servidor secundário e as configurações de monitoramento.
Clique OK para aplicar a configuração
O assistente cria todas as tarefas necessárias nos servidores primário, secundário e de monitoramento.
Clique Fechar quando a configuração for concluída

5. Vantagens e desvantagens do transporte de toras

5.1 benefícios de SQL Server Envio de toras

Solução econômica: Funciona com SQL Server A Standard Edition elimina os dispendiosos requisitos de licenciamento da Enterprise Edition. Isso torna a recuperação de desastres confiável acessível a organizações com orçamentos limitados.
Fácil de configurar e manter: O assistente de configuração guia os administradores durante a instalação com opções claras. A maioria dos bancos de dados pode ser configurada em 15 a 30 minutos sem treinamento especializado.
Suporte a múltiplos servidores secundários: Suporte vários servidores secundários sem limitações arquitetônicas. Implante um servidor secundário para recuperação de desastres local, outro remotamente e um terceiro para geração de relatórios.
Impacto mínimo no servidor primário: Opera de forma assíncrona, eliminando a sobrecarga de sincronização no servidor principal. Os tempos de confirmação das transações permanecem inalterados.
Utiliza backups de logs de transações existentes: Os backups de envio de logs são backups padrão de logs de transações, utilizáveis para recuperação pontual, independentemente do envio de logs.
Opção de restauração atrasada: O recurso de atraso na restauração oferece proteção contra modificações acidentais de dados, indisponível em soluções de replicação em tempo real.
Não é necessário armazenamento compartilhado: Utiliza armazenamento independente em cada servidor, eliminando a necessidade de armazenamento compartilhado e os custos associados.
Suporte multiplataforma: Funciona da mesma forma tanto no Windows quanto no Linux. SQL Server implantações.
Funciona em diversas áreas: Não requer relações de confiança de domínio nem integração com o Active Directory.

5.2 Desvantagens e Limitações do Transporte de Toras

Sem failover automático: A principal limitação é a necessidade de failover manual. Os administradores precisam executar várias etapas antes que o serviço seja retomado.
Atraso na sincronização de dados: Os bancos de dados secundários sempre ficam atrás dos bancos de dados primários em termos de frequência de backup e restauração.
Configuração apenas no nível do banco de dados: A configuração é feita no nível do banco de dados, e não no nível da instância. Proteger 50 bancos de dados requer 50 configurações separadas.
Alterações manuais na string de conexão: Após a falha, os aplicativos devem atualizar as cadeias de conexão para apontar para o servidor secundário.
Interrupções secundárias do banco de dados: Em modo de espera, os bancos de dados secundários desconectam os usuários durante as operações de restauração.
Gerenciamento de banco de dados separado: Cada configuração de banco de dados deve ser gerenciada individualmente, sem recursos de gerenciamento coordenado.

6. Melhores Práticas e Casos de Uso

6.1 Quando usar o Log Shipping

Recuperação de desastres com baixo orçamento: Destaca-se como uma solução de recuperação de desastres com excelente custo-benefício para organizações que não conseguem justificar os custos de licenciamento da versão Enterprise.
Requisitos moderados de RPO/RTO: Aplicações que toleram 15 a 30 minutos de perda de dados e 30 a 60 minutos de inatividade se encaixam perfeitamente em suas capacidades.
Servidor de Relatórios Somente Leitura: Crie cópias somente leitura para cargas de trabalho de geração de relatórios que tolerem desconexões periódicas.
Ambientes da Edição Padrão: Organizações padronizadas em SQL Server A Standard Edition não tem acesso aos Grupos de Disponibilidade Always On, tornando o envio de logs a melhor opção disponível.
Projetos de Migração de Servidores: Facilita a migração de servidores, mantendo cópias sincronizadas durante os períodos de transição.
Requisitos de dados atrasados: Configure atrasos na restauração para manter os bancos de dados em pontos fixos no passado para fins de conformidade ou auditoria.

6.2 Quando NÃO usar o Log Shipping

Requisitos de tempo de inatividade praticamente nulo: Aplicações com requisitos de RTO inferiores a 15 minutos não podem depender de failover manual.
Necessidade de failover automático: Inadequado quando os requisitos de negócio exigem failover automático sem intervenção do administrador.
Sincronização em tempo real necessária: Aplicações que exigem dados em tempo real ou quase em tempo real em servidores secundários não podem aceitar a latência inerente ao envio de logs.
Tolerância mínima à perda de dados: Organizações com RPO medido em segundos ou que exigem zero perda de dados precisam de soluções síncronas.

6.3 melhores práticas

Otimização da frequência de backup: Equilibre a frequência de backup com a sobrecarga do sistema e os objetivos de recuperação. Comece com intervalos de 15 minutos e ajuste conforme as necessidades reais.
Considerações sobre o caminho da rede: Use caminhos UNC em vez de unidades mapeadas para os locais de backup. Coloque os compartilhamentos de backup em uma infraestrutura de rede confiável.
Configuração de monitoramento e alertas: Configure alertas para falhas em tarefas de backup, cópia e restauração imediatamente após a conclusão da configuração do envio de logs.
Cronograma de testes regulares: Agende testes de failover trimestrais ou semestrais para validar os procedimentos e manter a prontidão do administrador.
Manutenção de documentação: Mantenha manuais de procedimentos detalhados, documentando as configurações, os procedimentos de failover e as etapas de solução de problemas.
Considerações de segurança: Utilize contas de serviço dedicadas com as permissões mínimas necessárias. Restrinja as permissões de compartilhamento de rede adequadamente.
Gerenciamento de espaço em disco: Monitore continuamente o espaço em disco nos locais de backup. Configure alertas para quando o espaço ficar abaixo de 20%.
Configuração da política de retenção: Defina períodos de retenção de backup maiores do que o atraso máximo de sincronização aceitável.
Restaurar atraso para proteção: Configure os atrasos de restauração quando a proteção contra modificações acidentais justificar um aumento na latência de sincronização.

7. Solução de problemas comuns

7.1 Falhas nas tarefas de backup

Espaço em disco insuficiente: Verifique o histórico de tarefas em busca de erros de espaço em disco. Verifique o espaço disponível e o espaço livre excluindo backups antigos ou ativando a compactação.
Problemas de permissão: Verifique o SQL Server A conta de serviço possui permissões de Controle Total tanto na pasta local quanto no compartilhamento de rede.
Banco de dados não está totalmente recuperado: Volte ao modelo de recuperação completa e faça um backup completo para reiniciar a cadeia de logs de transações.

7.2 Falhas na Cópia de Tarefas

Caminho de rede inacessível: Teste a conectividade do servidor secundário mapeando o caminho de rede manualmente.
Problemas de autenticação: Configure credenciais explícitas para acesso ao compartilhamento de rede caso os servidores estejam em domínios diferentes.
Problemas de bloqueio de arquivos: Exclua a pasta de backup da verificação em tempo real do antivírus para evitar bloqueios de arquivos.

7.3 Restaurar falhas de tarefas

Arquivos de backup ausentes: Verifique se os arquivos existem na pasta de destino e confira o histórico de tarefas de cópia.
Erro na sequência de restauração: Identificar backups de logs de transações ausentes e restaurá-los em sequência para reparar a cadeia de logs.
Banco de dados em estado incorreto: Reinicialize o envio de logs restaurando um backup completo com NORECOVERY caso alguém tenha recuperado o banco de dados.
Corrupção de arquivos de banco de dados: Se as falhas de restauração persistirem apesar da sequência e configuração corretas, os próprios arquivos do banco de dados podem estar corrompidos. Nesses casos, pode ser necessário usar uma solução especializada. ferramenta de recuperação de SQL Para extrair dados dos arquivos .MDF e .NDF danificados antes de tentar reinicializar o envio de logs.

7.4 Problemas de atraso de sincronização

Limitações de largura de banda da rede: Ative a compressão de backup para reduzir o tamanho dos arquivos e os requisitos de largura de banda.
Alto volume de transações: Considere aumentar a frequência de backups para criar arquivos de backup menores e mais fáceis de gerenciar.
Frequência de restauração inadequada: Aumente a frequência das tarefas de restauração para se aproximar da frequência de backup e minimize o atraso.

7.5 Monitorar problemas de conectividade do servidor (SQL 2025)

Erros do provedor OLE DB: SQL Server A criptografia obrigatória padrão de 2025 entra em conflito com instâncias mais antigas que não possuem a configuração de criptografia adequada.
Configuração de criptografia incompatível: Verifique a configuração do servidor vinculado no servidor de monitoramento e confira as configurações de criptografia.
Soluções alternativas: Remova e recrie o envio de logs usando parâmetros TLS 1.3 ou atualize todas as instâncias para SQL Server 2025.

7.6 SQL Server Problemas com o serviço do agente

Serviço não iniciado: Verifique o status do serviço do Agente e configure-o para iniciar automaticamente.
Horário de trabalho desativado: Verifique o status da programação de tarefas e ative as programações desativadas.
Falhas em etapas do trabalho: Analise o histórico do trabalho para identificar etapas com falha e mensagens de erro específicas.

8. Perguntas frequentes (FAQ)

P: Posso usar o envio de toras de madeira com a Express Edition?

A: Não, SQL Server A Express Edition não suporta o envio de logs, pois não possui... SQL Server Agente.

P: Com que frequência devo agendar backups de logs?

A: Os intervalos padrão de 15 minutos oferecem um equilíbrio razoável. Ajuste-os com base no seu objetivo de recuperação.

P: É possível usar bancos de dados secundários para gerar relatórios?

A: Sim, os bancos de dados secundários configurados em modo de espera permitem acesso somente leitura entre as operações de restauração.

P: O que acontece se o servidor primário falhar?

A: Execute o failover manual para colocar um banco de dados secundário online. A perda de dados é igual ao atraso de sincronização no momento da falha.

P: Posso ter vários servidores secundários?

A: Sim, o envio de logs suporta um número ilimitado de servidores secundários com configurações independentes.

P: Como calculo o atraso de sincronização?

A: Compare o último registro de data e hora restaurado do log de transações com a hora atual usando as tabelas de monitoramento de envio de logs.

P: O envio de logs pode funcionar em domínios diferentes?

A: Sim, funciona em diferentes domínios ou em ambientes de grupo de trabalho sem exigir relações de confiança.

P: Qual a diferença entre o modo "Sem Recuperação" e o modo de espera?

A: O modo de não recuperação mantém o banco de dados inacessível. O modo de espera permite consultas somente leitura entre as restaurações.

P: Posso pausar o envio de logs temporariamente?

A: Sim, desative as tarefas de backup, cópia e restauração para pausar a sincronização, preservando a configuração.

P: Como faço para remover a configuração de envio de logs?

R: No Registro de transações de envio página de propriedades:

Desmarcar Habilite este banco de dados como primário em uma configuração de envio de logs.
Clique OK Para remover a configuração e excluir os trabalhos.

P: Posso alterar o banco de dados secundário para o modo de leitura e gravação?

A: Sim, execute RESTORE DATABASE WITH RECOVERY, mas isso interrompe a cadeia de envio de logs.

P: Qual é o atraso máximo que posso configurar para a restauração?

A: Não existe um limite rígido. Configure atrasos de minutos a dias, de acordo com suas necessidades de proteção.

P: Como o envio de logs afeta a estratégia de backup?

A: Ele cria backups de logs de transações que podem ser usados tanto para envio de logs quanto para recuperação pontual.

P: Posso usar o envio de logs para migração de servidor?

A: Sim, configure o envio de logs para o novo servidor, sincronize e, em seguida, execute o failover planejado do servidor antigo durante a manutenção.

P: Quais ferramentas de monitoramento funcionam com o envio de logs?

A: SQL Server O Management Studio inclui relatórios integrados. Ferramentas de terceiros, como o SQL Monitor e o SolarWinds, oferecem monitoramento aprimorado.

9. Conclusão e recomendações

9.1 Resumo dos Pontos Chave

SQL Server O envio de logs proporciona uma recuperação de desastres confiável e econômica por meio de operações automatizadas de backup e restauração de logs de transações. A tecnologia funciona com a Standard Edition, requer infraestrutura mínima e suporta múltiplos servidores secundários.

O envio de logs se destaca para objetivos de recuperação moderados, onde o failover manual é aceitável. As principais limitações incluem a necessidade de failover manual, a latência de sincronização e o escopo da configuração em nível de banco de dados.

A tecnologia integra-se bem com as estratégias de backup existentes, suporta relatórios somente leitura por meio do modo de espera e oferece proteção contra restauração atrasada em caso de alterações acidentais.

9.2 Fazendo a escolha certa para o seu ambiente

Antes de implementar o envio de logs, avalie-o em relação às suas necessidades específicas. Considere os objetivos de ponto de recuperação (RPO), os objetivos de tempo de recuperação (RTO), as restrições orçamentárias e a tolerância à complexidade operacional.

Organizações usando SQL Server A versão Standard Edition, com requisitos moderados de recuperação, deve considerar seriamente o envio de logs. Empresas com RTOs rigorosos, inferiores a 15 minutos, devem avaliar os Grupos de Disponibilidade Always On.

Considere abordagens híbridas que combinem o transporte logístico com outras tecnologias para otimizar custos e, ao mesmo tempo, atender a diversos requisitos.

9.3 Próximos passos e recursos adicionais

Comece com implementações piloto em pequena escala para ganhar experiência. Desenvolva documentação completa, incluindo detalhes de configuração, procedimentos de failover e guias de solução de problemas.

Agende testes de failover regulares para validar os procedimentos e manter a prontidão do administrador. Mantenha-se atualizado com SQL Server Atualizações e melhorias.

Referências

Documento oficial da Microsoft: Sobre o envio de toras (SQL Server)
Documento oficial da Microsoft: Configurar o envio de logs (SQL Server)

Sobre o autor

Yuan Sheng é um administrador de banco de dados sênior (DBA) com mais de 10 anos de experiência em SQL Server ambientes e gerenciamento de bancos de dados corporativos. Ele solucionou com sucesso centenas de cenários de recuperação de bancos de dados em organizações de serviços financeiros, saúde e manufatura.

Yuan é especialista em SQL Server recuperação de banco de dados, soluções de alta disponibilidade e otimização de desempenho. Sua vasta experiência prática inclui gerenciamento de bancos de dados multiterabytes, implementação de Grupos de Disponibilidade Always On e desenvolvimento de estratégias automatizadas de backup e recuperação para sistemas empresariais de missão crítica.

Por meio de sua experiência técnica e abordagem prática, Yuan se concentra na criação de guias abrangentes que ajudam administradores de banco de dados e profissionais de TI a resolver problemas complexos. SQL Server desafios de forma eficiente. Ele se mantém atualizado com as últimas SQL Server lançamentos e as tecnologias de banco de dados em evolução da Microsoft, testando regularmente cenários de recuperação para garantir que suas recomendações reflitam as melhores práticas do mundo real.

Tem dúvidas sobre SQL Server recuperação ou precisa de orientação adicional para solução de problemas de banco de dados? Yuan dá as boas-vindas comentários e sugestões para melhorar esses recursos técnicos.