Backup de dados do Exchange Server 2003 e serviços de cópia de sombra de volume

O recurso de serviço de cópias de sombra de volume no Microsoft Windows Server 2003 pode ser usado para criar aplicativos que o backup e restaurar o Microsoft Exchange Server 2003. O serviço de cópias de sombra (VSS) Windows Volume fornece uma infra-estrutura que permite a programas de gerenciamento de armazenamento de terceiros, programas de negócios e provedores de hardware para cooperar na criação e gerenciamento de cópias de sombra. As soluções com base nessa infra-estrutura podem usar cópias de sombra (ou cópias espelhadas) para fazer backup e restaurar um ou mais bancos de dados Exchange Server 2003.

O serviço cópia de sombra de volume coordena a comunicação entre solicitadores (aplicativos de backup), gravadores (aplicativos nos serviços do Windows como o Exchange Server 2003 e SQL Server 2000) e provedores (sistema, software ou hardware componentes que criar as cópias de sombra). Para usar o recurso de serviço de cópias de sombra de volume para o backup do Exchange Server 2003, o programa de backup deve incluir um solicitante serviço cópia de sombra de volume ciente do Exchange Server 2003. Como o programa de backup agrupado com o Windows Server tem não tal solicitante, as organizações devem usar aplicativos de backup de terceiros.

Para ser compatível com o Exchange Server 2003, os aplicativos de backup VSS baseado devem seguir três requisitos básicos para garantir a integridade e a recuperação de backups de cópia de sombra. Se esses requisitos não são seguidos, o Microsoft Product Support Services (PSS) irá considerar a solução de backup para ser fora da estrutura VSS do Exchange e não será capaz de solucionar problemas de backup e restaurar problemas. Os clientes devem verificar com seus fornecedores de backup que o aplicativo de backup atende os requisitos de compatível com o Exchange listados neste artigo da Base de dados de Conhecimento. Detalhes dos requisitos de VSS do Exchange são apresentadas na seção "Mais informações" deste artigo.

Como com qualquer solução de terceiros, o fornecedor do aplicativo de backup é seu provedor de suporte primário para problemas de backup e recuperação. Atendimento Microsoft pode ajudar a diagnosticar ou analisar problemas com o banco de dados disponível e conjuntos de arquivo de log de transação. No entanto, Microsoft não solucionar problemas ou depurar produtos de terceiros. Assistência do Atendimento Microsoft está limitada a conselhos sobre como continuar melhor recuperar o banco de dados disponível e os arquivos de log de transações.

Para obter mais informações sobre como o VSS com base em soluções são suportadas pelo PSS, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

A lista a seguir descreve o backup do Exchange Server 2003 com o processo do serviço cópia de sombra de volume:

1. O programa de backup (ou agente) executa um trabalho agendado.
2. O serviço de cópia de sombra de volume solicitador no programa de backup envia um comando para o serviço cópia de sombra de volume para tirar uma cópia de sombra dos grupos de armazenamento do Exchange Server 2003 selecionados.
3. Serviço de cópias de sombra de volume se comunica com o gravador do Exchange Server 2003 para se preparar para um backup de instantâneo.
4. Serviço de cópias de sombra de volume se comunica com o provedor de armazenamento apropriado para criar uma cópia de sombra de volume de armazenamento ou os volumes de armazenamento que contêm o grupo de armazenamento do Exchange Server 2003 ou grupos de armazenamento.
5. Serviço de cópias de sombra de volume libera o Exchange Server 2003 para continuar a operações comuns.
6. O serviço de cópia de sombra de volume solicitante verifica a integridade do conjunto de backup anteriores ao Exchange de informando que o backup foi bem-sucedido.

Por exemplo, quando uma solicitação de cópia de sombra é recebida de um programa backup do Exchange Server 2003 que possui o serviço oferece suporte (um solicitante), cópia de sombra de volume serviço se comunica com o gravador do Exchange Server 2003 para preparar para instantâneo, neste ponto Exchange Server 2003 proíbe ações administrativas contra o grupo de armazenamento, verifica as dependências de volume e suspende todas escrever as operações de banco de dados e arquivos de log de transações permitindo acesso somente leitura. Serviço de cópias de sombra de volume, em seguida, se comunica com o provedor de armazenamento apropriado para iniciar o processo de cópia de sombra de volumes de disco que contêm os dados do Exchange Server 2003. A cópia de sombra normalmente leva alguns segundos, que serão praticamente imperceptível para o usuário final. Quando a cópia de sombra foi tomada, serviço de cópias de sombra de volume se comunica com o gravador do Exchange Server 2003 que o Exchange pode reiniciar operações comuns. Programa de backup verifica a integridade de cópia de sombra anteriores ao Exchange de informando que o backup foi bem-sucedido. No final de um Exchange de backup bem-sucedida trunca os logs e registra a hora do último backup do banco de dados ou bancos de dados.

