Júlio Battisti Livros e Cursosa sua sala de aula na internet

Vamos ver alguns exemplos teóricos de estratégias de backup/restore, onde consideramos os diferentes tipos de backup: completo, diferencial e do Log de transações.

Exemplo 01: O backup completo diário do Banco de Dados: Nesta estratégia fazemos um backup completo do Banco de Dados diariamente. Vamos considerar a programação de backup descrita na Tabela 5.1.

Tabela 5.1 Backup completo do Banco de Dados.

Hipótese: Na quinta-feira, às 9 horas da manhã o Banco de Dados é corrompido.

Recuperação do Banco de Dados: Nesta situação somente poderemos restaurar os dados à situação em que estes estavam na quarta-feira, às 23 horas, que foi o horário do último backup completo. Todas as alterações realizadas, entre às 23 horas de quarta-feira e o momento em que o Banco de Dados foi corrompido, serão perdidas.

Procedimento de Restore: Restaurar o último backup completo disponível, que neste caso é o backup da quarta-feira às 23h.

Exemplo 02: O backup completo combinado com o backup do Log de transações: Nesta estratégia fazemos um backup completo do Banco de Dados em períodos mais espaçados, digamos uma ou duas vezes por semana. Entre um backup completo e outro, são feitos backups do Log de transações. Vamos considerar a programação de backup descrita na Tabela 5.2.

Tabela 5.2 Backup completo do Banco de Dados mais backup do Log de transações.

Hipótese: Na quinta-feira, às 9h30 o Banco de Dados é corrompido.

Recuperação do Banco de Dados: Neste situação poderemos restaurar os dados à situação em que estes estavam na quinta-feira, às 9h, que foi o horário do último backup do Log de transações. Todas as alterações realizadas entre às 9h e 9h30 da quinta-feira, e o momento em que o Banco de Dados foi corrompido, serão perdidas. Na verdade existem algumas técnicas avançadas que permitem recuperar os dados até próximo da hora em que o banco foi corrompido. Aprenderemos estas técnicas mais adiante, neste capítulo.

Procedimento de Restore: Restaurar o backup completo do sábado às 23h e todos os backups do Log de transações, na seqüência correta, até o backup do Log de transações da quinta-feira às 9h.

Observe que nesta situação teríamos que restaurar 18 backups:

• um completo do sábado +
• quatro backups do Log do domingo (9h, 12h, 15h e 18h) +
• quatro backups do Log da segunda-feira (9h, 12h, 15h e 18h) +
• quatro backups do Log da terça-feira (9h, 12h, 15h e 18h) +
• quatro backups do Log da quarta-feira (9h, 12h, 15h e 18h) +
• um backup do Log da segunda-feira (9h)

Total = 18 backups a serem restaurados.

Conforme podemos conferir pelo exemplo, esta estratégia é mais complexa na hora de restaurar o Banco de Dados, porém temos uma perda de alterações bem menor do que no caso da utilização de somente backup completo. Em caso de perdas, estas são em menor número do que no caso do backup somente do Banco de Dados.

Exemplo 03: O backup completo combinado com o backup diferencial e com o backup do Log de transações: Nesta estratégia fazemos um backup completo do Banco de Dados em períodos mais espaçados, uma ou duas vezes por semana. Entre um backup completo e outro são feitos backups do Log de transações e também um backup diferencial na quarta-feira. Vamos considerar a programação de backup descrita na Tabela 5.3.

Tabela 5.3 Utilizando backups completos, diferenciais e do log de transações.

Observe que somente fizemos um backup completo no início do ciclo, depois vamos fazendo nas quartas e sábados backups diferenciais, e entre os backups diferenciais, quatro backups diários do log de transações.

Hipótese: Na quinta-feira, às 9h30 o Banco de Dados é corrompido.

Recuperação do Banco de Dados: Nesta situação poderemos restaurar os dados à situação em que estes estavam na quinta-feira, às 9h, que foi o horário do último backup do Log de transações. Todas as alterações realizadas entre as 9h e 9h30 da quinta-feira, e o momento em que o Banco de Dados foi corrompido, serão perdidas. Na verdade existem algumas técnicas avançadas que permitem recuperar os dados até próximo da hora em que o banco foi corrompido. Aprenderemos estas técnicas mais adiante, neste capítulo.

Procedimento de Restore: Restaurar o backup completo do sábado às 23h, depois restaurar o backup diferencial da quarta feira às 23h e o backup do Log de transações da quinta-feira às 9h.

Observe que nesta situação teríamos que restaurar três backups:

• um completo do sábado +
• um diferencial na quarta-feira (23h) +
• um backup do Log da quinta-feira (9h)

Total = 3 backups a serem restaurados.

Fica bastante claro que a utilização do backup diferencial facilita muito o processo de restauração do Banco de Dados, que conforme salientado pelo exemplo, diminui o número de backups que devam ser restaurados, em relação a uma estratégia que usa somente backups completos e do log de transações.

Com o SQL Server 2005 podemos efetuar o backup com o Banco de Dados on-line, isto é, sendo utilizado por uma ou mais aplicações. Porém não poderemos criar ou excluir arquivos de dados – primários (.mdf) ou secundários (.ndf) enquanto o backup estiver sendo realizado.

Agora que conhecemos a parte teórica a respeito do Log de transações e dos tipos de backup possíveis no SQL Server 2005, podemos aprender a fazer o backup dos dados e a restaurar os dados, quando necessário. Mas antes, um pouco sobre backup devices.

Estou utilizando um computador que não possui drive de fita instalado, por isso, nos exemplos deste capítulo, farei o backup em uma pasta do disco rígido. Na prática um servidor com o SQL Server 2005, usando em um ambiente de produção na empresa, certamente terá um drive de fita para efetuar o backup, sendo esta a estratégia recomendada. Não é recomendado a realização de backups no disco rígido, pois se o disco rígido for danificado o backup será perdido. Fazer o backup no disco rígido é análogo a situação em que as fitas de backup são guardadas na mesma sala do servidor. O princípio básico é que devemos deixar, fisicamente separados, os dados e as mídias de backup. Se possível em prédios separados com as fitas de backup em uma sala-cofre à prova de fogo.

Know-how em: O Conceito Backup Devices e Criação de Backup Devices

Pré-Requisitos:

• Noções sobre o Log de transações.
• Noções sobre estratégias de backup.
• Fundamentos apresentados na Parte I do Livro.
• Saber utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL.

Metodologia:

• Apresentação teórica sobre Backup Devices.

Técnica:

• Utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL para a criação de Backup Devices.

Ao efetuarmos um backup devemos especificar um “backup device”, onde o backup será efetuado. Conforme veremos a seguir, um backup device é um conceito que associa um dispositivo físico de backup, como um drive de fita ou um volume em um disco rígido, com um backup device. Falando de uma maneira bastante simples, o backup device é um “nome” que associamos com um dispositivo físico de backup, como por exemplo um drive de fita. Depois na hora de fazer o backup, utilizamos o nome (backup device) ao invés de utilizar o caminho físico para o dispositivo. O objetivo básico do Backup Device é facilitar a identificação dos dispositivos físicos de backup.