Estratégias de backup e restauração (ou recuperação) para bancos de dados SQL Server

Uma das atribuições mais importantes de um administrador de banco de dados é proteger constantemente a integridade dos bancos de dados e manter uma capacidade de recuperação rápida em caso de falhas. Razões pela extrema importância na definição de uma estratégia de backup e recuperação disponível em caso de emergência.

Uma das principais responsabilidades do administrador de banco de dados é garantir a disponibilidade de um banco de dados sempre que necessário e estar preparado para vários cenários onde a disponibilidade ou o desempenho podem ser afetados. Portanto, quando banco de dados seja corrompido, por qualquer circunstância ou excluído intencional ou acidentalmente senão entrar em um estado inutilizável, o administrador de banco de dados é o principal responsável na restauração em um estado de funcionamento com pouca ou nenhuma perda conforme os acordos de nível de serviço estejam definidos ou as políticas governamentais.

Os administradores de banco de dados precisam estar preparados interagir com cenários de recuperação de desastres. Um metódo de estar praprado consiste em testar as estratégias de backup e restauração do SQL Server em intervalos regulares. Visando garantir uma recuperação perfeita dos dados. Essa perfeita recuperação significa rápida recuperação de sistemas com perda mínima ou nula dos dados. Embora proteger os dados das várias falhas de dados seja também outra atribuição do administrador de banco de dados.

Ao desenvolver o plano para backup e restauração é necessário considerar o planejamento de recuperação de desastre condizentes com requisitos específicos dos negócios e do ambiente. Por exemplo, como aplicar uma recuperação em caso de várias falhas de dados em três locais principais no ambiente? Quanto tempo será necessaário para recuperar os dados e por quanto tempo haverá indisponibidade dos sistemas? Qual a quantidade tolerável para perda de dados em sua organização?

Outra consideração importante no qual os administradores de banco de dados precisam se estar atentos está na natureza do armazenamento de dados. Afetando diretamente a utilidade, bem como a eficiência do processo de backup e restauração.

Existem disponíveis inúmeras técnicas avançadas como Cluster, AlwaysOn, LogShipping e Espelhamento colaborando na garantia da maior disponibilidade mas a recuperação de desastres está diretamente relacionada processos de backup e restauração bem definidos e validados.

Elementos a considerar na definição de uma boa estratégia para backup incliuem:

1. regularidade em que os dados são alterados

2. processamento de transações online

3. frequência das mudanças de esquema

4. frequência de mudança na configuração do banco de dados

5. padrões de carregamento de dados

6. natureza dos dados em si

Este artigo tem a intenção de apresentar os pontos mencionados previamente e também examinar os requisitos, segundo atributos como o tamanho dos bancos de dados, detalhes internos e regularidade das alterações. A seguir uma análise das considerações importantes para a projeção de uma estratégia sólida de backup.

Os arquivos de backups oriundos do SQL Server incluem todos os objetos do banco de dados como tabelas, gatilhos, índices e procedimentos armazenados. São arquivos de backup usualmente utilizados na migração de bancos de dados entre diferentes instâncias do SQL Server em execução localmente ou em nuvem. Podendo ser utilizados numa ingestão de dados, recuperação de desastres e assim por diante também. Os backups nativos simplificam o processo de importação de dados e esquemas de instâncias locais do SQL Server, sendo fáceis para os administradores do SQL Server compreenderem e utilizarem. Algumas aplicações para o uso dos backups são:

• migração entre bancos de dados

• recuperar de exclusões acidentais nas tabelas

• Lidar com instâncias únicas ou múltiplas de banco de dados

• atualização de ambientes de desenvolvimento

• movimentação do banco de dados para uma unidade diferente

• exportação e importação de dados

• descarregar as necessidades de relatórios usando o Log Shipping de alta disponibilidade

• criar cópias de banco de dados para laboratórios, treinamentos e demonstrações

• criação de arquivos de backup para dentro e fora do armazenamento em nuvem para fornecer uma camada adicional de proteção para recuperação de desastres

O script transact-SQL a seguir pode ser utilizado na busca por tendência de crescimento do banco de dados utilizando a tabela backup_history. As informações de backup ficam sempre armazenadas no banco de dados msdb. Em alguns casos pode-se obter dados limitados com base nas tarefas de manutenção ou tarefas de limpeza criadas para limpar os dados. Os detalhes do tamanho do backup podem ser localizados na tabela dbo.backupset que contém uma linha para cada operação de backup bem-sucedida.

A consulta acima pode ser alterada para conseguir uma visão geral dos tamanhos de backup em uma base diária ou semanal, dependendo da granularidade desejada.

O próximo script T-SQL utiliza a tabela msdb.dbo.backup_history para analisar o crescimento do banco de dados em um determinado período. As métricas são úteis para planejamento e previsão de capacidade com referência a backup

Informações complementares

Um dos principais motivadores para proteção dos dados é a realização de regulares backups.

Para estabelecer a estratégia adequada de backup e recuperação, deve-se entender:

1. O tipo e a natureza dos dados