Para obter mais informações sobre backup do Exchange Server 2003 com serviços de cópia de sombra de volume, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

A lista a seguir descreve os requisitos Exchange Server 2003 que os aplicativos de backup de cópia de sombra devem seguir para garantir a integridade e a capacidade de recuperação de bancos de dados do Exchange:

A lista abaixo fornece os logs de eventos aplicativos específicos que identificar se os requisitos do Exchange estão sendo seguidos. Aplicativos de backup e o servidor Exchange podem fazer outros eventos associados com o processo de backup e restauração. Confirmar que os seguintes eventos são registrados durante o backup e restauração servirá como a verificação de conformidade com requisitos de VSS do Exchange. Atualmente, não há nenhum programa de certificação para qualquer solução de software de terceiros em execução no Exchange. Conformidade garante a integridade e capacidade de recuperação de backups de cópia de sombra mas não oferece garantia no desempenho ou confiabilidade da solução de terceiros.

1. Banco de dados do Exchange, do log de transações e arquivos de ponto de verificação devem ser feitos exclusivamente por meio do gravador do Exchange:
   
   Os seguintes eventos do aplicativo serão registrados se o gravador do Exchange é iniciado durante backups de cópia de sombra.

   Tipo de evento: informações
   Origem do evento: ESE
   Categoria do evento: ShadowCopy
   IDENTIFICAÇÃO de evento: 2005
   Data: 17/6/2004
   Tempo: 11:40:41 AM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: A cópia de sombra de armazenamento de informações (2180) instância iniciando 3. Esse será um ? tipo de backup ? * cópia de sombra.

   * Onde ? tipo ? é o tipo de backup realizada (inteiro, cópia, incremental ou diferencial).

   Tipo de evento: informações
   Origem do evento: MSExchangeIS
   Categoria do evento: O gravador VSS do Exchange
   IDENTIFICAÇÃO de evento: 9608
   Data: 17/6/2004
   Tempo: 11:40:42 AM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: O instantâneo VSS do Exchange foi preparado para instantâneo com êxito.

   Tipo de evento: informações
   Origem do evento: MSExchangeIS
   Categoria do evento: O gravador VSS do Exchange
   IDENTIFICAÇÃO de evento: 9610
   Data: 17/6/2004
   Tempo: 11:40:43 AM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: Instantâneo VSS do Exchange congelou os grupos de armazenamento com êxito.

   Tipo de evento: informações
   Origem do evento: MSExchangeIS
   Categoria do evento: O gravador VSS do Exchange
   IDENTIFICAÇÃO de evento: 9612
   Data: 17/6/2004
   Tempo: 11:40:44 AM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: Instantâneo VSS do Exchange descongelou os grupos de armazenamento com êxito.

2. O aplicativo de backup deve validar a integridade do conjunto de backup de cópia de sombra.
   
   A Microsoft recomenda, mas não exige, que isso seja feito antes do aplicativo de backup notifica Exchange esse backup foi concluída. A razão para essa recomendação é que o Exchange executa duas tarefas importantes após um backup bem-sucedido:
   • Os cabeçalhos de bancos de dados dos quais foi feito backup para refletir o último tempo de backup bem-sucedido de atualizações do Exchange
   • Exchange remove logs de transação (? Remove ?) do servidor que não são necessárias para roll forward desde o último backup bem-sucedido.
   Se um aplicativo de backup adia a verificação de integridade até depois que tiverem essas tarefas concluídas, em seguida, especial deve ter cuidado para preservar o último backup verificado junto com cópias de todos os arquivos de log necessários ao backup. Embora o backup pode ter já foi relatado como bem-sucedida para o Exchange, o backup deve não ser dependia até que o aplicativo de backup seja concluída, na verdade, verificação de integridade.
   
   Consulte a "como executar verificação de integridade para backups VSS" seção deste artigo para obter detalhes completos sobre como executar as verificações de integridade e como determinar qual banco de dados e arquivos de log de transações deve ser preservada até que a verificação de integridade tenha terminado.
3. Restaura a original local ** deve ser feita exclusivamente com o gravador do Exchange
   
   Gravador do Exchange registrará eventos nos logs de eventos do aplicativo a seguir durante um processo de restauração de cópia de sombra.

   Tipo de evento: informações
   Origem do evento: MSExchangeIS
   Categoria do evento: O gravador VSS do Exchange
   IDENTIFICAÇÃO de evento: 9620
   Data: 17/6/2004
   Tempo: 1:49:59 PM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: Instantâneo VSS do Exchange processou evento de pré-restauração com êxito

   Tipo de evento: informações
   Origem do evento: MSExchangeIS
   Categoria do evento: O gravador VSS do Exchange
   IDENTIFICAÇÃO de evento: 9618
   Data: 17/6/2004
   Tempo: 1:59:46 PM
   Usuário: N/d
   Computador: EXCHSERVER
   Descrição: Instantâneo VSS do Exchange processou evento de pós-restauração com êxito

** "Local original" significa que um computador com Exchange com o mesmo nome de servidor e o mesmo caminho do arquivo como o computador do Exchange onde foi feito o backup VSS.

Restaurações para locais alternativos não podem ser obtidas por meio do gravador do Exchange como do Exchange Server 2003 SP1. Aplicativos de backup VSS baseado podem optar por fornecer manual ou outros métodos programáticos para restaurar cópias de sombra de bancos de dados do Exchange para locais alternativos.

Como executar a verificação de integridade para backups VSS

Quando um banco de dados é feito usando o fluxo contínuo de API de backup do Exchange, cada página no banco de dados é lida por sua vez, e a integridade de soma de verificação de cada página é verificada durante o processo de backup. A integridade de soma de verificação dos arquivos de log de transações também é verificada antes que eles serão copiados.

Durante um backup do VSS, há não oportunidade para o Exchange para ler cada arquivo de banco de dados em sua totalidade e verificar sua integridade de soma de verificação. Portanto, a integridade do arquivo log de transações e banco de dados deve ser verificada pelo aplicativo de backup. Isso pode ser realizado executando Eseutil conforme descrito no final deste documento.

Se você não soma de verificação-verificá seus backups VSS, é possível que uma página danificada pode permanecer sem serem detectados no banco de dados e eventualmente se torne presente em todos os backups existentes. A única maneira de recuperar essa circunstância é corrigir o banco de dados. Reparo de banco de dados exigirá tempo de inatividade abrangente e resultará em menos perda de dados (pelo menos a perda de dados que estavam nas páginas danificadas).

No entanto, se o último backup VSS foi verificado para conter todas as páginas boas, você pode limpar páginas danificadas do banco de dados, restaurando o backup verificado e implantá-la frente com logs de transação criados desde o backup foi feito. O tempo de inatividade necessário fazer isso geralmente será muito menor do que para reparar um banco de dados e esse método de recuperação pode corrigir os problemas de banco de dados com zero perda de dados.

Portanto, você não deve considerar um backup VSS para ser bom até que todos os arquivos de ele tem sido verificada a soma de verificação.

Você deve seguir as duas regras abaixo para verificar a integridade do backup:

• Para arquivos de banco de dados: você sempre deve manter uma cópia de verificar a integridade dos arquivos de banco de dados disponíveis. Um backup de verificação de integridade é uma em qual página verificação de soma de verificação foi concluída em arquivos do banco de dados no conjunto de backup.

Um banco de dados backup recentemente que ainda não tenha passado verificação de soma de verificação não pode ser considerado um backup válido. Você não deve descartar um backup anterior verificado até que você verificou a integridade do backup atual.

• Para arquivos de log de transação: log de transações todos os arquivos necessários para recuperação do backup do banco de dados de verificação de integridade mais recente também deve ser feita backup e sua integridade de nível de soma de verificação também verificada.

Esses logs de transação incluem, no mínimo, o intervalo inclusive de arquivos de log listados no campo log necessário no cabeçalho de cada banco de dados no último backup verificado. Se esses arquivos de log não estiverem disponíveis, o banco de dados não será montado após a restauração.

importante Esse requisito se aplica ao último backup verificada de integridade, não para o backup executado mais recentemente. Até que o backup mais recente passou a verificação de soma de verificação, ele não é considerado um backup válido.

Opcionalmente, você também pode preservar os logs adicionais necessários para reverter completamente o banco de dados Avançar após a restauração de um backup do banco de dados. Esses são todos os logs das transações em seqüência ininterrupta, começando com o menor arquivo de log necessário até o log de transação recém-criado que foi removido do servidor do Exchange. Exemplos detalhados e explicações sobre o que isso significa que é fornecidos abaixo.

