Cópia de segurança do Exchange Server 2003 dados e serviços de cópia sombra de volumes

A funcionalidade de serviço de cópia sombra de volumes no Microsoft Windows Server 2003 pode ser utilizada para criar aplicações que efectuar uma cópia de segurança e restaurar o Microsoft Exchange Server 2003. O Windows serviço sombra de volumes copiar (VSS) fornece uma infra-estrutura que permite que programas de gestão de armazenamento de outros fabricantes, programas comerciais e fornecedores de hardware para cooperar na criação e gestão de cópias sombra. Soluções baseadas nesta infra-estrutura podem utilizar a cópias sombra (ou cópias de mirror) para criar uma cópia de segurança e restaurar uma ou mais Exchange Server 2003 bases de dados.

O serviço de cópia sombra de volumes coordena comunicação entre solicitadores (aplicações de cópia de segurança), escritores (aplicações nos serviços do Windows como Exchange Server 2003 e SQL Server 2000) e de fornecedores (componentes sistema, software ou hardware que cria as cópias sombra). Para utilizar a funcionalidade de serviço de cópia sombra de volumes para cópia de segurança Exchange Server 2003, o programa de cópia de segurança tem de incluir solicitador de serviço de cópia sombra de volumes conhecimento um Exchange Server 2003. O programa de cópia de segurança que está agrupado com o Windows Server, porque não tal solicitador organizações tem de utilizar aplicações de cópia de segurança de terceiros.

Para estar em conformidade com o Exchange Server 2003, aplicações de cópia de segurança do VSS com base tem de seguir três requisitos básicos para assegurar a integridade e recuperação de cópias sombra. Se estes requisitos não forem seguidos, serviços de suporte técnico da Microsoft (PSS) terá de considerar a solução de cópia de segurança seja fora da estrutura do Exchange VSS e não será capaz de resolução de problemas relacionados com a cópia de segurança e restaurar problemas. Os clientes devem verificar com os respectivos fornecedores de cópia de segurança que a aplicação de cópia de segurança cumpra os requisitos compatível com o Exchange listados neste artigo da base de dados de conhecimento da. Detalhes dos requisitos VSS Exchange são apresentadas na secção "Mais informação" deste artigo.

Tal como com qualquer solução de terceiros, o fornecedor da aplicação cópia de segurança é o fornecedor de suporte principal para problemas de cópia de segurança e recuperação. Suporte técnico da Microsoft podem ajudar a diagnosticar ou analisar problemas relacionados com a base de dados disponível e conjuntos de ficheiros registo transacções. No entanto, Microsoft não resolução de problemas ou depurar produtos de outros fabricantes. Assistência do suporte técnico da Microsoft está limitada a conselhos sobre como continuar melhor recuperar a base de dados disponível e ficheiros de registo de transacções.

Para obter mais informações sobre como VSS com soluções são suportadas pelo suporte técnico da Microsoft, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

A lista seguinte descreve a cópia de segurança Exchange Server 2003 com o processo do serviço cópia sombra de volumes:

1. Programa de cópia de segurança (ou agente) executa uma tarefa agendada.
2. O serviço de cópia sombra de volumes solicitador no programa de cópia de segurança envia um comando ao serviço de cópia sombra de volumes para tirar uma cópia sombra dos grupos de armazenamento seleccionadas do Exchange Server 2003.
3. Serviço de cópia sombra do volume comunica com o Exchange Server ' Escritor de 2003 para preparar uma cópia de segurança do instantâneo.
4. Serviço de cópia sombra do volume comunica com o fornecedor de armazenamento adequado para criar uma cópia sombra do 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ópia sombra do volume lança o Exchange Server 2003 para retome as operações normais.
6. O serviço de cópia sombra de volumes solicitador verifica a integridade do conjunto cópia de segurança anteriores ao Exchange de informar que a cópia de segurança teve êxito.

Por exemplo, quando é recebido um pedido de cópia sombra de um programa de cópia de segurança do Exchange Server 2003 que tem serviço de cópia sombra de volumes suporta (um solicitador), cópia sombra de volumes serviço comunica com o Exchange Server ' Escritor de 2003 para preparar o instantâneo, neste momento Exchange Server 2003 proíbe acções administrativas contra o grupo de armazenamento, verifica as dependências de volume e suspende todas escrever operações a base de dados e ficheiros de registo de transacções permitindo acesso só de leitura. Serviço de cópia sombra do volume, em seguida, comunica com o fornecedor de armazenamento adequado para iniciar o processo de cópia sombra para os volumes de disco que contêm os dados do Exchange Server 2003. A cópia sombra normalmente demora alguns segundos, que serão praticamente despercebidos ao utilizador final. Quando a cópia sombra foi colocada, o serviço de cópia sombra de volumes comunica com o escritor do Exchange Server 2003 que Exchange pode retome as operações normais. Programa de cópia de segurança verifica a integridade da cópia sombra anteriores ao Exchange de informar que a cópia de segurança teve êxito. No fim de um Exchange de cópia de segurança com êxito trunca os registos e regista o tempo da última cópia de segurança para a base de dados ou bases de dados.

Para obter mais informações sobre cópia de segurança Exchange Server 2003 com serviços de cópia sombra de volumes, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

A lista seguinte descreve os requisitos do Exchange Server 2003 que as aplicações de cópia de segurança de cópia sombra tem de seguir para garantir a integridade e a recuperação de bases de dados do Exchange:

A lista abaixo fornece registos de eventos aplicação específicos que identificam se forem a ser seguidos os requisitos do Exchange. Aplicações de cópia de segurança e o servidor do Exchange poderão iniciar outros eventos associados com o processo de cópia de segurança e restauro. Confirmar que os seguintes eventos são registados durante a cópia de segurança e restauro irá servir como a verificação de conformidade com os requisitos do Exchange VSS. Actualmente, não existe nenhum programa de certificação para qualquer solução de software de terceiros em execução no Exchange. Compatibilidade assegura a integridade e recuperação de cópias sombra, mas não oferece nenhuma garantia no desempenho ou fiabilidade da solução de terceiros.

1. Transacção de base de dados do Exchange, registo e ficheiros de ponto de verificação devem ser efectuados exclusivamente através o escritor do Exchange:
   
   Os seguintes eventos aplicação serão registados, se o escritor do Exchange for iniciado durante cópias sombra.

   Tipo de evento: Information
   Origem do evento: ESE
   Categoria do evento: ShadowCopy
   ID do evento: 2005
   Data: 6/17/2004
   Tempo: 11:40:41 AM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Cópia de arquivo de informações (2180) sombra instância iniciar 3. Este será ? tipo de cópia de segurança ? * cópia sombra.

   * Onde ? tipo de cópia de segurança ? é o tipo de efectuar cópia de segurança (Full, cópia, incremental ou diferencial).

   Tipo de evento: Information
   Origem do evento: MSExchangeIS
   Categoria do evento: O escritor do VSS de Exchange
   ID do evento: 9608
   Data: 6/17/2004
   Tempo: 11:40:42 AM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Exchange VSS Snapshot preparado para snapshot com êxito.

   Tipo de evento: Information
   Origem do evento: MSExchangeIS
   Categoria do evento: O escritor do VSS de Exchange
   ID do evento: 9610
   Data: 6/17/2004
   Tempo: 11:40:43 AM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Exchange VSS Snapshot tem fixos de com êxito os grupos de armazenamento.

   Tipo de evento: Information
   Origem do evento: MSExchangeIS
   Categoria do evento: O escritor do VSS de Exchange
   ID do evento: 9612
   Data: 6/17/2004
   Tempo: 11:40:44 AM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Exchange VSS Snapshot tem thawed de com êxito os grupos de armazenamento.

