Procedimentos de backup e restauração offline para o Exchange

Traduções deste artigo Traduções deste artigo
ID do artigo: 296788 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo descreve métodos que podem ser usados para ignorar as APIs (Interfaces de Programação de Aplicativo) de backup online, fazer o backup manualmente e restaurar os bancos de dados de armazenamento das informações do Exchange. Se você tiver vários grupos de armazenamento em um único servidor do Exchange, cada um deles deve ser considerado uma unidade independente, de conteúdo próprio, levando em conta os objetivos do backup e da restauração offline.Para obter informações adicionais sobre os backups instantâneo e offline, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft:
296787 XADM: Procedimentos de restauração e backup offline para o Exchange Server 4.0, 5.0 e 5.5

Mais Informações

Antes de Começar

Antes de fazer um backup offline, veja se você possui as seguintes informações:
  • Verifique se o registro em log circular está ou não ativado para o grupo de armazenamento. (Por padrão, essa opção fica desativada no Exchange.) Para determinar se o registro em log circular está ou não ativado, abra as propriedades do objeto storage_group no Exchange System Manager, e observe a página General. Para desativar o registro em log circular, desmarque a caixa de seleção Circular Logging. As alterações feitas no registro em log circular não têm efeito até que você interrompa todos os bancos de dados no grupo de armazenamento.

    Você não precisa desativar o registro em log circular para fazer backups offline. No entanto, você deve desativar o registro em log circular, caso queira copiar os logs de transação nos backups offline restaurados.
  • Defina os locais de caminho para o seu banco de dados do Exchange, o fluxo, o log de transação e os arquivos de verificação, além do arquivo de log para o grupo de armazenamento.

    Para localizar essas informações, abra as propriedades do objeto storage_group no Exchange System Manager, e observe a página General. Guarde os valores para as três caixas a seguir:
    • Log File Prefix (E0n, em que E0n pode ser E00, E01, E02 ou E03)
    • Transaction Log Location (E0n*.log)
    • System Path Location (E0n.chk)
    Os caminhos de banco de dados estão listados nas propriedades Database de cada objeto database_name objeto. Guarde os valores referentes aos dois campos a seguir para cada banco de dados no grupo de armazenamento:
    • Exchange Database (.edb)
    • Exchange Streaming Database (.stm)
Se o Exchange System Manager não estiver disponível, você poderá encontrar todas as informações anteriores, lendo os atributos não-processados diretamente a partir do Active Directory usando uma ferramenta como ADSIEDIT ou LDIFDE. Você pode usar o seguinte comando LDIFDE para conseguir as informações referentes a todos os servidores Exchange em uma floresta Active Directory.

OBSERVAÇÃO: O texto para este comando está disposto da seguinte maneira para facilitar a leitura.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=configuration_container_domain,DC=top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Este é um exemplo da saída do comando anterior:
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Connecting to "dc1.child.test.com"
Fazendo o logon como usuário atual usando SSPI
Exporting directory to file con
Searching for entries...

<output truncated>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
alterar_tipo: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
alterar_tipo: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
alterar_tipo: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Para conseguir copiar os logs de transação, você deverá restaurar os arquivos de banco de dados (.edb e .stm) para os mesmos locais de caminho a partir dos quais foi feito o backup dos arquivos. Por exemplo, se tiver feito o backup do arquivo de banco de dados a partir da pasta E:\Mdbdata e do arquivo de banco de dados do fluxo a partir da pasta F:\Mdbdata, você deve restaurar os arquivos para E:\Mdbdata e F:\Mdbdata, respectivamente. Essa limitação se aplica mesmo que você queira restaurar o banco de dados para um servidor completamente diferente (por exemplo, em uma situação de recuperação de uma única caixa de correio).

Se alterar o caminho de um banco de dados após o backup mais recente, você só poderá copiar os logs de transação parcialmente, podendo conseguir uma cópia parcial apenas se alterar o caminho para o local original. Se reverter para o caminho antigo, você poderá copiar os logs criados até o momento em que o caminho foi alterado.

Você pode restaurar os arquivos de log de transação (E0n*.log) para um caminho diferente do local de backup original. Isso acontece porque os logs de transação registram os locais dos bancos de dados aos quais estão vinculados, mas os bancos de dados não registram os locais dos logs de transação. Durante a cópia, os logs "encontram" os bancos de dados usando as informações referentes ao caminho armazenadas nos cabeçalhos do log de transação. (A API de backup online se adapta às alterações no caminho do banco de dados e, por isso, essa limitação não se aplica.)

Você não faz o backup ou restaura o arquivo de verificação (E0n.chk), mas deve saber o seu local atual porque pode precisar analisá-lo ou excluí-lo durante a recuperação.