Preservando logs de transação além desses listados no log de faixa (s) necessária é opcional, no sentido de que fazer então, não é estritamente necessário para com êxito restaurar e montar dos quais foi feito backup do banco de dados. No entanto, se não preservar todos os esses logs, em seguida, restauração do backup fará com que você perca todas as alterações no banco de dados após o ponto de backup. A Microsoft recomenda que você não só preservar os logs de transação necessários para restaurar e montar dos quais foi feito backup do banco de dados, mas também todos os subseqüentes logs de transação necessários para implantar o banco de dados Avançar sem perda de dados.

Determinar quais arquivos de log de transação são necessários

Se um banco de dados do Exchange é feito backup enquanto ele estiver on-line, arquivo de log pelo menos uma transação sempre será feito backup com ele. Isso é independentemente de você usar o backup de streaming API ou a API de backup VSS.

Após a restauração de uma informações de backup, on-line da transação de logs devem ser aplicados ao banco de dados ("repetido") antes do banco de dados ser montável novamente. O campo de log necessário de cada cabeçalho de banco de dados registra os números de seqüência (geração) do intervalo de arquivos de log de transação que deve ser reproduzidos no banco de dados.

Se o campo de log necessário lê 0-0, isso significa que o banco de dados é montado sem ter que repetir os dados de log de transações adicionais. A única vez em que será o valor de log necessário 0 0 é após um banco de dados é colocado em um estado de desligamento normal ". Enquanto um banco de dados está em execução, o campo de log necessário sempre registra o intervalo de logs de transação que ainda não foram aplicadas ao banco de dados. Esse intervalo é atualizado continuamente.

Um banco de dados backup on-line sempre terá um intervalo de log necessário diferente de zero, e esses logs devem ser copiados junto com o banco de dados. Se, após a restauração, esses logs não estiverem disponíveis, o banco de dados não será montado. (Você pode reparar o banco de dados se os logs necessários não podem ser encontrados, mas não houver nenhuma garantia que reparo será bem-sucedido e reparo quase sempre irá resultar em algum nível de perda de dados, mesmo se fizer somente os dados a ausente.)

Se você usar o fluxo contínuo de API de backup ou a API de backup VSS contidos o gravador VSS do Exchange do Exchange, em seguida, arquivos de log necessários necessários para montar um banco de dados serão feitos backup automaticamente com o banco de dados. Se você copiar somente os arquivos de log necessário, isso resultará no banco de dados sendo restaurado para o ponto de tempo em que o backup concluído. Se você desejar reverter passado direta banco de dados que apontam, você deve jogar também os arquivos de log gerados depois que o backup foi feito.

Para lançar completamente frente do banco de dados de qualquer backup específico, você deve preservar todos os arquivos de log em seqüência ininterrupta partir o log de mais baixo no intervalo de log necessário até ao arquivo de log gerado mais recentemente no grupo de armazenamento do banco de dados. Se qualquer log nesta série de estiver faltando ou danificado, você só poderá adiar até ao ponto do último log boa antes do arquivo ausente ou danificado.

Portanto, se você deseja recuperar do backup sem perda de dados, é essencial que você mantenha boas cópias de todos os arquivos de log de transação constante avanço desde seu último backup verificados bom banco de dados.

Remoção de log de transação

Se os logs de transação não forem removidos de um servidor Exchange, continuará a acumular até que eles preenchem todo espaço em disco disponível. Portanto, tanto o fluxo contínuo e APIs de backup VSS suportam "remoção" de arquivos de log de transações após a conclusão de um backup normal ou incremental. Arquivos de log mais antigos que aquelas necessárias para recuperar o backup mais recente são automaticamente excluídas do servidor após os sinais de aplicativos de backup do Exchange que backup foi concluída com êxito.

Com a API de fluxo, verificação de soma de verificação de banco de dados é feita durante o processo de backup. O momento em que um backup é concluído, todo o banco de dados e os arquivos de log necessários foram verificados para integridade física. Com a API de VSS, verificação de soma de verificação não pode ser feita como parte do processo de backup real. O fornecedor deve verificar a integridade física do banco de dados independentemente do processo de backup. Isso pode ser feito com Eseutil antes ou depois de sinalização Exchange que o backup foi concluída.

Se a verificação de soma de verificação for feita antes de backup é concluído, e um problema é encontrado no conjunto de backup, em seguida, Exchange pode ser informado que o backup não teve êxito. Isso impedirá que o Exchange de remoção de arquivos de log do servidor.

