Exchange 2010 dando um erro de backup (veja detalhes). Como faço para descobrir qual é o problema e como corrigi-lo?

2

O erro é:

eseutil (2860) JetDBUtilities - 3928: The log file \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy84\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0501047257\E000000B4E0.log is damaged, invalid, or inaccessible (error -501) and cannot be used. If this log file is required for recovery, a good copy of the log file will be needed for recovery to complete successfully.

O Exchange parece estar funcionando bem no momento.

Eu olhei esse erro para cima e parece que o arquivo de log especificado pode estar permanentemente corrompido (acho que isso é o que significa um erro-501). Infelizmente, uma boa versão desse arquivo de log é muito antiga para estar em nossos backups.

Existem várias sugestões na Internet para executar eseutil / mh para verificar o banco de dados e ver em que estado ele está e ver se esse arquivo de log é realmente necessário. Como isso tudo requer a desmontagem do banco de dados, estou procurando o melhor primeiro passo para evitar problemas, por exemplo, se o banco de dados não for remontado. Existe uma maneira, por exemplo, de fazer backup do e-mail de todos antes de desmontar o banco de dados, sem passar pela rota pst?

    
por Dominic Fitzpatrick 09.08.2011 / 17:12

1 resposta

2

Acabei de fazer uma experiência em uma VM para tentar imitar sua situação. Eu intencionalmente corrompeu um dos arquivos de log de transações e estou usando o Windows Server Backup como o aplicativo de backup. Tudo o que eu digo abaixo é baseado nesta experiência, mas a realidade não deve diferir muito.

Mesmo que você diga que está tudo funcionando bem no momento, você está muito certo em se preocupar com esse erro, e fazendo essa pergunta você pode ter acabado de salvar seu futuro de alguma tristeza e pânico.

Primeiro, algumas informações sobre por que você deveria se preocupar. Quando o Exchange conclui com êxito um backup, ele elimina (exclui) os logs de transação confirmada, portanto, se os backups estiverem falhando com essa mensagem, há uma boa chance de que os logs de transação não estejam sendo liberados e estejam sendo compilados. Se os registros de transações antigos não estão sendo liberados, infelizmente você tem uma bomba-relógio em suas mãos que pode explodir a qualquer momento (desculpe por soar tão dramático, mas na verdade é bem sério). Quando o volume que os logs de transações estiverem preenchidos for próximo da capacidade, os bancos de dados associados da caixa de correio serão desmontados até que haja espaço adequado para novos logs de transação. Dependendo da quantidade de logs de transação que você acumular, determinará quando os bancos de dados de sua caixa de correio serão desmontados devido à falta de espaço.

Você terá que desmontar o banco de dados para fazer o que eu sugiro, mas ele deve desmontar sem problema, e quando desmontei meu banco de dados, ele estava em um estado Clean Shutdown , o que é uma boa notícia.

Desmonte o banco de dados e faça uma verificação de integridade e execute eseutil /mh <edb file name> para garantir que o banco de dados esteja no estado Clean Shutdown . Em seguida, mova todos os arquivos *.log , exceto E00.log e E00tmp.log em algum lugar seguro (não os exclua, você precisará deles de volta se tudo for uniforme). Depois que todos forem movidos, monte o banco de dados novamente e tente fazer um backup completo do banco de dados o quanto antes (deve ser um backup completo, não um incremental). Esse processo funcionou na minha VM e, esperamos, deve resolver o seu problema.

Aviso: NÃO

por 10.08.2011 / 02:02