Como os arquivos de banco de dados do Exchange se relacionam uns com os outros

Os arquivos .edb e .stm são os repositórios finais para todas as informações do banco de dados. Considerando a maioria dos objetivos, trate esses dois arquivos como se eles fossem apenas um; faça o backup e restaure esses arquivos juntos. Esses arquivos devem estar cronologicamente sincronizados; um arquivo .edb cujo backup foi feito em um determinado dia não pode ser compatível com um arquivo de fluxo cujo backup foi feito em outro dia.

Um servidor do Exchange 2000 ou do Exchange 2003 pode oferecer suporte até quatro grupos de armazenamento, sendo que cada um deles pode oferecer suporte a até cinco bancos de dados. Um grupo de armazenamento é um conjunto de bancos de dados que compartilham um mesmo conjunto de arquivos de log de transação. O Microsoft Exchange Server 5.5 pode oferecer suporte a até um grupo de armazenamento que, por sua vez, pode oferecer suporte a até dois bancos de dados (os armazenamentos de informações particulares e públicas).

Na medida em que são feitas alterações no banco de dados, elas são gravadas primeiro no arquivo de log de transação e, em seguida, em um cache na memória. Assim que as alterações estiverem no cache, elas se tornam visíveis aos usuários. As páginas no cache são liberadas para o arquivo do banco de dados, quando isso for necessário. A verificação marca o ponto na seqüência de arquivos de log até onde todas as transações foram fisicamente liberadas para o arquivo do banco de dados. É normal a verificação deixar um espaço de três ou mais arquivos de log entre o arquivo de log atual e o que está sendo passado.

Para evitar confusão a respeito de quais arquivos de log pertencem a qual grupo de armazenamento, os logs do Exchange que pertencem a um determinado grupo recebem um prefixo de log único: os três primeiros caracteres do nome do arquivo. Os prefixos de log válidos para os quatro grupos de armazenamento suportados em um servidor do Exchange 2000 ou do Exchange 2003 são E00, E01, E02 e E03. Durante este artigo, o prefixo de log para um grupo de armazenamento é chamado de E0n. O arquivo de log atual para um grupo de armazenamento é sempre E0n.log.

Os logs de transação têm um tamanho padrão de 5 MBs (megabytes). Quando estiver cheio, o arquivo de log atual é renomeado com um número de seqüência hexadecimal (chamado de número de geração de log), e um novo arquivo de log atual é gerado. Os arquivos de log são numerados como E0n00001.log, E0n00002.log e assim por diante. Durante este artigo, os arquivos de log numerados são chamados genericamente de E0nxxxxx.log.

Se um banco de dados for interrompido de forma anormal, o arquivo de verificação (E0n.chk) registra o log de transação a partir do qual a recuperação deve copiar para restaurar a consistência do banco de dados. Esse processo é chamado de "recuperação simples". A recuperação simples pode ser comparada à "recuperação complexa", que é o processo pelo qual os arquivos de log são copiados após a restauração de um backup online. A diferença mais importante entre as duas recuperações é a interpolação de dados do arquivo de caminho no processo de cópia do arquivo de log durante a recuperação complexa.

Um arquivo de banco de dados do Exchange inconsistente é aquele que ainda não recebeu os registros de todas as grandes transações. Durante a operação normal, os arquivos de banco de dados do Exchange são inconsistentes porque há, no cache, informações que ainda não foram gravadas no arquivo. Em geral, um arquivo de banco de dados do Exchange pode ser considerado consistente somente após o desligamento normal do serviço de banco de dados. No entanto, o banco de dados, visto de forma geral (considerado a soma das informações tanto nos logs de transação quanto nos arquivos de banco de dados), é sempre consistente ? a menos que os arquivos de log necessários sejam excluídos prematuramente.

Como fazer backup de um banco de dados do Exchange offline

Para fazer backup de um banco de dados do Exchange offline:
  1. Desmonte o banco de dados para o qual você deseja fazer o backup. Você não precisa desmontar todos os bancos de dados no grupo de armazenamento, mas apenas o(s) banco(s) de dados para o(s) qual(is) deseja fazer o backup.
  2. Veja se os arquivos de banco de dados (tanto .edb quanto .stm) são consistentes e estão relacionados. Para fazer isso, execute o seguinte comando em relação a cada arquivo:
    eseutil /mh database file | find /i "DB Signature"
    OBSERVAÇÃO: O Exchange 2000 Service Pack 2 e posteriores não relatam o estado do banco de dados como "Consistent" ou "Inconsistent" e sim, como "Clean Shutdown" ou "Dirty Shutdown". O significado de "Clean Shutdown" é o mesmo de "Consistent", assim como também é "Dirty Shutdown" em relação a "Inconsistent". Para o Exchange 2000 Service Pack 2 ou posteriores, execute este comando adicional para determinar o estado de cada banco de dados:
    eseutil /mh database_name | find /i "Shutdown"
    Veja a seguir um exemplo da saída do comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    No exemplo anterior, as assinaturas DB são as mesmas, o que comprova que os arquivos .edb e .stm pertencem ao mesmo conjunto. (Para que haja uma correspondência de assinatura, ambas as linhas de assinatura devem ser idênticas no que se refere a cada caractere.)

    Não apenas as assinaturas DB devem corresponder, mas também os arquivos devem estar sincronizados e consistentes. Execute o seguinte comando em cada arquivo:
    eseutil /mh database file | find /i "consistent"
    Veja a seguir um exemplo da saída do comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    No exemplo anterior, ambos os arquivos relatam "State: Consistent." Os números hexadecimais entre parênteses referentes a cada arquivo (0x2CC7,1F14,1F7) também devem corresponder. Já o carimbo de data/hora Last Consistent não precisa corresponder. Esses arquivos são consistentes e correspondentes.

    Se algum dos arquivos relatasse "State: Inconsistent" ou as posições de log Last Consistent não estivessem sincronizadas, o banco de dados não teria sido desmontado corretamente. Monte e desmonte o banco de dados novamente. Se ainda assim os arquivos não corresponderem ou forem inconsistentes, entre em contato com o Atendimento Microsoft para obter ajuda adicional.
  3. Copie cada um dos arquivos de banco de dados .edb e seus arquivos de fluxo .stm correspondentes para um local de backup.
  4. Monte os bancos de dados para os quais foram feitos backups.
  5. Se o registro em log circular estiver ativado, ignore essa etapa. Se ele estiver desativado, e você quiser "adiar" mais tarde, é necessário fazer o backup de todos os arquivos de log de transação numerados (os arquivos E0nxxxxx.log). Não faça backup dos arquivos E0n.log, Res1.log e Res2.log.

    Você pode fazer o backup dos arquivos de log numerados a qualquer momento, mesmo após a sua criação, porque depois que um arquivo de log é renomeado de E0n.log para E0nxxxxx.log, o Exchange não altera esse arquivo novamente. Porém, exclua somente arquivos de log com backup de acordo com as instruções descritas na etapa 6.

    Seus backups de arquivo de log não têm uma correspondência direta com os backups do seu banco de dados. Cada backup de arquivo de log é um vínculo em uma cadeia de arquivos de log que podem ser reproduzidos em qualquer um dos vários backups de banco de dados. Você pode adiar isso a partir de um determinado backup de banco de dados, desde que tenha um fluxo completo de logs começando com o log listado na linha "Last Consistent" do cabeçalho do banco de dados. Neste artigo, o log consistente mais recente é chamado de "low anchor log".

    Se você observar o exemplo anterior, a entrada consistente mais recente é (0x2CC7,1F14,1F7). Os três números definem um arquivo de log, uma página nesse arquivo e um deslocamento de byte nessa página. Cada arquivo de log contém aproximadamente 10.000 páginas com 512 bytes cada. O deslocamento de página lhe dá uma boa idéia de como o arquivo de log está próximo de ficar cheio (o arquivo de log no exemplo anterior está cerca de 80 por cento cheio, porque 0x1F14 é o equivalente decimal a 7956), embora seja irrelevante na recuperação. A recuperação sempre começa no início de um arquivo de log.

    Neste exemplo, o arquivo de log low anchor é E0n02cc7.log.

    Talvez nem sempre você consiga ver o log consistente mais recente no disco como um log numerado, porque ele ainda pode estar nomeado como E0n.log. Você pode ver que o número da seqüência E0n.log será fornecido examinando o cabeçalho do arquivo de log enquanto o banco de dado permanece interrompido (o acesso é negado ao cabeçalho E0n.log enquanto o banco de dados estiver sendo executado).

    Para visualizar o número de geração de log interno, execute o seguinte comando:
    eseutil /ml [log file] | find /i "lGeneration"
    Veja a seguir um exemplo da saída do comando anterior:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Em muitas circunstâncias, é mais importante ter certeza de que os backups do seu arquivo de log sejam bons do que saber se o backup do banco de dados é bom. Isso porque cada backup do banco de dados pode oferecer redundância para os outros, mas a recuperação completa feita a partir de qualquer backup de banco de dados depende da preservação de cada um e do arquivo de log posterior ao backup.
  6. Ignore essa etapa caso o registro em log circular esteja ativado. Analise o cabeçalho do arquivo de verificação para determinar o arquivo de log numerado máximo que pode ser removido com segurança. A verificação controla o arquivo de log numerado mínimo necessário à recuperação automática no caso do banco de dados ser interrompido de forma anormal. Para analisar o arquivo de verificação, execute o seguinte comando:
    eseutil /mk E0n.chk
    Veja a seguir um exemplo da saída do comando anterior:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    A terceira linha, Checkpoint, contém as informações relevantes (a entrada LastFullBackupCheckpoint é usada pelo backup online, e permanece com todos os zeros no caso de um backup online nunca ter sido realizado no banco de dados). O formato da posição do log Checkpoint é o mesmo da entrada consistente mais recente no cabeçalho do banco de dados. Neste exemplo, a verificação está em E0002cc7.log.

    Se o registro em log circular estiver desativado, os arquivos de log se acumulam até que sejam manualmente excluídos ou removidos automaticamente pelo processo de backup online. Se essa opção estiver ativada, não é necessário nenhum tipo de gerenciamento especial dos arquivos de log antigos, uma vez que o serviço de banco de dados excluir os arquivos de log mais antigos depois que a verificação passar por eles.

    Depois de fazer o backup de todos os arquivos de log numerados, você poderá recuperar espaço em disco removendo todos os arquivos de log numerados até, mas sem incluir, o log de verificação.

    IMPORTANTE: Não remova o log de verificação.

    Neste exemplo, você pode remover todos os logs até E0002cc6.log.
  7. Esta etapa é opcional. Você pode usar o utilitário Esefile para verificar a integridade das cópias dos bancos de dados no que se refere à página.

    O arquivo Esefile.exe está disponível na pasta Support do CD-ROM do Exchange Server 5.5 Service Pack 3, no CD-ROM de instalação do Exchange 2000 Server ou no CD-ROM de instalação do Exchange Server 2003. Você também pode obter o arquivo Esefile.exe com o Atendimento Microsoft. O utilitário Esefile funciona com arquivos .edb do Exchange Server 5.0 e 5.5, Exchange 2000 e Exchange 2003.

    Atualmente, não há um método que não seja o backup online para examinar as somas de verificação de cada página de um arquivo .stm. O arquivo .stm contém dados não-processados. Todos os índices e ponteiros que organizam esses dados estão no arquivo .edb. Um problema no arquivo .stm causa algumas perdas de dados para determinados clientes, mas não compromete a integridade estrutural ou lógica do banco de dados como um todo.

    Para verificar as somas de verificação da página para um banco de dados do Exchange, execute o seguinte comando do utilitário Esefile:
    esefile /sdatabase_name
    Veja a seguir um exemplo da saída do comando anterior:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    São aceitáveis páginas não-inicializadas, mas em um banco de dados sem problemas, há 0 somas de verificação inválidas e 0 números de página errados.

    Se um banco de dados não passar pelo teste de integridade do utilitário Esefile, o melhor a fazer é restaurar um backup anterior (o qual, sabe-se que está bom) e adiar o banco de dados. Se não houver um backup como esse disponível, consulte o Atendimento Microsoft para saber como reparar ou recuperar o banco de dados.
  8. Esta etapa é opcional. Você pode usar o seguinte comando para verificar a integridade dos arquivos de log para os quais foram feitos backups:
    eseutil /ml E0n
    Veja a seguir um exemplo da saída do comando anterior:
    k:\backups>eseutil /ml E00
    							
    Você deve executar esse comando a partir de uma pasta que contenha os arquivos de log com backup. Você também pode executar esse comando na pasta de log em execução atual, mas se Eseutil tentar ler o cabeçalho de E0n.log enquanto houver algum banco de dados no grupo de armazenamento em execução, você recebe um erro -1032 (JET_errFileAccessDenied).

    Esse comando detecta corrupção nos arquivos de log, além de avisar se está faltando algum no meio de uma seqüência, ou se não há uma correspondência entre algum dos arquivos de log.

