Início > Administração de Banco de Dados, Backup, Carreiras em TI, Dicas, Disaster Recovery, SQLManics > Dicas para DBA Iniciante – Estratégia de Backup

Dicas para DBA Iniciante – Estratégia de Backup

E ai galerinha, tudo bem com vocês?

Nesta semana continuaremos com a nossa séria de Dicas para um DBA Iniciante falando sobre o processo de backup.

Após a criação do inventário, é extremamente importante projetar e implementar uma estratégia de backup eficiente em seu ambiente, pois desta forma assegura-se que todas as informações da empresa estão copiadas e poderão ser restauradas à qualquer momento no caso de um desastre.

Acredito ser importante que todos os seus ambientes sejam levados em consideração em sua estratégia de backup, ou seja, considere além do ambiente de PRODUÇÃO o ambiente de DESENVOLVIMENTO.

Pode parecer desnecessária a realização de backups em um ambiente de desenvolvimento, já que o mesmo não é critico e não trará perdas para a empresa caso ocorra um desastre, certo?

ERRADO!!!!

Vamos pensar da seguinte forma, o ambiente de DESENVOLVIMENTO é o ambiente de PRODUÇÃO dos desenvolvedores e se o mesmo for perdido, todos os projetos em desenvolvimento também serão perdidos.

Colocando isso de uma forma mais interessante, imagine um projeto em grande escala ocorrendo em sua empresa e que consultores foram contratados por hora para este desenvolvimento.

O desenvolvimento do projeto já está em seu 2º mês, quase R$ 200.000,00 foram investidos em mão de obra e de repente ocorre um desastre e todo o servidor de banco de dados é perdido.

Como não existe backup para este ambiente, a empresa acaba de ter um enorme prejuízo, pois o projeto foi completamente perdido e terá de iniciar novamente do zero.

Tenho certeza de que haveria uma cópia dos códigos-fonte em algum lugar, mas para evitar qualquer perda de informação, TODOS os ambientes devem ser considerados em sua estratégia de backup..

Para iniciar este trabalho é necessário definir o significado de duas métricas que são fundamentais para uma estratégia de backup.

São elas:

Recovery Time Objective (RTO)

Recovery Point Objective (RPO)

Define quanto tempo será necessário para a restauração de um ambiente através da utilização dos backups. Define a quantidade de informação que pode ser perdida no caso de uma situação total de desastre

Para que seja possível projetar uma estratégia de backup eficiente, e que cumpra os valores definidos como RTO e RPO, o SQL Server possui os seguintes tipos de backup:

Tipo de Backup
Full
Diferencial
Transacion Log
File/Filegroup
Parcial

Através do backup Full é possível criar uma cópia completa de todos os arquivos de dados e arquivos de log utilizados no banco de dados.

O backup diferencial copiará apenas as páginas de dados que foram alteradas/criadas a partir do último backup Full válido.

Com o backup de File/Filegroups é possível realizar a cópia de arquivos de dados específicos ou então de um ou mais Filegroups.

O backup de transaction logs permite que sejam copiadas apenas as transações mais recentes executadas em um determinado banco de dados, ou seja, a parte ativa do arquivo de transaction log.

É importante ressaltar que os backups de transaction logs são apenas possívels caso a propriedade Recovery Model do banco de dado não esteja definido como SIMPLE.

O backup Parcial permite que sejam realizadas cópias de determinados Filegroups através de alguma propriedade específica, por exemplo, copiar todos os filegroups que estão configurados como ReadOnly ou então de todos os Filegroups que são Read/Write ou apenas o Filegroup PRIMARY.

Para projetarmos uma pequena estratéfia de backup, imaginem um cenário em que um determinado ambiente possui as seguintes definições de RTO e RPO.

RTO

RPO

8 horas 30 minutos

Inicialmente necessitaríamos da execução diária de um backup full em um horário de baixa utilização do ambiente de banco de dados. Definimos então que o backup full será realizado todos os dias às 00:00.

Com a execução de um backup Full todas as noites estamos cumprindo o RTO de 8 horas, porém temos um RPO de 24 horas que está muito distante dos 30 minutos solicitados pelo nosso cliente.

Podemos diminuir essa perda de informação com um backup diferencial executado a cada 6 horas garantindo assim um RPO de 6 horas.

Porém ainda estamos extremamente distantes do RPO de 30 minutos solicitados pelo cliente, correto?

Para ganharmos tempo, necessitamos de um backup rápido e que ocupe pouco espaço em disco, já que o mesmo será executado a cada 30 minutos.

Com certeza a melhor solução seria a implementação de um backup de log a cada 30 minutos, sendo que desta maneira cumprimos o RPO de 30 minutos solicitado pelo nosso cliente e mantemos o RTO dentro das 8 horas.

De forma resumida temos a seguinte estratégia de backup:

Tipo de Backup

Horário de execução

Backup Full Todos os dias às 00h00min
Backup Diferencial Todos os dias a cada 06 horas
Backup de Transaction Log Todos os dias a cada 30 minutos

Para a implementação desta estratégia de backup utilizaremos uma funcionalidade do SQL Server chamada Plano de Manutenção, que já existe desde a versão SQL Server 2000:

A configuração do Plano de Manutenção será definida da seguinte forma:

1) Clicar com o botão direito em Maintenance Plan Wizard;

Backup_1

2) Clicar no botão Next;

Backup_2

3) Definir o nome do plano de manutenção, uma descrição da sua funcionalidade, selecionar um agendamento diferente para cada tarefa e clicar no botão Next;

Backup_3

4) Selecionar as opções Back Up Database (Full), Back Up Database (Differential), Back Up Database (Transaction Log) e clicar no botão Next;

