Plano de Backup para SQL Server

Ter um bom plano de backup é crucial para os nossos negócios.  Falando de uma maneira negativa, é ter ou, caso contrário, o arrependimento virá mais cedo ou mais tarde. Os "desastres" que mais ocorrem são devido à falhas de hardware, mas este é apenas um dos riscos aos quais nossos dados estão expostos. Erros humanos na administração do servidor, operação incorreta do sistema, ataques cibernéticos, vírus,... Em qualquer um destes casos, todo investimento feito em um plano de backup e em sua correta execução será recompensado.

Para bancos de dados SQL Server, há muitas estratégias de backup que podem ser adotadas. O plano deve ser composto pela parte do backup e pela parte da restauração. A parte do backup define a frequencia, a natureza e velocidade do hardware aonde os arquivos serão gravados, como os backup serão testados, quando e como as mídias de backup serão armazenadas, incluindo considerações sobre segurança. A parte da restauração define quem é responsável pela execução, como deve ser executada para atingir o objetivo de minimizar a perda de dados.

Vale ressaltar que uma estratégia de backup não existe até que ela seja testada. A restauração com sucesso deve ser conseguida para cada combinação que estiver disponível na estratégia. Em nosso caso precisamos restaurar o backup total e, em seguida, um dos parciais que, não necessariamente, será o mais recente.

O banco de dados que está recebendo esta estratégia de backup é o coração da Crucial. Integramos nele diversos sistemas como contábil, financeiro, comercial, recursos humanos, entre outros. Este banco deve estar disponível para a empresa funcionar. Levando também em consideração que o site de comércio eletrônico e seu banco de dados se encontram em um data center terceirizado, o ideal é que este banco de dados interno esteja disponível para ser modificado 24 horas por dia. Só assim podemos cadastrar os novos pedidos que chegam pelo site assim que eles forem feitos, em horário comercial ou não.

Partiremos do princípio de que o máximo para perda de dados do nosso banco interno será uma hora de transações. Assim, mesmo no horário de pico, seríamos capazes de refazer o trabalho que foi perdido e prosseguir executando os processos. Dessa forma, podemos trabalhar com backups completos e diferenciais, no modelo simples de restauração.

Essa foi uma decisão difícil, já que nunca é fácil recuperar transações que foram perdidas. Decidimos assumir o risco por termos os dados fundamentais em outras fontes (site, notas fiscais eletrônicas, emails, etc.) e, principalmente, por confiarmos na redundância de discos do nosso servidor, onde implementamos RAID 10. Esse não seria o caso de uma empresa que lida com transações que não podem ser facilmente recuperadas (como uma instituição financeira), cuja restauração deveria acontecer até a última transação realizada e o modelo de backup seria o "cheio".

Precisamos que os backups sejam executados automaticamente, e, em caso de falha, sermos avisados. Os requisitos da segurança de acesso aos dados não são muitos no momento, já que, por enquanto, toda tecnologia está na mão dos sócios da empresa. Por outro lado, não seria nem um pouco agradável perceber que uma mídia contendo backup do banco de dados foi furtada (bem mais fácil que levar o servidor todo). Assim, os backups serão gravados em um disco externo e este ficará preso ao rack com corrente tipo Kensington. Esta precaução da corrente é maior devido ao não controle de acesso físico aos servidores, que deveremos implantar em uma etapa posterior. Do disco externo, os arquivos serão copiados para armazenamento remoto seguro. A idéia é que tenhamos certa garantia que, mesmo em um caso mais grave como um incêndio, teremos como reiniciar o sistema em outra localização.

Para o plano, levaremos o seguinte em consideração:

  1. O backup completo será executado diariamente às 5 horas, um horário fora do pico;
  2. Os backups diferenciais serão executados de hora em hora durante o horário comercial (7 às 19, de segunda a sexta) e de 3 em 3 horas nos horários não comerciais, onde ocorrem menos transações.
  3. O backup cheio necessita, por enquanto, de apenas 1GB de espaço livre em disco (use sp_spaceused para descobrir). Se nada de muito significativo mudar nos próximos meses, 4GB será suficiente para todas as nossas transações de 2010 (tomara que não!).
  4. O tempo de retenção deve ser multiplicado pela quantidade de backups cheios, assim se quisermos reter os arquivos das últimas 5 semanas (para guardar pelo menos uma cópia sem alteração dos livros fiscais do mês anterior, até que os novos sejam gerados sem problemas), precisaremos de, atualmente  5 x 7 x 1GB = 35GB e, até o final de 2010, um estimado de 4 vezes isso.

Uma vez que tenhamos o que deve ser feito planejado, a automação no SQL Server 2008 é relativamente simples com a ajuda do Maintenance Plan Wizard, dentro do Microsoft SQL Server Management Studio. Ele permite a criação de todo script de backup de maneira visual e realiza o agendamento automático dos pacotes no SQL Server Agent. Uma boa idéia é criar o plano manualmente e depois de criado fazer o ajuste fino. No exemplo abaixo, os nomes foram modificados de subplan1, subplan2 e assim por diante para fazerem mais sentido e ficar mais fácil de acompanhar os agendamentos e suas execuções.

Outra boa idéia é o uso do botão "Exibir T-SQL" da tela de edição da tarefa. Assim podemos copiar e colar o código em uma nova consulta para verificar se tudo correu bem. Foi dessa maneira que descobri antecipadamente que a opção "COMPRESSION" do comando BACKUP não funciona com sistemas 64-bit.

Sempre que a edição é salva, os jobs são automaticamente atualizados no SQL Server Agent, tornando nossa vida MUITO mais fácil que em outras épocas:

Após finalizado o trabalho, consideramos que o sistema de agendamento poderia liberar uma programação mais flexível de horários para execução. Foi necessária a criação de 4 subplanos, cada um com uma faixa de horário de agendamento para cobrir nossa necessidade de  backups diferenciais com maior frequencia em horário comercial e menor frequencia fora do horário comercial.

blog comments powered by Disqus