2. A regularidade de backup

3. A natureza e velocidade do hardware subjacente

4. O destino do arquivo de backup: unidade de fita, disco local, compartilhamento de rede, compartilhamento remoto ou serviços de nuvem

5. A largura de banda da rede

Efetuar frequentes laboratórios de backup e restauração para identificar a maneira mais adequada na restauração dos dados é igualmente importante.

É fato sobre a maioria das organizações poderem assimilar algum tipo de perda de dados, juntamente com a indisponibilidade do banco de dados por alguns minutos ou horas.

Uma estratégia para uma solução de backup sem perda de dados pode requerer um projeto especial e desencadear custos adicionais no grenciamento do recurso necessário para garantir a cópia confiável dos fluxos de dados em vários destinos regularmente.

Outro condição trivial é o Recovery-Time-Objective, ou RTO. Contemplando o tempo total de indisponibilidade do sistema, a fim de balancear o custo do sistema que permanecerá inativo com o custo de restaurar o sistema rapidamente e de manter a infraestrutura e a equipe efetuando essa tarefa imediatamente.

Modelo de Aplicação

O estudo a seguir cacula o tempo necessário para a atividade de backup e restauração para atender os objetivos do RTO (Recovery Time Objective). Presumindo o tamanho do banco de dados “X” ser 32 GB (ou 32 * 1024 = 32768 MB) e considerando a taxa de transferência de backup em 120 MB/minuto, terá como resultado o tempo necessário para fazer o backup do banco de dados “X” será 32768/120=273 minutos (aproximadamente ~ 4 horas e 33 minutos). Numa taxa de transferência e restauração a 100MB/minuto terá como resultado o tempo necessario restaurar o banco de dados “X” sendo 32768/100=327 minutos (ou aproximadamente 5 horas e 27 minutos).

Neste exemplo foi possível identificar o tempo necessario de 4.5 horas para produzir um arquivo de backup e o processo de restauração exigirá aproximadamente 5,5 horas. Concluindo a simulação deste RTO (objetivo de tempo de recuperação) para este banco de dados. É um cálculo indispensável para estabelecer cronogramas de RTO que precisamos ter em mente no planejamento da estratégia para backup e restauração.

A regularidade das atividades de backups define a dimensão dos dados na iminência de um desastre. Quanto maior a quantidade e diversidade de backups, melhor será o processo de restauração capaz de atender o RPO (Recovery Point Objective)

Complementares entre si são o Backup e armazenamento. Quanto maior a frequência do uso do backup do banco de dados, mais armazenamento será necessário, invariavelmente ocasionando algumas restrições orçamentárias quanto a importância da frequência dos backups. Somando ainda o local de armazenamento como outra figura importante para a estratégia. O armazenamento local e externo influenciou na definição para o Recovery-Point-Objective. Ao armazenar todos os dados de backup nas instalações e algum desastre físico ocorrer nele, não apenas os servidores serão inutlizados como também todas as mídias de backup, ocasionando uma perda irreparável dos arquivos. Entretando ao armazenar parte ou todo o backup externamente como discos virtuais, poderá influenciar no tempo ncessário para restauração. Motrivação para a maioria projetos, durante as primeiras semanas armazenar localmente os localmente, posteriormente movidos para fora da organização. Preservar dados fora do local necessita precauções adicionais para os dados usando medidas adequadas de criptografia e segurança. Quando esses arquivos de backup estejam relativamente longe do controle físico acaba reduzidno significativamente os níveis de segurança.

Vários intervalos de testes ajudarão a identificar a maioria dos problemas como identificar uma mídia de fita é frágil, falha na gravação do arquivo de backup ou corrupção durante o envio ou recuperação para um local externo de armazenamento.

Considere que quanto maior o banco de dados então maior o tempo necessario para sua restauração. A maneira possivelmente mais segura de mensurar esse tempo é efetuar algumas avaliações e compartilhar os resultados com a liderança da organização, para os tomadores de decisão conhecerem as consequências, apresentando os diversos resultados dos laboratórios apresentando as variações de backup e restauração.

Conclusão

A utlização de bancos de dados está numa escala astronônica atingindo qualquer ambiente onde seja necessário preservar e utilizar qualquer tipo de informação obtidade das mais diversas maneiras, a própria diversidade de soluções SBBD pode ser considerada verdadeiramente desconhecida e também a incontável variação em suas aplicações.

São elementos que tornaram-se mais importantes do que os próprios sistemas onde são implementados na maioria dos casos, razão que estimula conhecer o maior número possível de condições para sua preservação e restauração, aqui apresentado numa solução baseada nativamente dentro do próprio MS SQL Server.

Como sugestão adicional considere conhecer mais as soluções Iperius, principalmente na facilitação da configuração de estratégias de backup e restauração pois como é possível observar no artigo, requer um grande conhecimento da solução SGBD e quando o administrador possui um ambiente com uma regular diversidade de bancos de dados como Oracle, MySQL, PostgreSQL entre outos acaba gerando relativa dificuldade definir estratégias por script adequadamente para todos eles.