Criação e Restauração de Backup no SQL Server 2005

Uma das tarefas mais comuns para os Administradores de Bancos de Dados é a criação e restauração de Backups. Criando cópia de segurança da base de dados, o DBA está garantindo que as informações cadastradas no banco não serão perdidas em caso de falha no Servidor de Dados (quer seja de hardware ou de software).

No entanto, não basta ao Administrador apenas criar Backups do banco de dados: ao entender os métodos de backup que o SQL Server oferece, o DBA passa a contar com um leque de opções para criar suas políticas de backup de forma a equilibrar eficiência e desempenho do servidor, ao mesmo tempo em que miniminiza a perda de dados.

Neste artigo, apresentaremos os métodos de backup disponíveis no SQL Server 2005 e como realizá-los através do Management Studio e da linguagem T-SQL. Ao longo deste artigo mostraremos exemplos de criação destes métodos. Este artigo é o primeiro de uma série de três, que mostrará como criar e restaurar backups.

Para este artigo, utilizaremos o SQL Server 2005 Express Edition com o banco de dados Adventure Works instalado. Ambos estão disponíveis para download através do site SQL Express: http://msdn.microsoft.com/vstudio/express/sql/. Além disso, é necessária a criação da pasta C:\Backup para armazenar os exemplos mostrados.

Backup Engine do SQL Server 2005

Para entender como o SQL Server 2005 realiza o backup do banco de dados, é necessário entender como funciona a sua Backup Engine. Esta Engine é configurada para realizar todas as tarefas relacionadas a cópia dos dados da forma mais rápida possível, minimizando o impacto na performance do Servidor de Dados.

Quando o backup é iniciado, a Engine escreve as páginas de dados no dispositivo de backup (Disco ou Fita) sem se preocupar com a ordem. Graças a isso, o SQL Server pode abrir vários processos para escrever os dados no seu destino, agilizando o processo.

Mas como este processo geralmente ocorre em ambientes de produção (com usuários trabalhando com os dados), podem ocorrer alterações nos dados durante o processo de criação do backup, e isso poderia gerar inconsistência dos dados.

Para evitar este problema, o SQL Server 2005 realiza uma seqüência de tarefas para garantir que ao término da criação da cópia de segurança, todos os dados e objetos existentes na base de dados estão copiados no backup. Estes passos são:

• Travamento do Banco de Dados: Ao travar o banco de dados, o SQL Server fecha todas as conexões existentes.
• Criação da marca Checkpoint no Log de Transações: Neste passo, o SQL Server insere uma marca chamada Checkpoint. É através desta marcação que o SQL Server delimita até que ponto do log será feito o backup inicial. As transações que forem realizadas durante o processo de criação são copiadas depois de criado o backup inicial.
• Liberação do Banco de Dados: Depois de criado o Checkpoint, a base de dados é então liberada para receber as transações durante o processo de backup.
• Cópia de todas as páginas de dados: Neste passo, ocorre a criação do backup, onde o SQL Server 2005 realiza a cópia de todas as páginas de dados para o destino.
• Travamento do Banco de Dados: Uma vez copiada todas as páginas de dados, o SQL Server fecha novamente todas as conexões existentes.
• Criação da marca Checkpoint no Log de Transações: Novamente, o SQL Server insere a marca Checkpoint no Log de Transações.
• Liberação do Banco de Dados: Depois de criado o novo Checkpoint, o SQL Server libera o banco.
• Extração de todas as transações que ocorreram durante o processo de Backup: Através dos dois Checkpoints criados no arquivo de log, o SQL Server extrai todas as transações que foram efetuadas entre as duas marcações e adiciona ao backup. Isto garante a consistência dos dados e objetos existentes no backup no horário de termino da sua criação.

Métodos de Backup no SQL Server 2005

O SQL Server 2005 oferece quatro métodos de Backups. Estes métodos são:

• Full Backup;
• Differential Backup;
• Transaction Log Backup;
• Filegroup Backup.

Cada método possui características e dependências específicas, que são utilizadas pelo DBA para decidir quando cada um será utilizado na sua política de backup.

Full Backup

O Full Backup (Backup Completo) captura todos os dados que estão armazenados no banco de dados. A Engine executa esta tarefa copiando todas as Extents (Uma Extent contém 8 páginas de dados físicas e contínuas, ocupando 64kb de espaço) que possuem objetos do banco alocados. Com este tipo de backup, é possível recriar toda a base de dados. Além disso, ele sempre está disponível para o Administrador, independente do Recovery Model (Full, Bulk Logged ou Simple) configurando no banco em questão.

O Full Backup é pré-requisito para criação dos outros tipos de backup.

Differential Backup

O Differential Backup (Backup Diferencial) captura todas as Extents que sofreram alterações desde o ultimo Full Backup. Isso significa que todas as alterações de dados e objetos realizadas no banco são copiadas e armazenadas. As informações das Extents alteradas são armazenadas através do Extents Map.

Extent Map é um conjunto de páginas de dados pertencentes ao banco de dados, onde é armazenado um mapeamento de todas as Extents usadas pela base de dados. Cada Extent é um bit no mapa, de valor inicial 0 (zero). Quando uma Extent sofre alterações, o SQL Server acessa o mapa e marca com o valor 1. Esta é a condição usada pela Backup Engine para realizar o backup diferencial: apenas as Extents que possuem o valor 1 no mapeamento. Quando é realizado o Full Backup, todos os valores são zerados.

O backup diferencial sempre trabalha em conjunto com o backup completo: caso não exista um backup completo do banco, o SQL Server não permite a criação de um backup diferencial. Graças a integração com o Full Backup, o Differential Backup também é independente do Recovery Model configurado na base de dados.

Por fim, vale ressaltar que o backup diferencial não é a mesma coisa de um backup incremental: cada backup diferencial criado pode substituir todos os backups (Diferenciais e de Log) criados anteriormente até o ultimo backup completo, nos caso de restauração da base de dados.

Transaction Log Backup

O Transaction Log Backup (Backup do Log de Transações) trabalha em cima do log ativo, capturando todas as transações finalizadas deste o ultimo backup, qualquer que seja o tipo. Este tipo de backup é incremental: cada vez que é realizado, ele inicia a cópia do ponto em que foi realizado o ultimo backup e copia todas as transações finalizadas gravadas no log. Ao encontrar uma transação em aberto, o SQL Server finaliza a cópia.

Todas as transações que foram copiadas para o backup são marcadas pelo SQL Server. Esta marcação informa ao SQL Server que a transação em questão pode ser substituída por outra nova, ajudando a minimizar os impactos do crescimento do arquivo de log.

Filegroup e File Backup

O Filegroup Backup (Backup do Grupo de Arquivos) e os File Backup (Backup do Arquivo) são alternativas de backup em bancos que trabalham com múltiplos arquivos de dados. Enquanto todos os métodos de backup apresentados até agora realizam a cópia de toda a base de dados, estes backups permitem que você realize a cópia de cada arquivo e/ou grupo de arquivos pertencentes a um banco de dados de forma isolada. O conjunto de backups de todos os arquivos equivale ao um backup completo da base de dados.

A utilização deste tipo de backup apresenta algumas vantagens:

• Recuperação dos Arquivos de uma mídia danificada: Ao utilizar o método de backup de arquivos, a recuperação do banco de dados é mais rápida nos casos de falha parcial. Imagine um servidor com 3 (três) discos, e em cada um deles está armazenado um arquivo de dados do banco. Caso um destes discos falhe, só é necessário realizar a recuperação do arquivo que está na mídia danificada, e não do banco inteiro.
• Realização de Backups de Arquivos e do Log simultaneamente: Ao realizar o backup de um arquivo, o SQL Server não realiza a etapa de atualização das transações que foram realizadas no período de criação da cópia, somente a cópia das Extents do banco. Isto permite ao SQL Server a realização dos dois backups de forma independente.
• Flexibilidade na política de backup: Trabalhar com backup de arquivos permite ao administrador uma maior liberdade no agendamento das tarefas e no gerenciamento das mídias de armazenamento, principalmente nos casos em que o backup completo pode se tornar impraticável (Bases de dados muito extensas e que trabalham com múltiplos arquivos).

As principais desvantagens da utilização deste tipo de backup são o aumento da carga administrativa e a dependência de todos os backups para restaurar o banco de dados (se a mídia que possui um File ou Filegroup Backup falhar, não é possível a restauração da base de dados).

Filegroup Backup e File Backup requer que o Recovery Model do banco seja Full ou Bulk Logged, já que são os backups dos logs de transações que manterão a consistência do banco. É possível criar Full Backups e Differential Backups de cada arquivo ou grupo de arquivos do banco de dados.

Criando um Backup no SQL Server 2005

O SQL Server oferece duas formas para a criação de backup: através do SQL Server Management Studio ou usando comandos Transact-SQL. Em ambos os casos, é possível criar todos os tipos de backups abordados acima.

Criando um backup através do SQL Server Management Studio

Para acessar a janela de criação de backups, abra o Management Studio e expanda a pasta Databases na caixa Object Explorer. Ao expandir, clique com o botão direito no banco de dados que você deseja criar o backup (no nosso exemplo, o AdventureWorks) e vá em Tasks > Back Up. Ao selecionar a opção, é exibida a janela Back Up Database, como mostra a Figura 1.

Figura 1: Criando um backup – Página General

A janela Back Up Database é divida em duas partes: General (onde você configura as informações gerais do backup) e Options (onde você define algumas ações que serão efetuadas pelo SQL Server ao longo do processo).

Na página General, o primeiro passo é definir qual o banco de dados será copiado e qual o tipo de backup a ser realizado. Na caixa Database já deve está exibindo o banco AdventureWorks, já que este fora selecionando antes de abrir a janela. A caixa Recovery Model exibe o modelo de recuperação do banco selecionado. Esta informação é importante para determinamos quais métodos de backup estarão disponíveis para a base de dados. A caixa Backup Type é onde definimos o tipo de backup a ser efetuado (Full, Differential ouTransaction Log).

O SQL Server 2005 ainda oferece a opção de você realizar uma cópia de segurança apenas de um Filegroup ou de um arquivo de dados (*.mdf ou *.ndf) da base de dados selecionada. Para tanto, basta selecionar a opção File and Filegroups da caixa Database Component e definir os nomes dos arquivos ou grupos de arquivos que você deseja realizar o backup.