2. A aplicação de cópia de segurança tem de validar a integridade do conjunto de cópia de segurança de cópias sombra.
   
   A Microsoft recomenda, mas não é necessário, que isto ser feito antes da aplicação de cópia de segurança notifica Exchange essa cópia de segurança foi concluída. O motivo para esta recomendação é que Exchange executa duas tarefas importantes depois de uma cópia de segurança com êxito:
   • Os cabeçalhos das bases de dados dos quais efectuou cópia de segurança para reflectir a última vez cópia de segurança com êxito de actualizações do Exchange
   • Exchange remove os registos de transacções (? elimina ?) do servidor que já não são necessários para rollforward a partir da última cópia de segurança com êxito.
   Se uma aplicação de cópia de segurança adia a verificação de integridade até depois de tem estas tarefas concluídas, em seguida, especial deve ter o cuidado para manter a última cópia de segurança verificada juntamente com cópias de todos os ficheiros de registo necessários para essa cópia de segurança. Apesar da cópia de segurança poderão ter já sido reportada como com êxito para o Exchange, a cópia de segurança deverá não ser confiavam no, até que a aplicação de cópia de segurança, na realidade, tenha concluído a verificação de integridade.
   
   Consulte o "como efectuar verificação da integridade para cópias de segurança do VSS" secção deste artigo para detalhes completos sobre como efectuar as verificações de integridade e como determinar qual a base de dados e ficheiros de registo de transacções tem de ser mantida até acabar de verificação de integridade.
3. Restaura a localização original ** tem de ser efectuada exclusivamente com o escritor do Exchange
   
   Impressão em formato Exchange registará após eventos de registos de eventos de aplicações durante um processo de restauro de cópia sombra.

   Tipo de evento: Information
   Origem do evento: MSExchangeIS
   Categoria do evento: O escritor do VSS de Exchange
   ID do evento: 9620
   Data: 6/17/2004
   Tempo: 1:49:59 PM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Exchange VSS Snapshot processou pre-restore eventos com êxito

   Tipo de evento: Information
   Origem do evento: MSExchangeIS
   Categoria do evento: O escritor do VSS de Exchange
   ID do evento: 9618
   Data: 6/17/2004
   Tempo: 1:59:46 PM
   Utilizador: N/d
   Computador: EXCHSERVER
   Descrição: Exchange VSS Snapshot processou post-restore eventos com êxito

** "Localização original" significa que um computador do Exchange com o mesmo nome de servidor e o mesmo caminho de ficheiro que o computador do Exchange onde foi efectuada a cópia de segurança do VSS.

Restaura a localizações alternativas não pode ser alcançada através do escritor do Exchange como do Exchange Server 2003 SP1. Aplicações de cópia de segurança do VSS com base pode fornecer manual ou outros métodos de programação para restaurar cópias sombra de bases de dados do Exchange para localizações alternativas.

Como efectuar a verificação de integridade para cópias de segurança do VSS

Quando uma base de dados é feita utilizando o Exchange transmissão em sequência API de cópia de segurança, cada página na base de dados é lido por sua vez e a integridade da soma de verificação de cada página é verificada durante o processo de cópia de segurança. A integridade da soma de verificação do ficheiros de registo de transacções também é verificada antes que são efectuadas cópias de segurança.

Durante uma cópia de segurança do VSS não existe nenhuma oportunidade para o Exchange para ler cada ficheiro de base de dados na sua totalidade e para verificar a integridade da soma de verificação. Por este motivo, integridade de ficheiro registo da base de dados e transacções deve ser verificada pela aplicação de cópia de segurança. Pode fazê-lo executando o Eseutil como descrito no final deste documento.

Se de que não soma de verificação-verificar as cópias de segurança VSS, é possível que uma página danificada foi permanecem não detectada na base de dados e, eventualmente, tornam-se presente em todas as cópias de segurança existentes. A única forma de recuperar nestas circunstâncias é reparar a base de dados. Reparar base de dados irá requerer períodos de inactividade extenso e irá resultar em, pelo menos, perda de dados (pelo menos a perda de dados que estavam em páginas danificadas).