Backup_4

5) Clicar no botão Next;

Backup_5

6) Selecionar a opção All user databases e clicar no botão OK;

Backup_6

7) Selecionar a opção Create a Sub-directory for each database, direcionar os backups para a pasta desejada, definir o agendamento para executar o backup diariamente às 00:00 e clicar no botão Next;

Backup_7

8) Selecionar a opção All user databases e clicar no botão OK;

Backup_8

9) Selecionar a opção Create a Sub-directory for each database, direcionar os backups para a pasta desejada, definir o agendamento para executar o backup a cada 06 horas e clicar no botão Next;

Backup_9

10) Selecionar a opção All user databases e clicar no botão OK;

Backup_10

11) Selecionar a opção Create a Sub-directory for each database, direcionar os backups para a pasta desejada, definir o agendamento para executar o backup a cada 30 minutos e clicar no botão Next;

Backup_11

12) Clicar no botão Next;

Backup_11_1

13) Clicar no botão Finish.

Backup_12

Com isso temos uma estratégia de backup eficiente e completamente funcional implantada em seu ambiente.

É importante ressaltar de que não existe uma única forma correta de projetar uma estratégia de backup eficiente, pois existem mudanças nas métricas de RTO e RPO em cada cenários.

Espero que tenham gostado de mais essa dica e inscrevam-se no blog para não perderem o próximo post no qual conversaremos sobre a criação de um baseline do seu ambiente.

Grande abraço.

Anúncios
  1. Samuel
    20/08/2013 às 10:34

    Grande Vitor,

    Excelente conteúdo. Esses diretrizes ajudaram a iluminar o caminho para novos profissionais. Uma pergunta: o curso 10776 você esta ministrando? Um grande abraço.

    • 20/08/2013 às 11:12

      Fala grande Samuel, tudo bem contigo?
      Obrigado por ficar sempre ligado no blog.
      Estou ministrando o 10776 sim meu velho.
      Grande abraço.

  2. 20/08/2013 às 10:54

    Parabéns Vitão, mais uma vez Sensacional. como o colega abaixo falou, você sempre nos abrindo a mente e ajudando no crescimento profissional.

    • 20/08/2013 às 11:13

      Fala Diogão.
      Cara, a intenção é sempre repassar o que aprendi em meu dia a dia.
      Obrigado pelo elogio e continua acompanhando a série.
      Grande abraço.

  3. Frederico Madeira
    20/08/2013 às 11:12

    Parabéns mesmo Vitão a cada terça feira agregando mais conhecimentos e novas estratégias de backup muito bom mesmo !!!!

  4. 21/08/2013 às 9:56

    Faaaala Vitão!!! Parabéns por mais este post sensacional, abraço!

    • 21/08/2013 às 10:59

      E ai Gustavão, beleza?
      Obrigado pelo elogio.
      Como sempre a idéia e disseminar a conteudo, hehehee.
      Grande abraço.

  5. Eric Silva
    22/08/2013 às 15:39

    Parabéns pelo artigo Vitor! Sou novo na área de SQL Server, porém tenho boa experiência com Oracle. Poderia tirar uma dúvida se possível? No Oracle, temos o RMAN que realiza o backup on-line, com isso, caso ocorra um desastre, ele recupera o banco até o momento da falha, caso o backup esteja tudo certinho. Não tem essa opção de estratégia de RPO. No caso do SQL Server, há esta possibilidade também? Pelo o que entendi, vou ter sempre uma margem de perda de dados, pois se calcular o RPO para 2 minutos e ocorrer um desastre, eu perderia 2 minutos de informação. É isso ou me equivoquei? Grande Abraço!

    • 22/08/2013 às 15:44

      Fala grande Eric, tudo bem contigo?
      Realmente com o backup do SQL Server temos sempre uma perda de dados, pois existe o intervalo entre os backups.
      Uma solução equivalente à sua solução atual seria o Database Mirroring do SQL Server.
      Esta funcionalidade garante que não haverá perda de dados, pois é um processo síncrono de commit de transações.
      Espero ter ajudado e se precisar de qualquer nova informação é só me avisar.
      Grande abraço.

      • Eric Silva
        22/08/2013 às 15:56

        Muito Obrigado Vitor! Vou me aprofundar nesse Database Mirroring para implantar aqui na empresa. Num cenário onde não há essa janela de perda de dados, esta é a opção mais viável. Abraços e Parabéns pelo blog!

  6. Anderson Souza
    18/04/2014 às 12:36

    Vitor, gostaria de compartilhar com todos um problema encontrado ontem no processo de restore num servidor sql server 2012 Enterprise 64 bits.
    Ao realizar o processo de restore via SSMS o backup full with norecovery ocorre sem problemas, mas ao realizar o restore do backup diferencial ele envia a mensagem “Unable to create restore plan due to break in the LSN chain”.
    Verifiquei o database_backup_lsn do diferencial e o mesmo bate com o first_lsn do backup full. Realizei todo o processo de restore via T-SQL e foi concluido com sucesso.
    Se alguem passou por esse problema compartilhe como resolveu.

  7. Fabio
    09/07/2015 às 11:07

    Tutorial simples, explicativo e muito util.
    Os iniciantes, ou os que caeem de paraquedas nestas situações agradecem……

    • 09/07/2015 às 17:48

      Grande Fabio, tudo bem?

      Muito obrigado pelo feedback positivo meu amigo e espero que os próximos posts continuem ajudando.

      Qualquer dúvida é só avisar.

      Grande abraço.

  1. 20/08/2013 às 10:46
  2. 20/08/2013 às 10:47

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: