Atualmente, há muitas tecnologias de recuperação de desastres (DR) na indústria, incluindo espelhamento de bancos de dados, clustering e soluções de replicação. No entanto, o envio de logs (log shipping) é um método mais simples, fácil de configurar e manter. Este artigo discutirá as etapas para recuperação de desastres do SQL Server utilizando o envio de logs.
Solução de Recuperação de Desastres com Envio de Logs
O envio de logs mantém principalmente cópias de segurança em um servidor secundário e assume o controle do servidor principal conforme necessário para melhorar a disponibilidade geral do banco de dados. Em outras palavras, quando o banco de dados principal fica indisponível devido a um desastre, você pode ativar manualmente o banco de dados secundário para continuar prestando serviços.
Para configurar o log shipping para um banco de dados, o SQL Server cria os seguintes três trabalhos do agente para automatizar as operações de backup, cópia e restauração:
O primeiro trabalho é executado na instância primária. Ele faz o backup do log de transações no banco de dados primário.
O segundo trabalho é executado no servidor secundário. Ele copia os backups de log do servidor primário para o servidor secundário.
O terceiro trabalho também é executado no servidor secundário. Ele restaura os backups de log e atualiza as entradas de log no banco de dados secundário.
Considerações antes de configurar o envio de logs no SQL Server
Embora configurar o envio de logs não seja difícil, várias considerações devem ser levadas em conta antes da implementação:
Proteção no nível do banco de dados: Se você precisar proteger apenas um pequeno número de bancos de dados em caso de desastre, este nível é suficiente. No entanto, se desejar preservar múltiplos bancos de dados no nível da instância do SQL Server, uma solução independente de log shipping é insuficiente.
Falha manual no servidor secundário: O envio de logs por si só não pode fazer a falha automática do servidor primário para o servidor secundário. Você deve ativar manualmente o banco de dados secundário.
Configuração manual de login SQL: Os logins SQL não são transferidos automaticamente do servidor principal para o servidor secundário. Você precisa transferir as credenciais de login da instância do servidor principal para a instância do servidor secundário para sincronização de login. Além disso, frequentemente é necessário criar manualmente vários planos de manutenção, servidores vinculados, e pacotes SSIS (SQL Server Integration Services) no servidor secundário.
Risco de perda de dados: Normalmente, quando o banco de dados principal fica indisponível, apenas o último backup do log de transações pode ser restaurado. Isso significa que quaisquer transações ocorridas após o último backup do log ter sido enviado ao servidor secundário serão perdidas. Por exemplo, se o servidor principal falhar às 9:00 da manhã e o último backup copiado para a instância B do servidor secundário foi às 8:45 da manhã, então todos os dados das 8:45 da manhã até as 9:00 da manhã serão perdidos.
Log shipping reverso: Isso é útil ao alternar funções de servidor sem realizar um backup completo do banco de dados. Por exemplo, se você tiver um backup grande e precisar transferir dados do servidor secundário para um servidor principal remoto, copiar o backup inteiro pode levar muito tempo.
Como configurar e utilizar o envio de logs?
Normalmente, o processo de configuração do envio de logs pode ser dividido em duas etapas distintas:
Passo 1 – Inicializar o Banco de Dados no Servidor Secundário
Suponha que temos duas bases de dados na instância do servidor principal e precisamos enviar logs para TestDB1 para um servidor secundário que inicialmente não tem nenhuma base de dados. É importante observar que, para configurar o envio de logs, a base de dados deve estar no modo de recuperação COMPLETO ou BULK-LOGGED. Se a base de dados estiver no modo de recuperação SIMPLES, o envio de logs falhará porque os backups de log de transação não poderão ser utilizados.
1. Primeiro, precisamos executar um backup completo do banco de dados e um backup do log de transações. Você pode executar as seguintes consultas T-SQL para criar backups "completo" e "do log de transações":
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. Em seguida, restaure o backup no servidor secundário.
3. Na interface Restore Database, selecione Device como fonte de dados e clique no ícone correspondente.
4. Na caixa de diálogo Select backup devices, clique em Add.
5. Selecione o arquivo de backup para restaurar e clique em OK.
6. Execute a restauração para o backup do TestDB1.
7. Clique em Select a page e vá para Files para modificar os locais dos arquivos de banco de dados físicos, se necessário.
8. Em seguida, clique em Options no lado esquerdo. Na página Options, selecione RESTORE WITH STANDBY na lista suspensa Recovery state. Observe que ao selecionar RESTORE WITH STANDBY garante-se que o banco de dados permaneça em um estado somente leitura. Se você escolher RESTORE WITH NORECOVERY, o banco de dados ficará inacessível.
9. Após selecionar o estado de recuperação apropriado, clique em OK para garantir uma restauração bem-sucedida. Isso restaurará o TestDB1 no modo Standby (somente leitura) na instância do servidor secundário.
Neste ponto, o banco de dados foi inicializado com sucesso no servidor secundário.
Passo 2 – Ativar o Banco de Dados Primário
1. Clique com o botão direito em TestDB1 na instância do servidor primário e clique em Properties.
2. Selecione Enable this as the primary database in the log shipping configuration.
Por padrão, o log de transação é copiado a cada 15 minutos. No entanto, às vezes o log de transação pode crescer demais para ser copiado e restaurado dentro do tempo predefinido. Para resolver isso, você precisa agendar cópias adicionais do log. Clique em Configurações de Backup, especifique o local do arquivo de backup na interface Configurações de Backup do Log de Transação, depois clique em Agendamento e altere a frequência do backup para executar a cada 1-2 minutos.
3. Clique em Add para configurar o banco de dados secundário. O sistema irá solicitá-lo a conectar à instância do servidor secundário.
4. Conforme configurado na Etapa 1, na interface Secondary Database Settings, selecione No, the secondary database is initialized.
5. Proceda à cópia dos arquivos especificando o local da pasta de backup do servidor secundário, definindo a frequência do backup e clicando em OK.
6. Na interface Restore Transaction Log, defina o estado do banco de dados como Standby mode e marque a opção Disconnect users in the database when restoring backups. Após definir o intervalo de backup, clique em OK.
7. Para adicionar a instância do servidor secundário e o banco de dados, clique em OK para criar trabalhos do SQL Server Agent.
Na instância do SQL Server Agent no servidor primário, você encontrará o trabalho de backup do log de transações.
Na instância do SQL Server Agent no servidor secundário, você encontrará dois trabalhos recém-criados: um que copia os backups do log de transações do banco de dados principal e outro que restaura os backups do log de transações no banco de dados secundário.
8. Neste momento, a solução de recuperação de desastres com envio de logs está totalmente configurada. Se o banco de dados principal falhar, você poderá colocar imediatamente o banco de dados secundário em funcionamento. Você também poderá executar a seguinte consulta para confirmar que o banco de dados secundário saiu do modo de espera:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. Ao atualizar o banco de dados, você verá que o TestDB1 no servidor secundário está agora online.
Estratégia de Proteção de Dados Mais Abrangente para SQL Server
Ao implementar soluções de recuperação de desastres, como envio de logs, as empresas frequentemente exigem uma estratégia de proteção de dados mais abrangente e eficiente. Vinchin Backup & Recovery oferece uma solução automatizada de backup e recuperação especificamente projetada para máquinas virtuais e bancos de dados como o SQL Server, suportando backups completos, incrementais e diferenciais. Com tecnologias integradas de deduplicação e compressão de dados, reduz significativamente o consumo de armazenamento e o tempo de backup.
Além disso, a solução de backup da Vinchin elimina a necessidade de intervenções manuais complexas, permitindo a proteção automática de bancos de dados e oferecendo suporte à migração entre plataformas e ao armazenamento em nuvem. Em caso de falha no SQL Server, a Vinchin ajuda os administradores a restaurar rapidamente os bancos de dados, evitando perda de dados e tempo de inatividade prolongado, proporcionando assim uma garantia mais abrangente de recuperação de desastres para as empresas.
Para criar trabalhos de backup do banco de dados do SQL Server, acesse a página Physical Backup > Database Backup > Backup:
1. Selecione os bancos de dados que precisam ser copiados.
2. Selecione um nó de backup no qual você deseja que os dados de backup sejam processados e armazenados.
3. Configure estratégias de backup de acordo com suas necessidades.
4. Revise e confirme as configurações.
Clique no botão abaixo para experimentar a versão gratuita de 60 dias do Vinchin e conhecer uma solução eficiente e confiável para backup e recuperação de dados!
Perguntas Frequentes sobre Recuperação de Desastres do SQL Server
1. Qual é a diferença entre Alta Disponibilidade (HA) e Recuperação de Desastres (DR)?
A HA garante tempo de inatividade mínimo utilizando clustering de failover, grupos de disponibilidade Always On ou espelhamento de banco de dados, enquanto a DR se concentra na restauração do serviço após falhas catastróficas, muitas vezes envolvendo backups fora do local ou centros de dados secundários.
2. O que é uma instância de cluster de failover do SQL Server (FCI) e como ela ajuda na recuperação de desastres (DR)?
Um FCI é uma solução de alta disponibilidade que utiliza o Windows Server Failover Clustering (WSFC) para fornecer failover automático no nível da instância do SQL Server. Requer armazenamento compartilhado (SAN, Storage Spaces Direct ou soluções baseadas em nuvem). É ideal para alta disponibilidade local, mas não é por si só uma solução de recuperação de desastres, pois não protege contra falhas generalizadas no site.
Conclusão
O log shipping é uma solução econômica, eficiente e simples para recuperação de desastres no SQL Server. É uma escolha ideal para recuperação de desastres no nível do banco de dados. No entanto, para recuperação de desastres no nível de instância, outras técnicas de recuperação de desastres, como espelhamento de banco de dados ou clustering de failover, devem ser consideradas. Além disso, o log shipping pode levar à perda de dados. Se você precisar recuperar dados excluídos ou inacessíveis de um banco de dados SQL danificado, considere utilizar uma ferramenta profissional de recuperação SQL.