Após definido o banco de dados e o método de backup, o segundo passo é definir um nome de identificação, uma descrição e a data de expiração do backup criado. A expiração do backup informa ao SQL Server até quando aquele backup é válido. Uma vez vencida a data, o SQL Server poderá sobrescrever este backup, substituindo-o por um mais recente. Esta opção ajuda a manter constante o espaço do dispositivo de backup (Disco ou Fita) usado na criação dos backups, além de remover automaticamente backups desatualizados. Você pode configurar o vencimento informando a quantidade de dias que a cópia será valida ou determinando uma data para o seu vencimento. Digitando o valor 0 (zero) na caixa After (quantidade de dias) informa ao SQL Server 2005 que este backup não expira.

O ultimo passo para configurar o backup a ser criado é definir o destino da cópia. O SQL Server 2005 trabalha com duas opções de destino: Disk (Disco) ou Tape (Fita). Você pode trabalhar com até 64 destinos simultaneamente, de tal forma que o SQL Server dividirá o backup entre todos os destinos adicionados nesta opção. A opção de gravação em fita só estará disponível caso tenha um dispositivo DAT instalado. Para nosso exemplo utilizaremos o backup em disco.

Cada destino pode armazenar diferentes tipos de backup de diferentes bases de dados. Por exemplo, posso ter um backup completo do AdventureWorks e três backups de log de uma base de dados chamada CRM, todos armazenados no mesmo destino. Na hora da recuperação, é possível definir o conjunto de backups a ser restaurado, quando o destino possui mais de um backup armazenado.

Por padrão, o SQL Server 2005 possui uma pasta chamada BACKUP, onde são armazenados os bancos copiados. É esta a pasta que a caixa Destination sugere. Para adicionar um novo destino, clique no botão Add... e será exibida a janela Select Backup Destination. Nesta caixa, clique no botão ao lado do caminho e na janela Locate Database Files navegue até encontrar o local do arquivo de backup e digite um nome para este arquivo, como mostra a Figura 2.

Figura 2: Janela de escolha do destino do backup em disco

Definido o local, clique em OK e depois OK novamente e o SQL retornará a janela principal de criação de backup, mostrando o novo local adicionado a lista de destinos. Para remover um destino, selecione-o na lista e clique no botão Remove. Para ver mais informações sobre a mídia e os backups que já existem em um destino, selecione-o e clique no botão Contents. Para o nosso exemplo, realizaremos um Full Backup, removeremos o destino padrão e adicionaremos o destino C:\Backup\BackupSSMS.bak.

Configurado a página General, o próximo passo é configurar a página de Options. Ao selecioná-la no menu a esquerda da janela, o Management Studio apresenta a janela de opções, como mostra a Figura 3.

Figura 3: Opções do backup – Página Options

Nesta parte, o administrador pode configurar algumas ações ligadas à mídia de destino e outros backups existentes nesta mídia. A janela é divida em quatro partes: Overwrite Media, Reliability, Transaction Log e Tape Drive.

Em Overwrite Media, o DBA decide como o backup será gravado no Media Set. Media Set é um conjunto de mídias de backup (locais de destinos das cópias), com a finalidade de melhorar a organização das cópias e facilitar a restauração do backup.

É possível criar um novo Media Set a partir dos destinos configurados, marcando a opção Backup to a new media set, and erase all existing backup sets. Marcando esta opção, basta informar o nome e uma descrição para este novo conjunto.

Para utilizar um Media Set já existente, basta marcar a opção Backup to the existing media set. Desta forma, o administrador está informando ao SQL Server que utilizará o conjunto de destinos que já está configurado na caixa Destination. É necessário adicionar na caixa Destination (página General) todos os locais que fazem parte do Media Set, caso contrário o SQL Server não realiza o backup. É possível escolher duas opções em relação ao comportamento do novo backup dentro no conjunto: adicionar o novo backup a lista das cópias já existentes (Append to the existing backup set) ou apagar todos os backups anteriores e adiciona somente o atual (Overwrite all existing backup set).

Além disso, este item oferece a opção de verificar o nome do Media Set e a validade dos backups que já existem (Check media set name and backup set expiration), informando o nome do conjunto de mídia. Isto garante que o backup será feito nos locais desejados e da forma configurada.

Na parte Reliability, o administrador determina se deseja fazer testes no backup criado e na mídia onde será gravado o backup. A opção Verify backup when finished faz uma checagem no backup recém-criado, garantindo que este foi gravado corretamente. Já a opção Perform checksum before writing to media solicita ao SQL Server a execução de um teste no local onde será gravado o novo backup, garantindo assim que a mídia está livre de problemas. Quando esta opção está marcada, há uma redução no desempenho do servidor e um aumento do tempo de criação do backup, conseqüência dos testes que são efetuados na mídia. Opcionalmente, com a opção de teste na mídia marcada, é possível gravar o novo backup em uma mídia que contenha problemas, marcando a opção Continue on error.

As opções Truncate the transaction log e Back up the tail of the log, and leave the database in the restoring state estarão disponíveis apenas se o backup a ser criado é do tipo Transaction Log. A primeira opção marca as transações antigas existentes no arquivo de log e as remove logicamente, permitindo a substituição por novas transações. Isso permite a reutilização do espaço do log, minimizando o impacto gerado pelo crescimento do banco de dados e das transações realizadas. A segunda opção realiza o backup do log que ainda não sofreu backup até aquele instante (todas as transações que aconteceram desde o ultimo backup) e deixa o banco no estado de restauração. Neste estado o banco se torna inacessível para os usuários e evita a perda de dados em caso de restauração. Esta opção é utilizada quando o administrador pretende utilizar o método de restauração Point-in-time (O SQL Server restaura as transações até o dia e horário definido na janela da recuperação).