No entanto, se a última cópia de segurança VSS tiverem sido verificada para conter todas as páginas boas, pode limpar páginas danificadas da base de dados, restaurar a cópia de segurança verificada e graduais-frente com registos de transacções criados desde que foi efectuada a cópia de segurança. O período de indisponibilidade necessário efectuar este procedimento ficará muito inferior para reparar uma base de dados e este método de recuperação pode corrigir os problemas de base de dados com zero perda de dados.

Assim, não deverá considerar uma cópia de segurança VSS ser bom até que todos os ficheiros no mesmo tem sido verificado de soma de verificação.

Deverá seguir as duas regras abaixo para verificar a integridade de cópia de segurança:

• Para ficheiros de base de dados: tem sempre uma cópia de verificar a integridade dos ficheiros da base de dados disponíveis. Uma cópia de segurança Verificar integridade é uma em que página verificação de soma de verificação foi concluída nos ficheiros de base de dados no conjunto de cópia de segurança.

Uma base de dados recentemente cópia de segurança que ainda não tenha passado verificação de soma de verificação não pode ser considerada uma cópia de segurança válida. Não deve eliminar uma cópia de segurança verificada anterior até verificou a integridade da cópia de segurança actual.

• Para ficheiros de registo de transacções: Registar transacção todos os ficheiros necessários para recuperar a cópia de segurança verificar a integridade de base de dados mais recente deve também ser efectuada e os respectivos integridade de nível de soma de verificação também verificar.

Incluem estes registos de transacções, no mínimo, intervalo de ficheiros de registo listado no campo registo necessário no cabeçalho de cada base de dados na última cópia de segurança verificada inclusive. Se estes ficheiros de registo não estiverem disponíveis, a base de dados não será montável após o restauro.

importante Este requisito aplica-se a última cópia de verificar a integridade de segurança, não para a cópia de segurança executada mais recentemente. Até que a cópia de segurança mais recente passou a verificação de soma de verificação, não é considerado uma cópia de segurança válida.

Opcionalmente, também pode manter os registos adicionais necessários para recuperar completamente a base de dados para a frente após o restauro de uma cópia de segurança da base de dados. Estes são todos os registos de transacções numa sequência ininterrupta começando com ficheiro de registo necessário mais baixo até ao registo de transacções criado mais recentemente que tenha sido eliminado do Exchange server. Obter exemplos detalhados e explicações sobre o que isto significa que é fornecidas abaixo.

Manter registos de transacções para além dessas listados no registo de intervalo (s) necessário é opcional, no sentido em que se o fizer, não é estritamente necessário para com êxito restaurar e uma cópia de segurança de montagem base de dados. No entanto, se não preserva todos estes registos, em seguida, restaurando a partir da cópia de segurança fará com que a perda de todas as alterações na base de dados após o ponto de cópia de segurança. A Microsoft recomenda que preservar não só os registos de transacção necessários para restaurar e uma cópia de segurança de montagem base de dados, mas necessários para recuperar a base de dados para a frente sem perda de dados também registos de transacções subsequentes tudo.

Determinar que ficheiros de registo de transacções são necessários

Se uma base de dados do Exchange é cópias enquanto estiver online, ficheiro de registo, pelo menos, uma transacção serão sempre copiado com ele. Isto é independentemente de utilizar a cópia de segurança transmissão em sequência API ou a API de cópia de segurança do VSS.

Após o restauro de um online informações de cópia de segurança, da transacção registos tem ser aplicados à base de dados ("reproduzidos") antes da base de dados vai ser montável novamente. Campo de cada cabeçalho de base de dados de registo necessário regista os números de sequência (geração) do intervalo dos ficheiros de registo de transacções devem ser reproduzidos na base de dados.

Se o campo de registo necessário lê 0-0, isto significa que a base de dados é montável sem ter de reprodução de quaisquer dados de registo de transacções adicionais. Só o valor de registo necessário será igual a 0-0 é depois de uma base de dados é transferido para um estado de encerramento limpar. Com uma base de dados está em execução, o campo de registo necessário regista sempre o intervalo de registos de transacção que ainda não foram aplicadas à base de dados. Este intervalo é actualizado continuamente.

