none
URGENTE ! Restauração de Backup em um Ponto-No-Tempo entre 2 backups em FULL RRS feed

  • Pergunta

  • Boa tarde a todos,

    Devido a uma execução mal sucedida de um processo crítico no sistema, dados importantes foram apagados em um banco de dados e precisamos recuperá-los.

    A política de backups é resumida a backups full diários. O banco sempre esteve com RECOVERY = FULL. Tenho os backups de um dia antes e um dia depois do incidente e gostaria de, usando estes 2 backups de que disponho, restaurar o banco para um horário entre esses 2 dias.  

    Obs.: Não realizavamos até então o backup dos log's de transação :-(

    Por enquanto, o que tentei foi:

    RESTORE DATABASE TESTE

    FROM DISK = 'C:\BACKUP_1.bak'
    WITH REPLACE, PASSWORD = 'XXX', MOVE 'BANCO' TO 'C:\TESTE.MDF', MOVE 'BANCO_LOG' TO 'C:\TESTE_LOG.LDF', NORECOVERY

    RESTORE DATABASE TESTE
    FROM DISK = 'C:\BACKUP_2.bak'
    WITH PASSWORD = 'XXX', STOPAT = '2012-08-11 10:50:00.000', NORECOVERY

    RESTORE DATABASE TESTE WITH RECOVERY

    A execução ocorre sem erros, mas o comando STOPAT parece não funcionar e ser ignorado, pois os dados no banco restaurado correspondem aos dados do BACKUP_2.

    Por favor, alguém poderia me ajudar??


    PHB

    • Editado PabloHB segunda-feira, 13 de agosto de 2012 17:39
    • Movido Gustavo Maia Aguiar terça-feira, 14 de agosto de 2012 12:37 (De:SQL Server - Desenvolvimento Geral)
    segunda-feira, 13 de agosto de 2012 17:36

Respostas

  • Bom Dia,

    "Posso estar enganado, mas após executar um backup de transaction log, o mesmo é truncado, "liberando" o início do arquivo para que ele seja re-aproveitado."

    Essa informação está correta, mas a forma como está escrita provoca um duplo sentido e uma sensação de que o backup de log não poderá ser utilizado (o que felizmente não é verdade). Ocorre que ao fazer um backup de log, as entradas de log que foram backupeadas são retiradas do arquivo LDF para que ele possa ser reaproveitado, mas não há perda, pois, essas entradas foram backupeadas e podem ser utilizadas na restauração.

    Existe uma grande chance de recuperação no seu cenário, mas há um pequeno detalhe que pode atrapalhar. Veja que se você usa o Recovery Model FULL e não faz backup de log, o seu log irá encher. Se no momento em que ele enche, você costuma truncá-lo (seja com o comando BACKUP LOG WITH TRUNCATE_ONLY ou mudando o Recovery Model para SIMPLE), você está descartando o log e aí não teremos como recuperá-lo.

    Se você truncou o log, ainda temos chance. O importante é que após o último full antes do incidente, ninguém tenha truncado o log, pois, se alguém o fez, aí não teremos mais como recuperar os dados. Caso ninguém tenha truncado o log após o último full antes do incidente, então está fácil de resolver. Basta tirar um backup de log (pode ir sem medo), restaurar o último full antes do incidente e usar esse backup de log com a opção STOPAT. Sugiro restaurar em outro local (leia-se outra instância) para evitar acidentes.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    • Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 14 de agosto de 2012 12:36
    • Marcado como Resposta PabloHB quarta-feira, 15 de agosto de 2012 20:55
    terça-feira, 14 de agosto de 2012 12:36