Por fim, na parte Tape drive, o DBA pode solicitar ao SQL Server duas ações. Unload the tape after backup faz com que o SQL Server descarregue a fita do drive após a criação do backup. Rewind the tape before unloading solicita a rebobinação da fita antes de ser descarregada do dispositivo (É necessário que a primeira opção esteja marcada). Ambas as opções só estarão disponíveis quando o destino das cópias for fita.

Feita todas as configurações desejadas, basta clicar no botão OK e aguardar a execução do backup. O progresso de criação é mostrado na caixa Progress, localizada no canto inferior esquerdo da janela Back Up Database. No final, o SQL Server exibe uma mensagem informando que o backup foi criado com sucesso.

Criando um backup através de comandos Transact-SQL

A linguagem T-SQL oferece o comando BACKUP para efetuar qualquer um dos métodos de backups apresentados neste artigo. Na Listagem 1 está a sintaxe básica de criação de um backup completo:

Listagem 1: Sintaxe básica para a criação de um backup.

--Setando o banco a ser utilizado
USE AdventureWorks;
--Criando um backup. Por padrão, o backup criado é do tipo FULL
BACKUP DATABASE AdventureWorks TO DISK='C:\Backup\BackupTSQL.bak';

Na sintaxe acima, foi solicitado ao SQL Server a criação de um backup da base de dados AdventureWorks, que foi salvo no destino C:\Backup\BackupTSQL.bak. Repare que no comando é necessário informar o tipo e o endereço do destino.

Para efetuar o backup diferencial, o comando é o mesmo do apresentado acima, adicionando a opção WITH DIFFERENTIAL no final do comando. Veja um exemplo na Listagem 2:

Listagem 2: Sintaxe para a criação de um backup diferencial.

--Setando o banco a ser utilizado
USE AdventureWorks;
--Criando um backup do tipo DIFFERENTIAL
BACKUP DATABASE AdventureWorks TO DISK='C:\Backup\BackupTSQL.bak'
WITH DIFFERENTIAL;

Veja que o destino é o mesmo do backup criando na Listagem 1. Isto é possível graças à capacidade do SQL Server de armazenar backups de tipos e de bancos diferentes no mesmo destino, como visto anteriormente.

Para realizar o backup do log de transações, o comando muda para BACKUP LOG. Observe a Listagem 3:

Listagem 3: Criação de um backup do log de transações.

--Setando o banco a ser utilizado
USE AdventureWorks;
--Criando um backup do LOG
BACKUP LOG AdventureWorks TO DISK='C:\Backup\BackupLOG.bak';

No exemplo acima, foi criado um novo arquivo de backup, onde as transações que aconteceram deste o ultimo backup (no nosso exemplo, o diferencial) são copiadas.

Por fim, para realizar o backup de um arquivo, a sintaxe é idêntica ao da criação de um backup da base de dados, adicionando a clausula FILE no comando. Observe um exemplo de backup do arquivo AdventureWorks_Data.mdf para o arquivo BackupFILE.bak na Listagem 4:

Listagem 4: Criação de um backup de um arquivo.

--Setando o banco a ser utilizado
USE AdventureWorks;
--Criando um backup do LOG
BACKUP DATABASE AdventureWorks FILE='AdventureWorks_Data' TO DISK='C:\Backup\BackupFILE.bak';

Repare que não é necessário informar a extensão do arquivo de dados na cláusula FILE. Para realizar o backup de um FILEGROUP, o procedimento é idêntico. Confira na Listagem 5:

Listagem 5: Criação de um backup de um grupo de arquivos.

--Setando o banco a ser utilizado
USE AdventureWorks;
--Criando um backup do LOG
BACKUP DATABASE AdventureWorks FILEGROUP='PRIMARY' TO DISK='C:\Backup\BackupFG.bak';

No final, após a criação de todos os backups sugeridos acima, os arquivos armazenados no local C:\Backup são os mostrados na Figura 4.

Figura 4: Listagem dos arquivos criados

Agora veremos como realizar a restauração de backups no SQL Server 2005, a seqüência de recuperação dos diferentes tipos e como realizá-los através do Management Studio e da linguagem T-SQL.

Entendendo o processo de Restore no SQL Server 2005

Restaura um banco consiste, basicamente, em operações que recriam os objetos da base de dados até um ponto específico no tempo. Este ponto é o momento em que a criação do backup foi realizada e finalizada.

Diferente da criação do backup, o processo de restauração é seqüencial. Desta forma, o SQL Server garante a consistência dos dados, mas acaba consumindo mais tempo e recursos do servidor.

Por reescrever todas as páginas de dados, o processo de restauração não apenas pode ser utilizado para fins de substituição de uma base originalmente defeituosa, mas também em processos de transferência de bancos de dados para novos servidores SQL Server.

Além disso, vale lembrar que uma operação de Restore pode se resumir em um único passo onde apenas um Backup Completo é recuperado e o banco passa a esta disponível para os usuários e receber transações. Entretanto, na grande maioria dos casos, o cenário exige que o Administrador restaure um conjunto de backups, possibilitando assim a minimização da perda de dados. Em ambientes de alta disponibilidade, cinco minutos de perda de dados podem significar a eliminação de milhares de registros.