Uma base de dados efectuada uma cópia de segurança online terão sempre um intervalo de registo necessário diferente de zero e estes registos devem ser efectuados juntamente com a base de dados. Se, após o restauro, estes registos não estiverem disponíveis, a base de dados não será montável. (É possível reparar a base de dados se podem encontrar os registos necessários, mas não existir nenhuma garantia de que reparação será bem sucedida e reparação originarão quase sempre algum nível de perda de dados, mesmo que apenas os dados em falta a sessão.)

Se utilizar o Exchange transmissão em sequência API de cópia de segurança ou a API de cópia de segurança do VSS contidos no escritor do VSS Exchange, em seguida, necessários ficheiros de registo necessários para montar uma base de dados serão copiados automaticamente com a base de dados. Se reproduzir apenas os ficheiros de registo necessário, este irá resultar na base de dados a ser restaurada para o ponto de tempo em que a cópia de segurança concluída. Se pretender anular passado para a frente da base de dados que apontam, tem também reproduzir ficheiros de registo gerados depois da cópia de segurança foi efectuada.

Para lançar completamente a base de dados para a frente a partir de qualquer cópia de segurança específica, tem de manter todos os ficheiros de registo numa sequência ininterrupta partir o registo mais baixo no intervalo de registo necessário até ao ficheiro de registo gerado mais recentemente no grupo de armazenamento da base de dados. Se qualquer outro registo nesta série estiver em falta ou danificado, apenas conseguirá rollforward cópia para o ponto do último registo boa antes do ficheiro em falta ou danificado.

Consequentemente, se pretender recuperar a cópia de segurança sem perda de dados, é essencial que mantêm boas cópias de todos os ficheiros de registo de transacções vai para a frente da última cópia de segurança verificado de boa base de dados.

Eliminação do registo de transacções

Se não forem removidos registos de transacções a partir de um servidor do Exchange, continuará a acumular até que estão a preencher todo o espaço disponível. Por conseguinte, transmissão em sequência e cópia de segurança do VSS API suportam "eliminação" dos ficheiros de registo de transacções após a conclusão de uma cópia de segurança normal ou incremental. Ficheiros de registo mais antigos do que os necessários para recuperar a cópia de segurança mais recente são automaticamente eliminados do servidor depois dos sinais de aplicações de cópia de segurança Exchange essa cópia de segurança foi concluída com êxito.

Com a API de transmissão em sequência, é feita verificação de soma de verificação de base de dados durante o processo de cópia de segurança. Quando que conclui uma cópia de segurança, tiverem sido verificados toda a base de dados e os ficheiros de registo necessárias para integridade física. Com a API VSS, verificação de soma de verificação não pode ser feita como parte do processo de cópia de segurança real. O fornecedor deve verificar a integridade física da base de dados independentemente do processo de cópia de segurança. Isto pode fazer com o Eseutil antes ou depois de sinalização Exchange que a cópia de segurança foi concluída.

Se a verificação de soma de verificação é efectuada antes de cópia de segurança completa e é detectado um problema no conjunto de cópia de segurança, em seguida, Exchange pode ser informado que a cópia de segurança não teve êxito. Este procedimento impedirá Exchange dos ficheiros de registo de eliminação do servidor.

Se a verificação de soma de verificação é adiada até após conclusão de cópia de segurança de sinalização, o Exchange eliminar ficheiros de registo mais antigos do servidor. Alguns destes ficheiros registo poderão ter sido necessária para móvel para a frente a partir de uma cópia de segurança boa anterior. Se não tiver efectuado já cópias destes registos, em seguida, não será possível rollforward completamente.

A Microsoft recomenda assim, mas não é necessário, que a verificação de soma de verificação sejam efectuados numa cópia de segurança do VSS antes da aplicação de cópia de segurança sinais de conclusão de cópia de segurança para o Exchange. Se a verificação de soma de verificação é adiada até Certifique-quando já tiver concluído a cópia de segurança, a aplicação de cópia de segurança tem se são feitas cópias de todos os ficheiros de registo transacção que foram eliminados do servidor, a menos que graduais frente completamente não é importante para si.