Se verificação de soma de verificação é adiada até depois de sinalização de conclusão de backup, em seguida, o Exchange excluirá arquivos de log antigos do servidor. Alguns desses arquivos log podem ter sido necessário para sem interrupção frente de um backup anterior de boa. Se você já não tiver feito cópias desses logs, em seguida, não será capaz de roll forward completamente.

Portanto, a Microsoft recomenda, mas não exige, que verificação de soma de verificação seja executada em um backup VSS antes do aplicativo de backup sinais de conclusão de backup para o Exchange. Se a verificação de soma de verificação é adiada até depois que o backup já for concluída, em seguida, o aplicativo de backup deve garantir que cópias são feitas de todos os arquivos log de transações que foram removidos do servidor, a menos que sem interrupção frente completamente não é importante para você.

Na maioria dos casos, todos os logs de transação necessários para roll forward um backup VSS estarão disponível no conjunto de arquivos de log salvo com o backup anterior com aqueles salvos com o backup atual. Entretanto, os clientes devem verificar que isso é o caso ao considerar um fornecedor específico.

Restauração de backups não-verificados

Pode haver casos onde um desastre exigir restauração ocorre antes de verificação de soma de verificação foi concluída em um backup recente. Em tais casos, a Microsoft recomenda que você restaurar um backup anterior verificado e reverter esse backup direta em vez de confiar em um backup não-verificado.

No entanto, você pode ter contratos de nível de serviço que exigem que você restaurar os dados mais rapidamente do que pode ser feito a partir do backup anterior. Nesses casos, restauração do backup não-verificado pode ser uma opção melhor, contanto que você ainda manter que uma anterior verificar todos os arquivos de log necessários para roll forward completamente dele e de backup. Se você atender a esses requisitos, em seguida, ainda será capaz de roll forward de um backup boa conhecido no caso do último backup é descoberto ser incorreto.

Como verificar a consistência de instantâneo

Solicitador VSS deve verificar consistência de instantâneo executando Eseutil.exe contra os arquivos de banco de dados e de log usando as opções apropriadas como na tabela a seguir. Solicitador VSS deve verificar se todas as saída ERRORLEVELs são retornados estão não-negativo. Para ver o ERRORLEVEL na linha de comando, digite echo % errorlevel % após Eseutil.exe execução ser concluída. Um ERRORLEVEL negativo significa que há corrupção nos arquivos. Antes de solicitador VSS chama BackupComplete , solicitador VSS deve verificar status do componente de backup no documento componente backup reflete o resultado da verificação de consistência. Isto é, status do componente de backup deve ser FALSE se houver corrupção for encontrada e deve ser VERDADEIRO se nenhuma corrupção for encontrada. Verificação de consistência de instantâneo é um requisito obrigatório para a solução ser o suporte a equipe do Exchange.

A tabela a seguir mostra a combinação de verificações de integridade para cada tipo de backup.
Devido à natureza snap backups VSS, o JET não obtém a oportunidade para tocar todas as páginas para fazer as verificações de consistência necessário. Portanto, é responsabilidade do solicitador VSS para garantir consistência de instantâneo.

* Todos os arquivos de log com número de geração de arquivo de log igual a ou maior que o arquivo de log do ponto de verificação são necessários para recuperar um banco de dados instantâneo. Se existe o atual arquivo de log (Enn.log) também é necessário para recuperação do banco de dados. Se algum dos arquivos de log necessário falhar a verificação de consistência, solicitante deve Verifique se o status do componente backup está definido para FALSE antes para chamada BackupComplete . Para determinar o arquivo de log do ponto de verificação, execute eseutil.exe contra o arquivo de ponto de verificação de instantâneo e analisar a saída para "ponto de verificação:" por exemplo, "c:\eseutil.exe /mk E01.chk" mostra o seguinte: onde 0 x 20 é o número de geração de log do ponto de verificação de arquivo de log.

Neste exemplo, qualquer log de arquivos, incluindo E0100020.log e acima, deve ser corrompido em não para recuperar o banco de dados instantâneo mesmo se o próprio banco de dados já tivesse passado a verificação de consistência física.

** Todos os arquivos de log em um incremental ou diferencial conjunto de backup são necessários para recuperação do banco de dados. Consistência de uma seqüência inteira log pode ser verificada, executando eseutil contra o prefixo do arquivo de log. Por exemplo, ? eseutil /k E01 ? irá executar verificações de consistência contra todos os arquivos do formulário E01xxxxx.log em um determinado caminho.