Todas as Respostas

  • Pablo,

    AFAIK, o backup full não te permite restaurar em um determinado momento. Para isso, você precisa restaurar os logs de transação, que é onde o STOPAT vai ser utilizado.

    Como você não tem os logs de transação, não terá como restaurar em um determinado momento... você terá que restaurar e tratar os dados conforme você necessite.

    Recomendo, após realizar todos os tratamentos, realizar um backup full do banco e implementar uma política de backup com diferenciais e logs de transação.

    Espero ter ajudado.

    []'s

    segunda-feira, 13 de agosto de 2012 18:31
  • Executei o programa versão trial ApexSQL LOG no banco e consegui visualizar parte dos dados de que necessito. O Apex fez a leitura do próprio banco (que se encontra íntegro). Acredito então que todos os dados estejam no arquivo .LDF. Acredito que através do Apex não vou conseguir recuperar devido as suas limitações de trial e ao seu alto custo.

    Mas agora surgiu então uma nova dúvida: Se os dados estão no .LDF (como pude comprovar pelo Apex), eu não poderia realizar um backup dos logs de transação agora E realizar uma restauração utilizando o log recém criado no ponto onde preciso?


    PHB

    segunda-feira, 13 de agosto de 2012 18:39
  • Pablo,

    Posso estar enganado, mas após executar um backup de transaction log, o mesmo é truncado, "liberando" o início do arquivo para que ele seja re-aproveitado.

    Ou seja, mesmo assim, não haveria como fazer a restauração conforme você espera.

    Espero ter ajudado.

    []'s

    segunda-feira, 13 de agosto de 2012 19:17
  • É que na verdade, neste banco ainda não realizei NENHUM backup de log. Este seria o primeiro. Meu medo agora é fazer um backup de log e estragar alguma coisa.

    PHB

    segunda-feira, 13 de agosto de 2012 19:19
  • Bom Dia,

    "Posso estar enganado, mas após executar um backup de transaction log, o mesmo é truncado, "liberando" o início do arquivo para que ele seja re-aproveitado."

    Essa informação está correta, mas a forma como está escrita provoca um duplo sentido e uma sensação de que o backup de log não poderá ser utilizado (o que felizmente não é verdade). Ocorre que ao fazer um backup de log, as entradas de log que foram backupeadas são retiradas do arquivo LDF para que ele possa ser reaproveitado, mas não há perda, pois, essas entradas foram backupeadas e podem ser utilizadas na restauração.

    Existe uma grande chance de recuperação no seu cenário, mas há um pequeno detalhe que pode atrapalhar. Veja que se você usa o Recovery Model FULL e não faz backup de log, o seu log irá encher. Se no momento em que ele enche, você costuma truncá-lo (seja com o comando BACKUP LOG WITH TRUNCATE_ONLY ou mudando o Recovery Model para SIMPLE), você está descartando o log e aí não teremos como recuperá-lo.

    Se você truncou o log, ainda temos chance. O importante é que após o último full antes do incidente, ninguém tenha truncado o log, pois, se alguém o fez, aí não teremos mais como recuperar os dados. Caso ninguém tenha truncado o log após o último full antes do incidente, então está fácil de resolver. Basta tirar um backup de log (pode ir sem medo), restaurar o último full antes do incidente e usar esse backup de log com a opção STOPAT. Sugiro restaurar em outro local (leia-se outra instância) para evitar acidentes.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    • Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 14 de agosto de 2012 12:36
    • Marcado como Resposta PabloHB quarta-feira, 15 de agosto de 2012 20:55
    terça-feira, 14 de agosto de 2012 12:36
  • Oi Gustavo,

    Acabei de tentar sua sugestão mas não consegui restaurar. Apesar de nunca ter feito nenhum backup de log e nenhum truncamento de log, o backup de log foi criado com apenas 1mb e não restaurou no momento que precisei. Primeiro voltei o último full anterior ao incidente e então o backup de log com STOPAT.

    Os backups full diários são executados com as opções WITH FORMAT, CHECKSUM, STOP_ON_ERROR, COPY_ONLY, PASSWORD = 'XXX'. Isso pode ter afetado minha recuperação?

    O backup de log que executei foi: BACKUP LOG 'BANCO' TO DISK = 'C:\BANCO_LOG.TRN'

    Fiz uma cópia dos arquivos .MDF e .LDF assim que descobri o problema e mantenho eles intactos. Caso eu tenha feito algum procedimento errado de recuperação, ainda posso utilizar os arquivos originais.

    Visto este procedimento, o que eu fiz de errado? O log pode ter sido truncado após um outro backup full realizado após o incidente?


    PHB

    terça-feira, 14 de agosto de 2012 13:40
  • Boa Noite,

    Se o backup de log tem apenas 1MB, há algo errado. Possivelmente ele foi truncado. Você pode verificar no ErrorLog. O truncamento pode acontecer em virtude do comando BACKUP LOG (com a opção TRUNCATE ONLY) ou pela mudança do RECOVERY MODEL de FULL para SIMPLE.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    quarta-feira, 15 de agosto de 2012 03:24