Na maioria dos casos, todos os registos de transacções necessários para rollforward uma cópia de segurança do VSS estará disponível no conjunto de ficheiros de registo guardado com a cópia de segurança anterior juntamente com os guardados com a cópia de segurança actual. No entanto, os clientes devem verificar que isto acontece quando considerar um determinado fornecedor.

Restaurar cópias de segurança não verificadas

Poderão existir casos em que um desastre que requerem o restauro ocorre antes de verificação de soma de verificação foi concluída numa cópia de segurança recente. Nesses casos, a Microsoft recomenda que restaurar uma cópia de segurança verificada anterior e anular essa cópia de segurança directa em vez de dependente numa cópia de segurança não verificada.

No entanto, poderá ter acordos de nível de serviço que requerer a restaurar dados mais rapidamente do que pode ser efectuado a partir da cópia de segurança anterior. Nestes casos, o restauro de cópia de segurança não verificado poderá ser a melhor opção, desde que ainda mantenha que um anterior verificar cópia de segurança e todos os ficheiros de registo necessários para rollforward completamente a partir do mesmo. Se cumprir estes requisitos, em seguida, irá conseguir rollforward a partir de uma cópia de segurança boa conhecida no caso da última cópia de segurança é identificada seja inválido.

Como verificar a consistência do instantâneo

Solicitador de VSS deve verificar consistência instantâneo executando Eseutil.exe contra os ficheiros de base de dados e do registo utilizando as opções adequadas como na seguinte tabela. Solicitador de VSS deve verificar se todos os saída ERRORLEVELs que são devolvidos estão não pode ser negativo. Para ver o ERRORLEVEL na linha de comandos, escreva echo % errorlevel % quando estiver Eseutil.exe concluída. Um ERRORLEVEL negativo significa que existe danos nos ficheiros. Antes de VSS solicitador chama BackupComplete , VSS solicitador tem Certifique-se de que o estado do componente de cópia de segurança no documento de componente de cópia de segurança reflecte o resultado da verificação de consistência. Ou seja, de estado o componente de cópia de segurança deve ser TRUE FALSE se qualquer encontrados danos e deve ser se encontrados não danos. Verificação de consistência de snapshot é um requisito obrigatório para a solução ser suportadas pela equipa do Exchange.

A tabela seguinte mostra a combinação de verificações de integridade para cada tipo de cópia de segurança.
Devido à natureza snap VSS cópias de segurança, o JET não obtém a oportunidade de tocar todas as páginas para efectuar as verificações de consistência necessário. Por este motivo, é responsabilidade do VSS solicitador para garantir a consistência do instantâneo.

* Todos os ficheiros de registo com o registo ficheiro geração de número igual ou maior do que o ficheiro de registo de ponto de verificação são necessários para recuperar uma base de dados instantâneo. Se existe o actual ficheiro de registo (Enn.log) também é necessário para recuperação da base de dados. Se qualquer dos ficheiros de registo necessárias falhar a verificação de consistência, solicitador tem de assegurar que o estado do componente cópia de segurança estiver definido como FALSE antes a chamada BackupComplete . Para determinar o ficheiro de registo de ponto de verificação, execute eseutil.exe o ficheiro de ponto de verificação 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 registo do ponto de verificação do ficheiro de registo.

Neste exemplo, qualquer registo de ficheiros, incluindo E0100020.log e acima, tem de ser não danificado para recuperar a base de dados instantâneo mesmo se a própria base de dados já tivesse transmitido a verificação de consistência física.

** Todos os ficheiros de registo de um incremental ou diferencial conjunto de cópia de segurança são necessárias para recuperação da base de dados. Consistência de uma sequência de registo completo pode ser seleccionada ao executar o eseutil com o prefixo do ficheiro de registo. Por exemplo, ? eseutil /k E01 ? executará verificações de consistência contra todos os ficheiros de formulário E01xxxxx.log no caminho especificado.