Backup, Tech, Virtual PASS BR

Restore – A fase crítica do processo

5/5 - (1 vote)

No dia 11/02 publiquei um artigo falando dos tipos mais básicos de backup no SQL Server. Dando continuidade tentarei abordar neste post um pouco sobre o processo de restore, especificamente dos tipos de backup (Full, Differential e Transaction Log) discutidos no post anterior.

Existe um cara super pessimista, ou excessivamente realista chamado Edward Murphy, que criou diversas leis, dentre as quais separei duas que podem ser aplicadas ao nosso contexto:

  • “Se alguma coisa pode dar errado, dará. E mais, dará errado da pior maneira, no pior momento e de modo que cause o maior dano possível”.
  • “A informação mais necessária é sempre a menos disponível”.

Olhando por este ponto, cabe ao DBA ou responsável pelas operações de backup / restore, comprovar que tais leis podem ser aplicadas em qualquer lugar, exceto naquele local e naquele momento. É necessário com testes de restore (citados nos primeiros posts da série) garantir que seus backups poderão ser restaurados. De posse desta garantia, partamos para o “How to” deste processo.

Como criei e citei exemplos dos tipos de backups básicos para um processo funcional, aqui neste post também exemplificarei apenas estes três tipos, uma referência detalhada sobre restore no SQL Server, pode ser consultada na página oficial do site do MSDN.

As possibilidades de restore e geração de backups estão diretamente ligadas ao “Recovery Model” em que o banco de dados está configurado, porém este recovery model será apenas citado neste post e já fica como compromisso para um post futuro, mais informações sobre, podem ser consultadas aqui: Recovery Model Overview.

Os restores possíveis de acordo com nossos backups previamente realizados são:

  • Restore Completo do banco (Backup Full)
  • Restore Parcial ou diferencial (Backup Full + Backup Differential)
  • Restore do Log de Transações (Backup Full + Backup Differential + Backups dos Logs)
  • Restore ao ponto da falha, ou “Point in Time” (Backup Full + Backup Differential + Backups dos Logs)
  • Restore de uma ou mais página de dados (Assunto para um outro post)

Restore Completo do banco (Backup Full)

É aqui onde tudo começa, pois os demais tipos de backup (Differential e Log) dependem do Full para serem restaurados. Este tipo de restore possibilita a restauaração completa da base no momento da finalização do processo de backup. O arquivo de backup, geralmente (mas não obrigatoriamente) possui a extensão “.bak”, este arquivo contém todas as páginas de dados (incluindo metadados), usuários, configurações e também a porção ativa do log das transações que estavam ativas no momento do backup.

O primeiro passo para restauração de um backup full, é saber o nome e o caminho dos arquivos lógicos (Dados e Log ) do seu banco de dados, para isto deve-se executar seguinte comando, que vai apenas “listar” os arquivos contidos no backup, e seus respectivos caminhos:

RESTORE FILELISTONLY

 FROM DISK = N’C:tempBackups_SQLSERVERBKP_DB_BACKUP_EXEMPLO_FULL.BAK’

Como se pode observar os arquivos de dados e log foram criados no caminho padrão do SQL Server, pois durante a criação do banco não foram especificados os diretórios onde estes arquivos seriam armazenados e na instalação do SQL Server, também não foi alterados o caminho padrão para arquivos de bancos de dados dos usuários, neste caso, será necessário “MOVER” os arquivos de dados e log para o diretório desejado, este cenário se aplica muito quando há backup do banco em um servidor e restore em outro servidor.

Para restaurar um backup full e mover os arquivos o script de restore deve contar a opção “MOVE”, conforme demonstrado abaixo.

RESTORE DATABASE [DB_BACKUP_EXEMPLO]
FROM DISK = N’C:tempBackups_SQLSERVERBKP_DB_BACKUP_EXEMPLO_FULL.BAK’
WITH FILE = 1
,MOVE ‘DB_BACKUP_EXEMPLO’
TO ‘C:tempMSSQLDadosDB_BACKUP_EXEMPLO.mdf’
,MOVE ‘DB_BACKUP_EXEMPLO_log’
TO ‘C:tempMSSQLLogDB_BACKUP_EXEMPLO_Log.ldf’
,NORECOVERY
,REPLACE
,STATS = 5