Por fim, uma observação importante: durante todo o processo de restauração, o banco fica inacessível para todos os usuários. Ele só se tornará acessível no momento em que o banco estiver no estado Restored (Restaurado). A única exceção desta regra é o processo Online Restore, que veremos adiante neste artigo.

Métodos de Restauração no SQL Server 2005

Baseado nos métodos de Backups existentes, o SQL Server 2005 oferece quatro métodos de Restore. Estes métodos restauram os seguintes tipos de backup:

• Full Backup;
• Differential Backup;
• Transaction Log Backup;
• Partial Backup.

Dependendo da política de criação de backups e do conjunto de cópias existente, cada método possui características e dependências específicas, que organizam e agilizam a recriação do banco de dados.

Restaurando um Full Backup

Na grande maioria dos casos, o primeiro passo no processo de restauração é a recriação completa da base de dados até um ponto específico no tempo, para que então o DBA aplique backups complementares que atualizem o banco para o estado desejado. Este processo começa com a restauração de um Full Backup (Backup Completo).

No artigo anterior, vimos que o backup completo possui todas as Extents que compõem um banco de dados e, conseqüentemente, todo o seu conteúdo. A operação de restauração, nos processo de reconstrução da base de dados, grava todas as páginas de volta no servidor seguindo a seqüência original do banco. Desta forma, o processo de Restore garante a consistência dos dados, mas acaba consumindo mais tempo.

A restauração do Full Backup é pré-requisito para a utilização dos outros tipos de restauração de backup.

Restaurando um Differential Backup

Antes de restaurar um Differential Backup (Backup Diferencial), duas condições devem ser satisfeitas:

• Backup Completo Restaurado: Como o backup diferencial grava todas as Extents alteradas desde o ultimo backup completo, é necessário a restauração do backup completo (ou seja, as Extents originais) para então aplicar o Differential Backup.
• A base de dados deve está no modo Recovering: Ao realizar o backup de um arquivo, o SQL Server não realiza a etapa de atualização das transações que foram realizadas no período de criação da cópia, somente a cópia das Extents do banco. Isto permite ao SQL Server a realização dos dois backups de forma independente.

Uma vez estas condições atendidas, o SQL Server 2005 então permite a restauração da cópia de segurança. Durante esta operação, as Extents armazenadas no backup sobrescrevem as já existentes no servidor, atualizando assim o conteúdo do banco de dados.

Por fim, vale ressaltar que o backup diferencial substitui todos os backups (Diferenciais e de Log) criados anteriormente. Desta forma, para o Administrador, só há a necessidade de restaurar apenas o ultimo backup diferencial disponível.

Restaurando um Transaction Log Backup

Ao criar um Transaction Log Backup (Backup do Log de Transações), o SQL Server armazena no destino a seqüência de transações que foram efetuadas desde o ultimo backup até o instante atual. Esta seqüência de transações são ordenadas pelos seu LSN (Log Sequence Number – Número de Seqüência no Log).

Sendo assim, quando o DBA executa a restauração de um backup do log de transações, o SQL Server lê as transações armazenadas na cópia de segurança e as executa no banco de dados, atualizando-o até o instante em que esse backup foi criado.

Desta forma, os backups do log só podem ser aplicados após a restauração de outro backup de qualquer tipo (Completo, Diferencial ou de Log).

Como as transações são ordenadas pelo LSN, o Administrador possui a oportunidade de restaurar a base de dados até um ponto específico. Esta característica, aliada ao fato de que o log é independente do banco, possibilita uma maior flexibilidade na hora de restaurar uma base de dados. Para entender as vantagens que este tipo de backup oferece no processo de restauração, apresentaremos algumas situações de restauração.

Imagine a existência de um servidor de dados SQL Server 2005 com uma aplicação CRM (Customer Relationship Management). Certo dia, os arquivos de dados (*.mdf e *.ndf) desta base são danificados e o banco torna-se inacessível. Após verificar o problema, o Administrador decide então restaurar o banco de dados. Nesta situação, como minimizar a perda de dados, já que o banco está inacessível?

Independente do ultimo backup que o Administrador possua, é possível realizar o backup do log de transações mesmo com a base de dados danificada, já que as transações são armazenadas em um arquivo diferente (*.ldf). Logo, o Administrador consegue realizar um Transaction Log Backup e assim copiar todas as ações que foram efetuadas no CRM até o instante da falha.

De posse deste backup e de um backup completo (lembre-se que o backup do log só pode ser efetuado após a criação de, pelo menos, um Full Backup), o SQL Server permite restaurar o banco para o instante antes da falha e assim minimizar a perda de dados.

Outra utilização do backup do log é a de facilmente reverter, por exemplo, a remoção de uma tabela acidentalmente por um usuário: basta restaurar o banco até o instante anterior ao comando executado pelo usuário. Mas lembre-se que, durante o processo de Restore, o banco fica indisponível para todos os usuários.

Nestes casos, para restaurar objetos removidos acidentalmente sem afetar o funcionamento do restante do sistema, recomenda-se restaurar os backups para um novo banco até o instante anterior da remoção; deste ponto copiar o objeto e colar na base de dados original.

