Understanding Backup, Restore and Disaster Recovery
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2010-11-01
O Microsoft Exchange Server 2010 apresenta uma plataforma nova, unificada, de alta disponibilidade e resiliência de site que agiliza e facilita a implantação de bancos de dados de caixa de correio redundantes e altamente disponíveis. Mas mesmo as formas mais extremas de redundância e de tolerância a falhas não podem proteger você de todas as falhas ou desastres possíveis. Garantir que haja proteção suficiente para os dados essenciais em sua organização do Exchange é uma tarefa operacional necessária para todas as organizações.
Como parte do planejamento para proteção de dados, é importante compreender as formas nas quais os dados podem ser protegidos e determinar qual delas melhor atende às necessidades da organização. O planejamento para proteção de dados é um processo complexo que depende de várias decisões tomadas durante a fase de planejamento da implantação.
Conteúdo
Tecnologias de backup com suporte
Recuperação do servidor
Banco de dados de recuperação
Portabilidade do banco de dados
Portabilidade de sinal de linha
Proteção de dados nativa do Exchange
Tecnologias de backup com suporte
O Microsoft Exchange Server 2007 e o Exchange Server 2003 incluem duas opções diferentes para backup e recuperação de dados: APIs de backup de streaming ESE (Mecanismo de Armazenamento Extensível) suporte às APIs de backup de VSS (Serviço de Cópias de Sombra de Volume). O Exchange 2010 não dá mais suporte às APIs de streaming ESE para backup e restauração de arquivos de programa ou dados. Em vez disso, o Exchange 2010 suporta apenas os backups baseados em VSS.
O Exchange 2010 inclui um plug-in para o Backup do Windows Server que permite criar backups dos dados do Exchange com base no VSS. É possível usar o Backup do Windows Server para fazer backup e restaurar os bancos de dados do Exchange. Para fazer backup e restaurar o Exchange 2010, você deve usar um aplicativo com suporte ao Exchange que dê suporte ao gravador VSS para Exchange 2010, como o Backup do Windows Server (com o plug-in VSS), o Microsoft System Center Data Protection Manager ou um aplicativo baseado em VSS com suporte ao Exchange. Esteja atento a essas limitações ao usar o VSS no backup e na restauração de dados do Exchange:
O plug-in VSS que acompanha o Exchange 2010 pode ser usado no backup de volumes que contenham cópias de banco de dados de caixa de correio ou apenas bancos de dados de caixa de correio autônomos (não replicados). Ele não pode ser usado para fazer backup de volumes que contêm cópias de bancos de dados de caixa de correio passiva. Para fazer backup de cópias de banco de dados de caixa de correio passivas, você precisa do Microsoft System Center Data Protection Manager ou de um aplicativo de terceiros baseado em VSS com suporte ao Exchange.
É feito o backup das cópias de banco de dados de caixa de correio passivas usando-se um gravador VSS à parte no serviço de Replicação do Microsoft Exchange. O gravador VSS do serviço de Replicação do Microsoft Exchange não suporta restaurações. Embora seja possível fazer backup de uma cópia de banco de dados de caixa de correio passiva usando-se o Microsoft System Center Data Protection Manager ou um aplicativo baseado em VSS com suporte ao Exchange, você não pode realizar uma restauração de VSS diretamente em uma cópia de banco de dados de caixa de correio passiva. No entanto, é possível realizar uma restauração de VSS em um local alternativo, suspender a replicação para a cópia passiva e, em seguida, copiar o banco de dados e os arquivos de log do local alternativo para o local da cópia de banco dados passiva no sistema de arquivos.
Para instruções detalhadas sobre backup e restauração de dados do Exchange usando o Windows Server Backup, consulte Usando o backup do Windows Server para realizar o backup e restaurar dados do Exchange.
Voltar ao início
Recuperação do servidor
Praticamente todas as definições de configuração das funções de servidor Caixa de Correio, Acesso para Cliente, Transporte de Hub e Unificação de Mensagens são armazenadas no Active Directory. Assim como acontecia com versões anteriores do Exchange, o Exchange 2010 inclui um parâmetro de Instalação para recuperação de servidores perdidos. Esse parâmetro, /m:RecoverServer, é usado para recompilar e recriar um servidor perdido, usando-se as definições e as informações de configuração armazenadas no Active Directory.
Para obter etapas detalhadas sobre a realização da recuperação de um servidor perdido do Exchange 2010, consulte Recuperar um Exchange Server. Para obter etapas detalhadas sobre a recuperação de um servidor perdido que seja membro de um grupo de disponibilidade do banco de dados, consulte Recuperar um servidor de membro do grupo de disponibilidade do banco de dados.
Voltar ao início
Banco de dados de recuperação
Banco de dados de recuperação é um recurso do Exchange 2010 que substitui o RSG (grupo de armazenamento de recuperação) encontrado nas versões anteriores do Exchange. Banco de dados de recuperação é um tipo especial de banco de dados de caixa de correio que permite montar um banco de dados de caixa de correio restaurado e extrair dados do banco de dados restaurado como parte de uma operação de recuperação. É possível usar o cmdlet restore-Mailbox para extrair dados de um banco de dados de recuperação. Após a extração, os dados podem ser exportados para uma pasta ou mesclados em uma caixa de correio existente. Os bancos de dados de recuperação permitem recuperar dados de um backup ou da cópia de um banco de dados sem atrapalhar o acesso do usuário a dados atuais.
Para que seja possível usar um banco de dados de recuperação, existem determinados requisitos a serem atendidos. Um banco de dados de recuperação só pode ser usado para bancos de dados de caixas de correio do Exchange 2010. Não há suporte para bancos de dados de caixa de correio de versões anteriores do Exchange. Além disso, a caixa de correio de destino usada em mesclagens de dados e extrações deve estar na mesma floresta do Active Directory do banco de dados montado no banco de dados de recuperação.
Para mais informações, consulte Bancos de dados de recuperação. Para obter instruções detalhadas sobre como criar um banco de dados de recuperação, consulte Criar um banco de dados de recuperação. Para obter instruções detalhadas sobre como usar um banco de dados de recuperação, consulte Restaurar dados usando um banco de dados de recuperação.
Voltar ao início
Portabilidade do banco de dados
A portabilidade de banco de dados é um recurso que permite que um banco de dados de caixa de correio do Exchange 2010 seja movido para e montado em qualquer outro servidor de caixa de correio do Exchange 2010 na mesma organização. Usando a portabilidade de banco de dados, a confiabilidade é aprimorada pela remoção de diversas etapas manuais suscetíveis a erros dos processos de recuperação. Além disso, essa portabilidade reduz os tempos de recuperação gerais de vários cenários de falha.
Para mais informações, consulte Portabilidade do banco de dados. Para instruções detalhadas sobre portabilidade de banco de dados, consulte Mover um banco de dados de caixa de correio usando a portabilidade de banco de dados.
Voltar ao início
Portabilidade de sinal de linha
A portabilidade de sinal de linha é um recurso que fornece uma solução de continuidade comercial limitada para falhas que afetem um banco de dados de caixa de correio, um servidor ou um site inteiro. A portabilidade de sinal de linha permite que um usuário tenha uma caixa de correio temporária para envio e recebimento de email enquanto a caixa de correio original está sendo restaurada ou reparada. A caixa de correio temporária pode estar no mesmo servidor de Caixa de Correio do Exchange 2010 ou em qualquer outro servidor de Caixa de Correio do Exchange 2010 em sua organização. Isso permite que um servidor alternativo hospede as caixas de correio de usuários que estavam antes em um servidor que não está mais disponível. Clientes que oferecem suporte a Descoberta Automática, como o Microsoft Outlook 2010 ou Office Outlook 2007, são automaticamente redirecionados para o novo servidor sem a necessidade de atualização manual do perfil da área de trabalho do usuário. Após os dados da caixa de correio original do usuário serem restaurados, um administrador pode mesclar a caixa de correio recuperada e a caixa de correio com sinal de linha de um usuário em uma caixa de correio única e atualizada.
O processo para o uso da portabilidade de sinal de linha é denominado uma recuperação de sinal de linha. Uma recuperação de sinal de linha envolve a criação de um banco de dados vazio em um servidor de Caixa de Correio para substituir o banco de dados com falha. Esse banco de dados vazio, conhecido como banco de dados de sinal de linha, permite que os usuários enviem e recebam emails enquanto o banco de dados com falha está sendo recuperado. Após a recuperação do banco de dados com falha, o banco de dados de sinal de linha e o banco de dados recuperado são trocados e, em seguida, os dados do banco de dados de sinal de linha são mesclados ao banco de dados recuperado.
Para mais informações, consulte Portabilidade de Sinal de Linha. Para obter instruções detalhadas sobre a realização de uma recuperação de sinal de linha, consulte Executar uma recuperação de sinal de discagem.
Voltar ao início
Proteção de dados nativa do Exchange
O Exchange 2010 inclui vários recursos novos e alterações importantes que, quando implantados e configurados corretamente, podem oferecer proteção de dados nativa que elimina a necessidade de fazer backups tradicionais de seus dados. O uso dos recursos de alta disponibilidade se integram ao Exchange 2010 para minimizar o tempo de inatividade e a perda de dados caso haja um desastre também podem reduzir o custo total de propriedade do sistema de mensagens. Ao combinar esses recursos a outros recursos integrados, como à Retenção de Documentos, as organizações podem reduzir ou eliminar sua dependência de backups pontuais tradicionais e reduzir os custos associados.
Além de determinar se o Exchange 2010 permitirá a você abandonar os backups pontuais tradicionais, também recomendamos que você avalie os custos de sua infraestrutura de backup atual. Considere os custos de perda de dados e tempo de inatividade de usuário final ao tentar se recuperar de um desastre usando sua infraestrutura de backup existente. Inclua também os custos com hardware, instalação e licenças, além do custo de gerenciamento associado à recuperação de dados e à manutenção de backups. Dependendo dos requisitos de sua organização, é bem provável que um ambiente puro do Exchange 2010 com pelo menos três cópias de banco de dados de caixa de correio ofereça um custo total de propriedade menor do que um com backups.
Os backups costumam ser usados nos cenários a seguir, e existem recursos do Exchange 2010 para atender a todas essas necessidades com eficiência e economia.
Recuperação de desastre Em caso de falha de um hardware ou software, várias cópias de banco de dados em um DAG possibilitam alta disponibilidade com failover rápido sem perda de dados. Isso elimina o tempo de inatividade do usuário final e a perda de produtividade resultante, um custo significativo de recuperação de um backup pontual anterior em disco ou em fita. Os DAGs podem ser estendidos até vários sites e fornecer resiliência diante de falhas no datacenter.
Recuperação de itens excluídos acidentalmente Historicamente, em uma situação na qual um usuário excluiu itens que posteriormente precisarão ser recuperados, isso envolvia a localização da mídia de backup na qual os dados que precisavam ser recuperados foram armazenados e, de alguma forma, a obtenção e fornecimento dos itens desejados ao usuário. Com a nova pasta Itens Recuperáveis no Exchange 2010 e a Diretiva de Retenção que pode ser aplicada a ela, é possível reter todos os dados excluídos e modificados durante um período especificado, para que a recuperação desses itens seja mais fácil e rápida. Isso reduz a carga sobre os administradores do Exchange e a assistência técnica de TI, permitindo aos usuários finais recuperarem itens excluídos acidentalmente por eles próprios, o que reduz a complexidade e os custos administrativos associados à recuperação de um único item. Para obter mais informações, consulte Diretiva e conformidade no envio e recebimento de mensagens, Informações sobre itens recuperáveis e Noções Básicas sobre Marcas e Diretivas de Retenção.
Armazenamento de dados a longo prazo Às vezes, os backups também têm uma finalidade de arquivo, e a fita costuma ser usada para preservar instantâneos pontuais de dados por longos períodos, segundo os requisitos de conformidade. Os novos recursos de arquivamento, de pesquisa em várias caixas de correio e de retenção de mensagens do Exchange 2010 fornecem um mecanismo para preservar dados de maneira acessível ao usuário final com eficiência durante longos períodos. Isso elimina restaurações caras a partir de fita e aumenta a produtividade do usuário final, permitindo a clientes avançados, como o Microsoft Outlook e o Outlook Web App, terem acesso aos dados antigos. Para obter mais informações, consulte Noções Básicas Sobre Arquivos Pessoais, Noções Básicas Sobre Pesquisa em Várias Caixas de Correio e Noções Básicas sobre Marcas e Diretivas de Retenção.
Instantâneo de banco de dados pontual Se uma cópia pontual anterior dos dados de caixa de correio for um requisito para a organização, o Exchange garantirá a possibilidade de criação de uma cópia com retardamento em um ambiente DAG. Isso pode ser útil no raro caso de haver um dano lógico que se replique pelos bancos de dados no DAG, o que resulta em uma necessidade de retornar a um momento anterior. Isso também poderá ser útil se um administrador excluir acidentalmente caixas de correio ou dados do usuário. A recuperação a partir de uma cópia com retardamento pode ser mais rápida do que a restauração a partir de um backup porque as cópias com retardamento não exigem um processo de cópia demorado do servidor de backup para o servidor do Exchange. Isso pode reduzir significativamente o custo total de propriedade, reduzindo o tempo de inatividade do usuário final.
Truncamento de log sem backups
Uma das funções realizadas ao final de um backup completo ou incremental com êxito é o truncamento dos arquivos de log da transação que não são mais necessários à recuperação do banco de dados. Se não estão sendo realizados backups, o truncamento de log não irá ocorrer. Para evitar um acúmulo de arquivos de log, você habilita o registro em log circular para os bancos de dados replicados. Ao integrar o registro em log circular à replicação contínua, você tem um novo tipo de registro em log circular chamado de CRCL (registro em log circular de replicação contínua), diferente do registro em log circular ESE. Enquanto o registro em log circular ESE é realizado e gerenciado pelo serviço de Armazenamento de Informações do Microsoft Exchange, o CRCL é realizado e gerenciado pelo Serviço de Replicação do Microsoft Exchange. Quando habilitado, o registro em log circular ESE não gera arquivos de log adicionais e, em vez disso, substitui o arquivo de log atual quando necessário. Contudo, em um ambiente de replicação contínua, os arquivos de log são necessários para envio e repetição. O resultado é que, ao ativar o CRCL, o arquivo de log atual não é substituído e são gerados arquivos de log fechados para o processo de envio e repetição de log. Especificamente, Serviço de Replicação do Microsoft Exchange gerencia o CRCL para que a continuidade dos logs seja mantida e os logs não sejam excluídos pelo excluidor de logs se ainda forem necessários para replicação.
Para obter informações sobre como habilitar e desabilitar o log circular, consulte Configurar Propriedades do Banco de Dados da Caixa de Correio.
Considerações sobre a implementação de proteção de dados nativa do Exchange
Existem motivos técnicos e vários problemas a serem considerados antes do uso dos recursos integrados ao Exchange 2010 em substituição a backups tradicionais. A lista a seguir inclui algumas dessas considerações, ainda que não seja extensa. Também pode haver considerações especiais ou exclusivas da sua organização. Considere os seguintes problemas:
Quantas cópias do banco de dados serão implantadas? É altamente recomendável implantar pelo menos três cópias de um banco de dados de caixa de correio antes de eliminar formas tradicionais de proteção do banco de dados, como backups RAID ou tradicionais baseados em VSS.
As metas para tempo e ponto de recuperação devem ser definidas claramente, e você deve estabelecer que o uso de um conjunto combinado de recursos internos em lugar dos backups tradicionais permite atingir essas metas.
Você deve determinar quantas cópias de cada banco de dados são necessárias para cobrir os vários cenários de falha diante dos quais o sistema foi projetado para se proteger.
Se você eliminar o uso de um DAG ou de algum de seus membros, isso garante custos suficientes para suportar uma solução de backup tradicional? Se a resposta for sim, essa solução irá melhorar os SLAs (contratos de nível de serviço) por objetivo de tempo ou de ponto de recuperação?
Será possível se dar ao luxo de perder uma cópia pontual se o membro DAG que hospeda a cópia apresentar uma falha que afete a cópia ou a integridade da cópia?
O Exchange 2010 permite implantar caixas de correio maiores, e o tamanho do banco de dados de caixa de correio máximo recomendado passou de 200 GB (gigabytes) no Exchange 2007 para 2 terabytes (quando três ou mais cópias de banco de dados de caixa de correio estiverem sendo usadas). Com base nas caixa de correio maiores que a maioria das organizações tende a implantar, qual será o objetivo quanto ao ponto de recuperação se você precisar repetir um grande número de arquivos de log ao ativar uma cópia de banco de dados ou uma cópia de banco de dados com retardamento?
Como você irá detectar e evitar o dano lógico em uma cópia de banco de dados ativa decorrente da replicação para as cópias passivas do banco de dados? Qual é seu plano de recuperação para essa situação? Com que frequência esse cenário ocorreu no passado? Se o dano lógico ocorrer com frequência na organização, será recomendável levar esse cenário em conta no projeto usando-se uma ou mais cópias com retardamento, com uma janela de intervalo de repetição suficiente para permitir a detecção e a ação diante do dano lógico quando ele ocorrer, mas antes desse dano ser replicado para outras cópias de banco de dados.
Voltar ao início
© 2010 Microsoft Corporation. Todos os direitos reservados.