Opções no script:

  • NORECOVERY – Esta opção foi utilizada, pois teremos que restaurar outros backups (Diferencial e Log), caso o único backup a ser restaurado fosse o Full, esta opção deveria ser omitida ou usada a opção RECOVERY.
  • REPLACE – Deve se utilizar esta opção sempre quando o banco de dados for substituído pelo backup, neste caso faremos com que o restore substitua o arquivo de banco que está atualmente na instância, caso não seja este o cenário, esta opção pode ser simplesmente omitida.
  • STATS – Opção para exibir na console do SQL Server o progresso do processo, caso não deseje a exibição, basta omitir esta opção.

Restore Parcial ou diferencial (Backup Full + Backup Differential)

O restore de um backup Differential, sempre deve ser precedido de um restore Full, caso contrário o SQL Server indicará um erro, informando não ser possível restaurar o banco de dados, pois não houve restauração prévia de um backup Full. Igualmente ao backup full, este arquivo contem as páginas de dados alteradas desde o último backup Full, juntamente com a porção ativa do Log de transações durante a geração deste backup.

Segue demonstração de restore de um backup Differential seguindo a sequência após restauração do backup full.

Observação: Neste ponto, não é mais necessário utilizar a opção MOVE para os arquivos, uma vez que o diretório de armazenamento já foi informado durante o restore do backup Full.

RESTORE DATABASE [DB_BACKUP_EXEMPLO]
FROM DISK = N’C:tempBackups_SQLSERVERBKP_DB_BACKUP_EXEMPLO_DIFF.BAK’
WITH NORECOVERY
,STATS = 3

Opções no script:

  • NORECOVERY – Esta opção foi utilizada, pois teremos que restaurar outros backups (Log), a sequência de restore terminasse aqui, deveria-se utilizar a opção RECOVERY.
  • STATS – Opção para exibir na console do SQL Server o progresso do processo, caso não deseje a exibição, basta omitir esta opção.

Restore do Log de Transações (Backup Full + Backup Differential + Backups dos Logs)

Este é o mais fascinantes dos backups no SQL Server, é pelo backup do Log de Transações que é possível restores ao ponto da falha ou em pontos específicos. A dependência é que haja um backup Full precedente aos backups de logs, e que TODOS os arquivos de backups de log sejam restaurados na sequência desde o Full até o momento em que se deseja restaurar a base. A sequência lógica é restaurar o Backup Full, em seguida o Backup Differential e então todos os Backups de Log na sequência. Caso haja perda, corrupção ou indisponibilidade de um backup Differential, ainda assim é possível realizar o restore, utilizando-se da mesma sequência, porém ignorando-se o Backup Differrential ausente e restaurando o Full, depois TODOS os Backups de Log.

Segue exemplo de Restore de um backup de Log:

RESTORE LOG [DB_BACKUP_EXEMPLO]
FROM DISK = N’C:tempBackups_SQLSERVERBKP_DB_BACKUP_EXEMPLO_LOG.BAK’
WITH NORECOVERY

Opções no script:

  • NORECOVERY – Neste caso, pode-se utilizar diretamente a opção RECOVERY, pois finalizou-se o processo de restore, ou então colocar o banco em modo operacional em seguida, conforme será feito no exemplo.
  • STATS – Opção para exibir na console do SQL Server o progresso do processo, caso não deseje a exibição, basta omitir esta opção.

Após a sequência de restores das bases de dados, caso não tenha sido execuado o RECOVERY na última instrução de restore, este pode ser executado a parte, pela execução do seguinte script:

RESTORE DATABASE [DB_BACKUP_EXEMPLO] WITH RECOVERY

Restore ao ponto da falha, ou “Point in Time” (Backup Full + Backup Differential + Backups dos Logs)

Executado exatamente igual ao restore do log, porém é informado a opção STOPAT na cláusula de restore, que informa onde o restore deve literalmente “PARAR”.

Exemplo de um script para restore Point in Time:

RESTORE LOG [DB_BACKUP_EXEMPLO]
FROM DISK = N’C:tempBackups_SQLSERVERBKP_DB_BACKUP_EXEMPLO_LOG.BAK’
WITH NORECOVERY
,STOPAT =‘2012-02-17 22:02:20.000’

  • NORECOVERY – Neste caso, pode-se utilizar diretamente a opção RECOVERY, pois finalizou-se o processo de restore, ou então colocar o banco em modo operacional em seguida, conforme será feito no exemplo.
  • STOPAT = ‘2012-02-17 22:02:20.000’  – Esta opção, permite restaurar o banco a um ponto específico no tempo que seja menor do que o momento da execução do backup.
  • STATS – Opção para exibir na console do SQL Server o progresso do processo, caso não deseje a exibição, basta omitir esta opção.

Após a sequência de restores das bases de dados, caso não tenha sido executado o RECOVERY na última instrução de restore, este pode ser executado a parte, pela execução do seguinte script:

RESTORE DATABASE [DB_BACKUP_EXEMPLO] WITH RECOVERY

Finalizo mais um post, com a típica frase:  Consegui a façanha de chegar até o final? Por favor, deixe um comentário, crítica, dúvida ou elogio, para que possa servir de incentivo e melhorar sempre a qualidade dos conteúdos aqui disponibilizados…

Muito Obrigado…

Grande Abraço,


Att.:

Edvaldo Castro

Administrador de Banco de Dados

@edvaldocastro02

Tagged , , , , , , , , , ,

15 thoughts on “Restore – A fase crítica do processo

  1. Sua contribuição me tornou um administrador melhor.

    Sou pura gratidão.

  2. Edvaldo existe algum restore interno e externo
    Se sim o que significa cada um??

    1. Ola Fabio,
      Talvez eu nao tenha entendido muito bem sua pergunta, mas acredito que a resposta seja nao. O restore e realizado basicamente com a finalidade de deixar um banco disponivel para utilizacao, nao sei bem qual o ponto de sua pergunta com relacao ao restore interno e externo.

      Obrigado pela leitura e comentario.

      Edvaldo Castro

  3. Entendi,

    Vou montar uma nova estratégia.
    Incluir apenas um DIFERENCIAL no dia e o restante de LOG, você acha uma boa idéia?

    1. Olá Leonardo,

      É difícil dizer se é uma boa estratégia ou não sem conhecer exatamente o ambiente e a tolerância à downtime e perda de dados… Porém de uma maneira genérica, o backup DIFERENCIAL te dá uma garantia de “redundância” e menos trabalho, pois não necessitará de todos os backups de Logs desde o último Full, mas somente após o diferencial restaurado… Por outro lado, é um custo de armazenamento, visto que o backup Diferencial NÃO é o backup da diferença entre o último diferencial, mas do último FULL.. assim sendo, seu backup DIFERENCIAL de sexta-feira, provavelmente ocupará bastante espaço, se o seu FULL for realizado aos sábados ou domingos…

      Abraço, e obrigado pela interação no post…

      1. Edvaldo,
        Eu que agradeço pelas duvidas sanadas, aliás, seu site é muito bom em conteúdo.

        Atualmente eu faço um Backup FULL diariamente a noite, então pensei em incluir um diferencial durante o dia + LOG, pois ao que parece é a forma mais “segura” de se manter a base integra em caso de restore.

        A forma atual é BACKUP FULL(noite) + LOGs(durante o dia)

        O que voce aconselharia? (Obs, nao tenho problema de Storage)

        Grato

    1. Olá Leonardo,
      Sim, é possível porém muito mais trabalhoso e propenso a falhas, pois você necessita de TODOS os arquivod de backup do log para realizar o restore ate o ponto desejado, se um destes arquivos estiver corrompido ou ausente… Seu restore torna-se impossível a partir daquele ponto…

      Abraços…

      1. Li o comentário e achei interessante a explicação desse lance do FULL + LOG não ser uma estratégia interessante. Você pretende abordar posteriormente assuntos como log backup chain?
        Abs

  4. Parabéns pelo post Edvaldo! É muito importante detalhar como conseguimos recuperar nossos dados após um desastre e você fez isso muito bem com seu post.

    1. Obrigado Cibelle Castro…

      Ainda tem bastante coisa pra falar sobre backups… Vou tentar manter a frequencia e aumentar paulatinamente a complexidade do conteúdo…

      Abraços

      Edvaldo Castro

Leave a Reply to Cibelle Castro Cancel reply

Your email address will not be published. Required fields are marked *