Como restaurar um backup offline de um banco de dados do Exchange

Esta seção descreve dois métodos para restaurar um backup offline:
  • Restauração "Point in time". Não é copiado nenhum arquivo de log para o banco de dados. Todos os dados criados após o backup são perdidos.
  • Restauração "Roll forward". Os arquivos de log que foram criados após o backup são copiados para o banco de dados. Se todos os arquivos de log estiverem disponíveis, todos os dados criados após o backup podem ser preservados. Se o registro em log circular estiver ativado, você deve fazer uma restauração "point in time" do seu backup offline; você não pode optar por uma restauração "roll forward".
O conjunto de arquivos restaurados por você devem atender aos seguintes critérios mínimos:
  • Para restaurações point in time, todos os bancos de dados interrompidos no grupo de armazenamento devem ser consistentes e deve haver um arquivo de verificação válido. Não exclua o arquivo de verificação atual ou qualquer um dos arquivos de log existentes.
  • Para restauração roll forward, todos os bancos de dados no grupo de armazenamento devem ser interrompidos e consistentes, devendo haver todos os arquivos de log criados após o backup ter sido feito (incluindo o E0n.log atual). O arquivo de verificação deve ser excluído.
Se o conjunto de arquivos não atender às condições anteriores, talvez a restauração e a cópia não falhem, mas você receba uma mensagem de erro -1216 (JET_errAttachedDatabaseMismatch) durante a recuperação simples.