Restaurando um Filegroup e File Backup

A restauração de um Filegroup Backup (Backup do Grupo de Arquivos) ou de um File Backup (Backup do Arquivo) é efetuada de forma semelhante ao backup completo.

A grande diferença está na possibilidade de restaurar apenas uma parte do banco de dados, minimizando a inacessibilidade do servidor. Desta forma, o administrador tem a vantagem de só restaurar a parte (arquivo ou grupos de arquivos) danificada, enquanto o restante do banco de dados continua disponível. Este tipo de restauração também é chamado de Partial Restore (Restauração Parcial).

Entretanto, vale lembrar que, em falha total do banco, todos os backups dos arquivos são necessários para restaurar o banco de dados (se a mídia que possui um File ou Filegroup Backup falhar, não é possível a restauração da base de dados).

Restaurando um Backup no SQL Server 2005

O SQL Server oferece duas formas para a restauração de backup: através do SQL Server Management Studio ou usando comandos Transact-SQL. Em ambos os casos, é possível restaurar todos os tipos de backups abordados acima.

Restaurando um backup através do SQL Server Management Studio

Para acessar a janela de restauração de backups, abra o Management Studio e clique com o botão direito na pasta Databases e selecione a opção Restore Database.

Figura 5: Restaurando um backup – Página General

A janela Back Up Database é divida em duas partes: General (onde você configura as informações de destino e da fonte da restauração) e Options (onde você define algumas ações que serão efetuadas pelo SQL Server ao longo do processo).

Na página General, o primeiro passo é definir qual será o nome do novo banco de dados. Você pode escolher um nome da lista de bancos já existente no servidor ou digitar o seu próprio.

Algumas observações são válidas em relação a esta propriedade. Se você escolher uma base já existente e realizar a operação de restauração, todas as operações que foram efetuadas desde a criação do backup são perdidas. Outro fato importante de ser destacado é que o nome da base não precisa, necessariamente, ser igual ao nome da base de dados que foi efetuado o processo de backup. Isso permite ao Administrador criar uma cópia do banco de dados sem afetar a base que está em produção.

Depois de escolhido o nome da base de dados destino, o próximo passo é configurar até que momento você deseja restaurar esta base. Como explicado no artigo anterior, é possível você restaurar um banco de dados até um momento no tempo. Este tipo de restauração é chamado de Point in Time (Ponto no Tempo). Para escolher um determinando momento, basta você clicar no botão  e o Management Studio apresentará a janela Point in Time Restore, como mostra a Figura 6.

Figura 2: Janela Point in Time Restore

Nesta janela, você pode escolher duas opções:

• The most recent state possible: Esta opção informa ao SQL Server que o banco de dados deve ser restaurado até o estado mais recente disponível. Ou seja: até o momento em que o backup foi finalizado.
• A specific date and time: Como o nome já diz, esta opção permite que você selecione uma data e um horário específico. Uma vez configurada estas opções, o SQL Server 2005 ira realizar a restauração do banco de dados até este instante do tempo. Os dados que existem após este momento no tempo não são restaurados. Isto permite ao DBA uma grande flexibilidade, já que permite, por exemplo, restaurar a base de dados até o instante anterior a uma transação indesejada.

Após definido as informações de destino, o próximo passo é configurar a origem dos dados e quais Sets. Este passo é divido em duas parte: em uma, você define de qual banco de dados ou arquivo os dados serão restaurados; na segunda, você escolhe quais backups serão restaurados.

A opção From Database permite ao Profissional restaurar o backup de uma base de dados existente no histórico de backups realizados pelo SQL Server. Este histórico fica armazenado na base de sistema msdb, toda vez que um backup é criado pelo Servidor (Interessante notar que, ao solicitar a exclusão de uma base de dados através do Management Studio, o SQL Server 2005 pergunta se você deseja remover também o histórico de Backup e Restore deste banco de dados).

Já a opção From Device permite ao Administrador navegar e selecionar arquivos ou dispositivos que possuem as cópias desejadas. Ao selecionar esta opção, é possível adicionar arquivos e dispositivos clicando no botão , exibindo assim a janela Specify Backup, como mostra a Figura 7.

Figura 7: Janela Specify Backup

Esta janela possui os campos Backup Media, onde você define o tipo de mídia do backup (Arquivo, Dispositivo de Backup ou Fita); e Backup Location, onde são exibidas as localizações dos backups. Para adicionar um novo arquivo a esta lista, clique no botão Add e navegue até encontrar o arquivo que possui a cópia do banco que você deseja restaurar e clique em OK. A janela Specify Backup passa a mostrar a localização do arquivo selecionado (como mostra a Figura 7).

Depois da localização do backup ser adicionado à lista, é possível realizar duas ações: verificar o seu conteúdo, através do botão Contents; ou remove-lo da lista, usando o botão Remove. O botão Contents possui uma grande finalidade: exibe os detalhes dos backups que estão armazenados dentro do arquivo ou dispositivo selecionado, através da janela Device Contents (Figura 8). Isto se torna bastante útil quando você tem várias cópias e não sabe em que arquivo ou fita está armazenado um backup específico. Esta funcionalidade é idêntica ao comando Transact-SQL RESTORE HEADERONLY.

Figura 4: Janela Device Contents

Uma vez definidos os locais de backup, basta clicar no botão OK para fechar a janela Specify Backup e retornar à janela Restore Database.