Como Lidar com um Erro 1216

Proteções de recuperação simples adicionais no Exchange 2000 e mais recentes causam o erro -1216 quando o Exchange detecta os arquivos de dados que foram alterados manualmente e determina que a recuperação em execução com o conjunto atual de dados resultaria na perda dos dados existentes.

Em versões mais antigas do Exchange, se o conjunto de arquivos estiver incompleto, mas for válido para uma cópia, a recuperação simples começa sem que sejam exibidos avisos ao administrador. No Exchange 2000 e mais recentes, o administrador deve estender o erro -1216 usando o Eseutil.

Como indicar o momento da restauração de um Backup offline

Para fazer uma restauração point in time de um backup offline:
  1. Se o banco de dados que você deseja restaurar estiver montado no momento, desmonte-o. Se houver algum outro banco de dados desmontado no grupo de armazenamento, os arquivos desse banco de dados e de fluxo (.edb e .stm) devem ser consistentes e correspondentes. (Para verificar a consistência e a correspondência, veja a etapa 2 na seção "Como fazer backup de um banco de dados do Exchange offline" deste artigo.)

    Se todos os bancos de dados no grupo de armazenamento estiverem desmontados, todos eles devem ser consistentes e ter um arquivo de verificação válido. Arquivo de verificação válido é um arquivo que estava sendo usado na última vez em que havia algum banco de dados no grupo de armazenamento em execução e que tem um cabeçalho indicando E0n.log como a verificação. Se algum banco de dados no grupo de armazenamento ainda estiver montado, o arquivo de verificação válido é o que está sendo atualmente usado pelo sistema. Se houver algum banco de dados em execução no grupo de armazenamento, é sinal de que há uma verificação válida.

    Para analisar o arquivo de verificação quando todos os bancos de dados estiverem interrompidos, execute os seguintes comandos:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Veja a seguir um exemplo da saída dos comandos anteriores:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    No exemplo anterior, a verificação está no log com a lGeneration de 0x2cc7, que é e00.log. Por isso, a verificação pode ser considerada válida.

    Se a verificação for inválida, você deve receber uma mensagem de erro -1216 (JET_errAttachedDatabaseMismatch) ao tentar montar qualquer banco de dados no grupo de armazenamento. Esse problema pode ocorrer se todos os bancos de dados contidos no grupo de armazenamento forem consistentes.
  2. Copie os arquivos .edb e .stm para os quais você fez backup nos locais do banco de dados e do arquivo de fluxo. (Para encontrar esses locais, consulte a seção "Antes de Começar" deste artigo). Veja se os arquivos restaurados são consistentes e correspondentes.

    OBSERVAÇÃO: Se já houver cópias dos arquivos de bancos de dados que você deseja restaurar no servidor, faça o backup desses arquivos antes de restaurar o banco de dados, mesmo que os arquivos existentes não possam ser iniciados. Eles podem ser reparados, e talvez você possa recuperar dados a partir deles usando o utilitário Exmerge.
  3. Monte o banco de dados restaurado. O banco de dados se anexa ao fim do arquivo E0n.log. Depois que o banco de dados for iniciado corretamente, nenhum arquivo de log anteriormente existente poderá ser copiado para o banco de dados. Bancos de dados de pasta pública que contêm milhares de pastas na hierarquia podem demorar um pouco para iniciar. Deixe, pelo menos, um minuto para cada 1.000 pastas na hierarquia.

    Em versões mais antigas do Exchange Server, você normalmente precisa executar o comando ISINTEG -patch após restaurar um backup offline de um banco de dados de informações para sincronizar o banco de dados que contém as informações com o diretório. Quando é necessário um patch para um banco de dados do Exchange, esse patch é feito automaticamente pelo sistema, a menos que o banco de dados seja restaurado para um outro servidor, um grupo de armazenamento ou um objeto de banco de dados lógico, ou o objeto do Active Directory referente ao banco de dados tenha sido excluído e criado novamente no Active Directory. Nesses casos, a seguinte mensagem de erro é registrada no log de eventos do aplicativo.
    Tipo de evento: Error
    Fonte: MSExchangeIS Mailbox Store
    Categoria: Geral
    Identificação do evento: 1087
    Data: 5/4/2001
    Hora: 20:33:42
    Usuário: N/A
    Computador: EXCHANGE1
    Descrição: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    Para resolver esse problema, você deve marcar a caixa de seleção This database can be overwritten by a restore no Exchange System Manager, nas propriedades Database do objeto de banco de dados.

Como adiar a restauração de um Backup offline

Para ter mais chances de obter sucesso ao copiar arquivos de log para um banco de dados restaurado:
  • Mantenha uma cópia de todos os logs de transação criados após o backup completo mais recente.
  • Não altere o caminho de um banco de dados sem fazer um novo backup completo depois disso.
  • Não execute ESEUTIL /p ou ESEUTIL /d sem fazer um novo backup completo logo depois disso.
  • Não adicione ou remova um banco de dados em um grupo de armazenamento sem fazer um backup completo de todos os bancos de dados contidos nesse grupo imediatamente.
Para iniciar o processo de restauração:
  1. Se o banco de dados que você deseja restaurar estiver montado, desmonte-o e copie os arquivos do banco de dados que você deseja restaurar para os caminhos apropriados no servidor. Se já houver cópias dos arquivos de bancos de dados que você deseja restaurar no servidor, faça o backup dessas cópias antes de restaurar o banco de dados, mesmo que os arquivos existentes não possam ser iniciados. Os arquivos podem ser reparados, e talvez você possa usar o utilitário Exmerge para recuperar os seus dados.
  2. Desmonte todos os bancos de dados no grupo de armazenamento, e execute o seguinte comando em cada um deles e, em seguida, em cada arquivo do banco de dados restaurado:
    eseutil /mh database_file_name | find /i "consistent"
    OBSERVAÇÃO: O Exchange 2000 Service Pack 2 e mais recentes não relatam o estado do banco de dados como "Consistent" ou "Inconsistent", e sim como "Clean Shutdown" ou "Dirty Shutdown". O significado de "Clean Shutdown" é o mesmo de "Consistent", assim como também é "Dirty Shutdown" em relação a "Inconsistent". Para o Exchange 2000 Service Pack 2 ou mais recentes, execute este comando adicional para determinar o estado de cada banco de dados:
    eseutil /mh database_name | find /i "Shutdown"
    Veja a seguir um exemplo da saída do comando anterior:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Esse comando tem três objetivos:
    • Verificar se os arquivos do banco de dados são consistentes.
    • Verificar se os arquivos .edb e .stm de cada banco de dados são correspondentes.
    • Identificar os arquivos de log low e high anchor, que são o primeiro e o último arquivos de log necessários à recuperação de todos os dados sem que seja gerado um erro -1216. O menor e mais recente valor consistente em todos os bancos de dados é o low anchor log, enquanto o maior e mais recente valor é o high anchor log.
    No exemplo anterior, o arquivo de log low anchor é E0002ac8.log e o arquivo de log high anchor, E0002cc7.log.
  3. Veja se a assinatura de log registrada no cabeçalho de cada banco de dados é a assinatura do log low anchor. Execute os seguintes comandos:
    eseutil /mhdatabase_name | find /i "Log Signature"
    eseutil /mllow_anchor_log | find /i "Signature"
    Veja a seguir um exemplo da saída do comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:06:38:00 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:06:40:00 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Um arquivo de log pode indicar várias assinaturas. A primeira assinatura é sempre a própria assinatura do arquivo de log; o restante corresponde a bancos de dados em execução no momento em que o arquivo de log foi criado. No exemplo anterior, as assinaturas de log registradas nos arquivos do banco de dados não correspondem à assinatura de log no low anchor log.

    Se não conseguir localizar o low anchor log, você não pode executar os logs nesse banco de dados. Se não conseguir encontrar o arquivo de log low anchor, você não pode copiar nenhum arquivo de log para nenhum banco de dados. Você pode usar dois métodos para lidar com um low anchor log faltando:
    • Você pode remover todos os arquivos de log. Como os bancos de dados são todos consistentes, você poderá iniciá-los sem a presença de arquivos de log, mas perde a chance de recuperar os dados que ainda não estejam nos arquivos de bancos de dados.
    • Você pode remover os bancos de dados com os valores consistentes mais baixos e mais recentes até criar uma seqüência de logs ininterrupta de low para high anchors e fazer a recuperação nos demais bancos de dados. Ao colocar os bancos de dados removidos novamente no grupo de armazenamento, você não pode inserir dados adicionais neles.
  4. Veja se os locais de caminho do banco de dados atual são os mesmos de quando você fez o backup.

    Embora possa alterar o caminho do log de transação ou o caminho em funcionamento depois de fazer o backup, você só pode copiar o arquivo de log se os arquivos do banco de dados estiverem nos mesmos locais a partir dos quais foi feito o backup. Se não tiver certeza a respeito dos locais originais, execute o seguinte comando:
    eseutil /ml"Last_Consistent"_log | find /i "database name or pattern"
    Veja a seguir um exemplo da saída do comando anterior:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    OBSERVAÇÃO: Se o low anchor log for E0n00001.log, ele não terá as informações referentes ao caminho em seu cabeçalho porque o cabeçalho para o primeiro log de uma seqüência é gerado antes de primeiro banco de dados ser anexado ao log. Nesse caso, você deve procurar o próximo cabeçalho do log para visualizar as informações referentes ao caminho do banco de dados. Em casos raros, isso também pode acontecer com logs posteriores ao primeiro, porque um banco de dados foi criado ou anexado ao fluxo de log depois que o log foi criado.
  5. Reúna todos os logs, a partir do número low anchor mais distante na seqüência ininterrupta e copie esses logs para o caminho de logs de transação atual. Não sobrescreva os logs já existentes no servidor sem fazer o backup deles antes. Para fazer isso, talvez você precise restaurar os arquivos de log a partir de mais de um tipo de mídia de backup.

    No exemplo anterior, o log low anchor é E0002ac8.log e o high anchor, E0002cc7.log. Quando você analisa os logs disponíveis, o log numerado mais elevado que você pode encontrar talvez seja um número menor do que o necessário (por exemplo, E0002cc6.log, em vez de 2cc7). Isso normalmente ocorre porque o E0n.log ainda não foi completado e renomeado para o seu número na seqüência. Para determinar se E0n.log está realmente no high anchor log, você deve usar o seguinte comando para analisar o valor lGeneration no cabeçalho do arquivo de log:
    eseutil /ml E0n.log | find /i "lGeneration"
    Veja a seguir um exemplo da saída do comando anterior:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    OBSERVAÇÃO: Para visualizar o cabeçalho de um arquivo de log usando o utilitário Eseutil, use a opção /ml; para visualizar um cabeçalho de arquivo de banco de dados, use a opção /mh. Se você trocar as opções, a saída dos comandos ficará incorreta.

    Normalmente, o high anchor log também é o log mais elevado disponível, mas isso não acontece se:
    • Os arquivos de log tiverem sido destruídos por acidente.

      -ou-
    • Você estiver restaurando todos os bancos de dados de uma vez em um grupo de armazenamento.
    No primeiro caso, é provável que você encontre erros -1216 durante a recuperação; já no segundo caso, você pode copiar os arquivos de log, e mesmo colar o high anchor log, desde que eles mantenham a seqüência lGeneration.
  6. Veja se todos os logs compartilham a mesma assinatura de log e se estão em uma seqüência ininterrupta. Execute o seguinte comando:
    eseutil /ml E0n > filename.txt
    Veja a seguir um exemplo da saída do comando anterior:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft (R) Exchange Server(TM) Database Utilities
    Version 6,0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Esse comando Eseutil faz três coisas: verifica cada arquivo de log em busca de danos, relata qualquer lacuna na seqüência de arquivos e detecta correspondências entre assinaturas de log.

    Todas as assinaturas de log devem corresponder a todos os arquivos de log candidatos à cópia. Você deve remover os logs que não tenham assinaturas correspondentes antes da cópia começar.

    Nesse momento, depois de remover os arquivos que não passaram nos testes de verificação, os únicos arquivos de log de transação na pasta Transaction Logs são os que:
    • Estão em uma seqüência lGeneration ininterrupta, começando com o arquivo de log low anchor e indo até o último arquivo de log high anchor ? e, se possível, indo além disso.
    • Tenha assinaturas de log correspondentes.
  7. Se o high anchor log não estiver nomeado como E0n.log, renomeie-o.
  8. Remova o arquivo E0n.chk da pasta System Path.

    Na ausência de um arquivo de verificação, o Exchange Server começa a copiar os logs a partir do arquivo de log numerado mais baixo disponível na pasta Transaction Logs: o low anchor log. Se houver o arquivo E0n.chk, o Exchange Server começa a copiar na verificação registrada neste arquivo. Se E0n.chk apontar para o low anchor log antigo, a cópia falha para o conjunto de arquivos restaurados. Em muitos casos, se cometer um erro com o arquivo de verificação, você deve começar a restauração dos arquivos de banco de dados a partir do backup.
  9. Como uma última verificação antes de montar o grupo de armazenamento, veja se:
    • Todos os arquivos de bancos de dados estão em seus caminhos de execução.
    • Os únicos arquivos de log no caminho do log de transação em execução são os que começam a partir do low anchor log e continuam, pelo menos, até o high anchor log, com o log mais alto disponível chamado E0n.log.
    • Não há arquivo E0n.chk na pasta System Path.
    Agora você deve conseguir montar o grupo de armazenamento e começar a copiar os logs de transação com esse conjunto de arquivos. Mesmo depois da recuperação e da inicialização do banco de dados, todos os dados em todos os arquivos de log talvez não sejam efetivamente recuperados por conta dos problemas com a assinatura DB e com o caminho encontrados durante a cópia. A seção "Como lidar com a assinatura do banco de dados e erros de caminho" deste artigo fornece informações adicionais sobre esses problemas.
  10. Se o armazenamento de informações ainda não estiver em execução, inicie-o, e monte pelo menos um banco de dados no grupo de armazenamento. Isso faz com que seja executada a recuperação simples em todos os bancos de dados no grupo de armazenamento.

    Em versões mais antigas do Exchange Server, você normalmente precisava executar o comando ISINTEG -patch após restaurar um backup offline de um banco de dados de informações, para sincronizar o banco de dados que contém as informações com o diretório. Quando é necessário um patch para um banco de dados do Exchange, esse patch é feito automaticamente pelo sistema, a menos que o banco de dados seja restaurado para um outro servidor, um grupo de armazenamento ou um objeto de banco de dados lógico, ou o objeto do Active Directory referente ao banco de dados tenha sido excluído e criado novamente no Active Directory. Nesses casos, a seguinte mensagem de erro é registrada no log de eventos do aplicativo.
    Tipo de evento: Error
    Fonte: MSExchangeIS Mailbox Store
    Categoria: Geral
    Identificação do evento: 1087
    Data: 5/4/2001
    Hora: 20:33:42
    Usuário: N/A
    Computador: EXCHANGE1
    Descrição: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
    Para resolver esse problema, você deve marcar a caixa de seleção This database can be overwritten by a restore no Exchange System Manager, nas propriedades Database do objeto de banco de dados.