Ao retornar a janela Restore Database, o Management Studio passa a listar os backups que estão armazenados nos locais selecionados, para que o Profissional selecione quais cópias restaurar. No exemplo mostrado na Figura 5, o SQL Server oferece a restauração de um Backup Completo da base de dados AdventureWorks. Definidas as propriedades gerais da restauração, a próxima ação é configurar as opções desta restauração.

A página Option é responsável por definir as propriedades de uma restauração. Estas propriedades incluem a definição dos nomes e locais dos arquivos de dados e log, o estado de recuperação do banco de dados (Recovery Model) e algumas propriedades inerentes ao processo de recriação da base de dados. Observe a Figura 9:

Figura 5: Restaurando um backup – Página Options

Da mesma forma que a página anterior, a página Options é dividida em duas partes: Restore Options e Recovery State. Na primeira parte, o SQL Server 2005 oferece ao administrador algumas propriedades que alteram o comportamento do processo de Restore. São elas:

• Overwrite the existing database: Esta opção permite que o processo de restauração sobrescreva o banco atual com a cópia a ser recuperada. Ao marcar esta opção, o SQL Server substitui as páginas de dados atuais pelas contidas na cópia. Uma consideração importante sobre esta opção é que o banco a ser sobrescrito não necessariamente é o mesmo existente na cópia, mas sim o informado na página General, no campo To Database. Esta ação não pode ser desfeita.
• Preserve the replication settings: Em caso de restauração de bancos publicados para replicação (duplicação), o SQL Server permite o Restore deesta bases publicadas em outros servidores diferentes do servidor de origem, trazendo consigo todas as configurações da replicação configurada anteriormente. Esta opção só estará disponível caso o estado de recuperação do banco de dados seja definido como RESTORE WITH RECOVERY.
• Prompt before restoring each backup: Ao marcar esta opção, o SQL Server pergunta ao DBA, após a restauração de um backup, se deseja continuar com o processo. Esta opção é utilizada quando o Administrador define a restauração de múltiplos backups na guia General, através da lista Select the backup sets to restore. Propriedade extremamente útil nos casos em que os backups estão distribuídos em várias fitas e seu servidor só possui um dispositivo para leitura: nos momentos de interrupção, o Administrador realiza a troca da fita e clica no botão OK para prosseguir com o processo. Caso o Administrador clique no botão NO, processo será interrompido e o banco ficará no estado de restauração RESTORE WITH NORECOVERY.
• Restrict Access to the restored database: Esta opção restringe o acesso ao banco, permitindo apenas que usuários dos papeis db_owner, dbcreator ou sysadmin acessem a base de dados.

Depois destas propriedades, a janela Restore Database oferece ao Administrador a possibilidade de definir o local dos arquivos de Dados e de Log da base a ser restaurada. Na primeira coluna, o SQL Server exibe os nomes originais dos arquivos do banco de dados. Na segunda coluna, o administrador pode definir qual será o novo local de cada arquivo da base de dados, clicando no botão  e escolhendo o destino.

Depois de definidas as propriedades do processo de restauração, vem o passo mais importante desta janela: Recovery State. Esta opção define o comportamento do banco de dados após o processo de Restore. São três opções disponíveis:

• RESTORE WITH RECOVERY: Esta opção informa ao SQL Server que, após a restauração, o banco de dados recuperado já estará disponível para utilização pelos usuários. Esta opção será utilizada nos casos em que a base de dados só possui um backup a ser restaurado. Uma vez restaurado no modo RECOVERY, não é possível aplicar o Restore do Log de Transações, uma vez que a base já recebeu novas transações.
• RESTORE WITH NORECOVERY: Também chamado de Recovering State, esta opção informa ao SQL Server que o banco de dados ainda receberá outros backups. Neste estado, a base ainda não aceita conexões de usuários, mantendo-o intacto até que seja restaurado o último backup com a opção RECOVERY WITH RECOVERY. Utilize esta opção quando o banco a ser restaurado possui vários conjuntos de backups (Exemplo: restaurar um Full Backup e em seguida um Differential Backup: o completo será restaurado comoNORECOVERY; o diferencial como RECOVERY).
• RESTORE WITH STANDBY: Informa ao SQL Server que a base restaurada estará no modo STANDBY, permitindo acesso no modo somente leitura. Ao escolher esta opção, o DBA define o local do arquivo que permitirá desfazer as alterações realizadas pelo STANDBY. Utilize esta opção no seguinte cenário: o Administrador deseja restaurar o banco para um momento específico, mas ele não possui nenhuma informação precisa sobre este momento (Não tem idéia exata do horário e nem da transação realizada). A solução seria restaurar o banco através com a opção STANDBY. Desta forma, é possível realizar consultas na base de dados para saber se o momento desejado é o atual. Se o momento for posterior, basta realizar a restauração de mais backups com STANDBY até encontrar o ponto desejado. Nos casos do momento desejado ser anterior ao carregado pelo backup, entra em ação o arquivo do STANDBY, que permite desfazer o ultimo backup. Ao encontrar o momento desejado, basta realizar a restauração com a opção RECOVERY.

Feita todas as configurações desejadas, basta clicar no botão OK e aguardar a execução do backup. O progresso de criação é mostrado na caixa Progress, localizada no canto inferior esquerdo da janela Restore Database. No final, o SQL Server exibe uma mensagem informando que o processo de restauração foi realizado com sucesso.