Verifique o log de eventos do aplicativo no Visualizador de eventos do Microsoft Windows NT em busca de possíveis erros ou anomalias ocorridas durante a inicialização do banco de dados. É exibido um evento 301 para cada arquivo de log copiado. Observe com cuidado os erros e avisos exibidos durante o processo de recuperação.

Como lidar com a assinatura do banco de dados e erros de caminho

Os bancos de dados, assim como os arquivos de log, têm as suas próprias assinaturas. No entanto, embora as assinaturas de log não mudem após a criação do arquivo E0n000001.log, as assinaturas de banco de dados mudam sempre que a topologia física do banco de dados é alterada, sem que essas alterações sejam monitoradas pelos arquivos de log. A desfragmentação offline ou o reparo de um banco de dados com Eseutil altera a assinatura DB. Após um evento como esse, o banco de dados pode ser anexado ao mesmo fluxo de log anterior, mas o banco de dados não aceita a cópia de transações que foram feitas enquanto o banco de dados tinha a sua assinatura anterior. Uma cópia anterior do banco de dados não aceita a cópia de transações feitas após ter ocorrido uma mudança na assinatura do banco de dados.

Como as assinaturas do banco de dados são redefinidas dessa forma, você não deve se esquecer de fazer backups completos do banco de dados logo após a desfragmentação ou o reparo de um banco de dados. Se você restaurar uma cópia do banco de dados com a assinatura anterior posteriormente, a cópia chega até o ponto da alteração da assinatura, mas você perde todas as alterações feitas até aquele ponto.

Se os caminhos do banco de dados forem alterados no meio de um fluxo de log, o efeito é similar ao da alteração das assinaturas: a cópia é interrompida no ponto da alteração. (A API de backup online oferece a facilidade de mapear os caminhos durante a recuperação novamente; por isso, a API de backup online pode copiar todos os logs, mesmo que um caminho tenha sido alterado desde a criação do backup.)

Como os problemas com a assinatura DB ou com o caminho DB são encontrados durante a cópia, esses problemas são relatados no log de eventos do aplicativo juntamente com os eventos de cópia 301 para cada arquivo de log. Os arquivos de log anteriores ao ponto do problema podem aparecer como executados, mas isso só acontece porque o mesmo aviso de não-correspondência não é registrado várias vezes. Em regra geral, a cópia para um determinado banco de dados é truncada a partir do ponto em que a primeira assinatura DB ou erro do caminho referente ao banco de dados é encontrada.

Propriedades

ID do artigo: 296788 - Última revisão: segunda-feira, 3 de dezembro de 2007 - Revisão: 4.6
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Palavras-chave: 
kberrmsg kbhowto kbproductlink KB296788

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com