Restaurando um backup através de comandos Transact-SQL

A linguagem T-SQL oferece o comando RESTORE para efetuar qualquer um dos métodos de recuperação de backups apresentados neste artigo. Na Listagem 6 está a sintaxe básica de restauração de um backup:

Listagem 6: Sintaxe básica para a restauração de um backup.

--Setando o banco a ser utilizado
USE master;
--Restaurando um backup. Por padrão, o modo de recuperação é RECOVERY
RESTORE DATABASE AdventureWorks FROM DISK='C:\Backup\BackupTSQL.bak';

Na sintaxe acima, foi solicitado ao SQL Server a restauração de um backup que está salvo no destino C:\Backup\BackupTSQL.bak, criando uma base de dados chamada AdventureWorks. Repare que no comando é necessário informar o tipo e o endereço da cópia.

Nos casos em que o banco já existe, o Administrador pode sobrescrevê-lo usando a opção WITH REPLACE. Na Listagem 7 está um exemplo:

Listagem 7: Sintaxe para a restauração de um banco já existente.

--Setando o banco a ser utilizado
USE master;
--Restaurando um backup de uma base já existente
RESTORE DATABASE AdventureWorks FROM DISK='C:\Backup\BackupTSQL.bak' WITH REPLACE;

Para restaurar um backup diferencial, o DBA precisa restaurar a cópia completa com a opção NORECOVERY. Depois de restaurado o Full Backup, basta utilizar mesmo comando, só que informando a opção RECOVERY. Veja um exemplo na Listagem 8:

Listagem 8: Sintaxe para a criação de um backup diferencial.

--Setando o banco a ser utilizado
USE master;
--Restaurando apenas o Full Backup, com a opção NORECOVERY
RESTORE DATABASE AdventureWorks FROM DISK='C:\Backup\BackupTSQL.bak'
WITH NORECOVERY;
--Restaurando o Differential Backup, com a opção RECOVERY
RESTORE DATABASE AdventureWorks FROM DISK='C:\Backup\BackupTSQL.bak'
WITH RECOVERY;

Veja que o backup é o mesmo utilizado na Listagem 6. Isto é possível graças à capacidade do SQL Server de armazenar backups de tipos e de bancos diferentes no mesmo destino, como visto anteriormente.

Para restaurar o backup do log de transações, o comando muda para RESTORE LOG. Observe a Listagem 9:

Listagem 9: Restauração de um backup do log de transações.

--Setando o banco a ser utilizado
USE master;
--Restaurando um backup do LOG
RESTORE LOG AdventureWorks FROM DISK='C:\Backup\BackupLOG.bak' WITH RECOVERY;

Lembrando que no exemplo acima foi utilizado a opção RECOVERY para restaurar o Log e disponibilizar a base de dados para os usuários. Nos casos em que o Profissional precise restaurar mais de um backup do Log, deve-se utilizar a opção RECOVERY apenas na última restauração e a opção NORECOVERY para as restaurações anteriores.

Por fim, para restaurar o backup de um arquivo, a sintaxe é idêntica a vista anteriormente, adicionando a clausula FILE no comando. Observe um exemplo de restauração do arquivo AdventureWorks_Data.mdf a partir do arquivo BackupFILE.bak na Listagem 10:

Listagem 10: Restauração de um backup de um arquivo.

--Setando o banco a ser utilizado
USE master;
--Restaurando um backup de Arquivo
RESTORE DATABASE AdventureWorks FILE='AdventureWorks_Data' FROM DISK='C:\Backup\BackupFILE.bak';

Repare que não é necessário informar a extensão do arquivo de dados na cláusula FILE. Para restaurar o backup de um FILEGROUP, o procedimento é idêntico. Confira na Listagem 11:

Listagem 11: Restauração de um backup de um grupo de arquivos.

--Setando o banco a ser utilizado
USE master;
--Restaurando um backup do Grupo de Arquivos
RESTORE DATABASE AdventureWorks FILEGROUP='PRIMARY' TO DISK='C:\Backup\BackupFG.bak';

Da mesma forma que os métodos de restauração acima, é possível utilizar as opções RECOVERY ou NORECOVERY nos casos de restauração de múltiplos arquivos ou grupos de arquivos.

No final, após a restauração de todos os backups sugeridos acima, o banco AdventureWorks estará restaurado e disponível para os usuários, como mostra a Figura 10.

Figura 10: Banco de Dados AdventureWorks restaurado

Conclusão

O procedimento de criação de backups é uma constante no dia-a-dia do Administrador de Banco de Dados. Neste artigo apresentamos o funcionamento da Backup Engine, responsável pela cópia dos dados. Mostramos como criar todos os tipos de backup através do SQL Server Management Studio e utilizando comandos Transact-SQL.

Mais importante que a criação de backups é o procedimento de restauração destas cópias de segurança feitas pelo Administrador de Banco de Dados. Neste artigo apresentamos o funcionamento do processo de restauração realizado pelo SQL Server 2005. Mostramos como restaurar todos os tipos de backup através do SQL Server Management Studio e utilizando comandos Transact-SQL. Na próxima e última parte desta série de artigos, veremos alguns recursos avançados relacionados a Backup e Restore no SQL Server 2005.