Antes de implementar as estratégias de backup e restauração VSS, reveja os requisitos de segurança e outras orientações que são específicas para seu ambiente. Considere como gerenciar a política do Tivoli Storage Manager e defina as opções e preferências de configuração disponíveis do Data Protection para Exchange.
Requisitos de segurança
O Data Protection para Exchange deve ser registrado para o Servidor do Tivoli Storage Manager e utilizar o nome de nó e a senha apropriados ao se conectar com o Servidor do Tivoli Storage Manager. Requisitos de segurança padrão do Tivoli Storage Manager aplicam-se ao Data Protection para Exchange.
Requisitos de Segurança para Tarefas do Data Protection para
Exchange restauração da caixa de correio no Exchange Server
Para executar tarefas de restauração da caixa de correio individual, o Data Protection para Exchange requer que os usuários de logon do Exchange tenham permissões de Role Based Access Control (RBAC) para acessar as caixas de correio e para executar os cmdlets do Exchange Powershell para operações de restauração. As permissões do RBAC geralmente são configuradas com cmdlets do Exchange Powershell em um processo de configuração do Microsoft Exchange. Para obter mais informações, consulte Entendendo o Controle de Acesso Baseado na Função. Se você estiver autorizado pela política de segurança em sua organização, inclua os usuários em grupos ou subgrupos da função de Gerenciamento de Organização do Exchange. Os usuários no grupo ou subgrupos de funções Gerenciamento de Organização do Exchange possuem privilégios suficientes para concluir idealmente as operações de restauração de caixa de correio. Os usuários que não estiverem no grupo ou subgrupos de função do Gerenciamento de Organização do Exchange poderão ter um desempenho mais lento.
Em resumo, deve-se definir um conjunto mínimo de funções de gerenciamento e escopo de função para o usuário do Exchange.
v Funções de gerenciamento: “Active Directory Permissions”, “Databases”, “ Disaster Recovery”, “Mailbox Import Export”, “View-Only Configuration” e “View-Only Recipients”.
Um cmdlet típico do Exchange Powershell que configura permissões de RBAC é o seguinte:
New-RoleGroup -Name "My Admins" -Roles "Active Directory Permissions", "Databases", "Disaster Recovery", "Mailbox Import Export", "View-Only Configuration",
"View-Only Recipients" -Members operator1
O exemplo acima cria um novo grupo, My Admins, com funções mínimas para executar o Data Protection para Exchange e designa um usuário operator1 para esse grupo. O usuário operator1 pode executar o Data Protection para Exchange, porém com privilégios limitados do Exchange, por exemplo, o usuário não pode criar ou remover uma caixa de correio do usuário.
v Escopo de função de gerenciamento. Certifique-se de que os seguintes objetos do Exchange estejam dentro do escopo de função do gerenciamento do usuário de logon do Exchange: | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
– O Exchange Server que contém os dados necessários
– O banco de dados de recuperação que o Data Protection para Exchange cria – O banco de dados que contém a caixa de correio ativa
– O banco de dados que contém a caixa de correio ativa do usuário que executa a operação de restauração
v Verifique se o usuário do Exchange é membro de um grupo do administrador local e se possui uma caixa de correio do Exchange ativa no domínio.
Por padrão, o Windows inclui o grupo Exchange Organization Administrators em outros grupos de segurança, incluindo o grupo Administradores local. Para usuários do Exchange que não forem membros do grupo Gerenciamento de Organização do Exchange, deve-se incluir manualmente a conta do usuário no grupo Administradores local utilizando a ferramenta Usuários e Grupos Locais no computador do membro de domínio (selecione Ferramentas Administrativas > Gerenciamento de Computador > Ferramenta de Usuários e Grupos Locais). Em um computador do controlador de domínio que não tenha um grupo Administradores local ou a ferramenta Usuários e Grupos Locais, inclua manualmente a conta do usuário no grupo Administradores no domínio (selecione Ferramentas Administrativas > Ferramenta Usuários e Computadores do Active Directory).
Requisitos de Segurança para Backup do Data Protection para
Exchange e Tarefas de Restauração
Os usuários do Exchange que têm as permissões de RBAC necessárias para concluir operações de restauração da caixa de correio individual também podem fazer backup e restaurar bancos de dados por padrão. As operações de backup e restauração de nível de banco de dados requerem menos permissão do que as operações de restauração de caixa de correio individuais.
Requisitos de backup e restauração de dados
Antes de executar tarefas de backup e restauração, revise os pré-requisitos a seguir. Para proteger dados do Microsoft Exchange Server 2010 e 2013, verifique se seu ambiente está configurado corretamente, como a seguir:
Requisitos do Microsoft Exchange Server 2010 e 2013
O Data Protection para Exchange requer que você tenha privilégios de Administrador local.
A associação no grupo de Gerenciamento da Organização não é necessária porque você pode não querer conceder permissões de grupo de
Gerenciamento da Organização para todos os operadores de backup e restauração do Exchange. Em vez disso, é possível definir funções de Controle de Acesso Baseado na Função (RBAC) customizadas e o escopo da função de gerenciamento, para que os usuários do Exchange possam executar apenas operações limitadas dentro de um escopo limitado. Ao concluir os backups de dados, o tamanho do arquivo de banco de dados do Exchange pode aumentar, devido ao aumento das confirmações de bancos de dados que serão acionadas pelas operações de backup. Requisitos do Microsoft Exchange Server 2013
Para as operações de restauração de caixa de correio do Exchange Server 2013, os clientes do MAPI precisam usar o RPC sobre HTTPS (também conhecido como Outlook Anywhere). A Microsoft não suporta RPC sobre HTTP. | | | | | | | | | | | | | | | | | | | | | | | | | |
v Use o Exchange 2013 CU2 ou versões mais recentes e faça o download do MAPI correto. Estes requisitos de software estão documentados na nota técnica Requisitos de Hardware e Software. Essa nota técnica está disponível nesta página da Web:TSM for Mail - Todos os Documentos de Requisitos. Siga o link para a nota técnica de requisitos para seu nível de liberação ou atualização específico.
v (Opcional) Use MFCMapi para verificar sua configuração de MAPI. Para concluir esta verificação, siga o link para esta postagem do blog: Como usar o mesmo perfil de MAPI para se conectar ao Exchange 2013 e as versões de legado do Exchange Server. Se MFCMapi não puder se conectar ao Exchange, o Data Protection for Microsoft Exchange não poderá se conectar ao Exchange.
v No ambiente do Exchange, verifique se é possível abrir a caixa de correio do administrador no Outlook ou no Outlook Web App (OWA). v No ambiente do Exchange, verifique se é possível abrir a caixa de
correio de destino no Outlook ou no Outlook Web App (OWA). Se o seu ambiente estiver configurado corretamente, as operações de restauração de caixa de correio funcionam da mesma maneira que com versões anteriores do Microsoft Exchange Server. Para obter mais informações, consulte os tópicos de informações sobre resolução de problemas.
Planejamento de backup de dados
As características de backups do VSS podem afetar as tarefas de gerenciamento de backup. Ao decidir suas estratégias de backup, lembre-se das seguintes diretrizes de backup do VSS.
Tarefas relacionadas:
“Fazendo Backup dos Dados do Exchange” na página 109
Características de Backup do VSS
Os backups podem ser armazenados em shadow volume local, armazenamento do Servidor do Tivoli Storage Manager ou ambos os locais. Os backups para
armazenamento do Servidor do Tivoli Storage Manager podem ser transferidos para outro sistema como recurso de ajuda para servidores de produção. Além disso, os backups podem ser restaurados para arquivos simples sem o
envolvimento do Exchange Server.
Os backups fornecem uma função de verificação de integridade de banco de dados do Exchange Server, mas não fornecem uma função de zeramento do banco de dados do Exchange Server. Tipos de backups completos, de cópia, incrementais e diferenciados são suportados. As configurações de política diferentes podem ser definidas para cada local de backup e tipo de backup (FULL ou COPY).
Os bancos de dados DAG do Exchange Server podem ser submetidos a backup com um nome de nó do DAG comum, independentemente do membro do DAG que executar o backup. O backup pode ser criado a partir de uma cópia ativa ou passiva. Ao fazer o backup de dados para um nó comum, os backups são gerenciados por uma política comum e o usuário pode restaurar o backup para qualquer Exchange Server que esteja no mesmo nó de DAG.
Requisitos do Backup VSS
Planeje sua estratégia do Backup VSS para otimizar o desempenho de suas operações de backup e para evitar possíveis problemas.
Considere os requisitos a seguir ao planejar backups do VSS:
v Ao executar operações do VSS, assegure-se de ter pelo menos 200 MB de espaço livre em disco no Windows System Drive. Este espaço é usado para armazenar os arquivos de metadados para o Data Protection para Exchange.
v Utilize LUNs de hardware individuais para arquivos de log e do sistema. v Utilize LUNs de hardware individuais para arquivos de banco de dados. v Utilize discos básicos.
v Se planejar manter os backups de captura instantânea do VSS apenas nos shadow volume locais, assegure-se de entender as opções de implementação e de configuração de seu provedor de hardware do VSS.
Por exemplo, se seu hardware do VSS suportar um mecanismo de captura instantânea de cópia completa versus captura instantânea de copy-on-write (COW), as implementações de tipo de cópia completa terão maiores requisitos de armazenamento em disco. No entanto, implementações do tipo de cópia completa não dependem do volume original para restaurar os dados e são menos arriscadas. As implementações de COW requerem muito menos
armazenamento em disco, porém dependem totalmente do volume original para restaurar os dados.
v Se executar backups do VSS paralelos, coordene o horário de início dos backups em pelo menos dez minutos. Este intervalo assegura que as operações de captura instantânea não se sobreponham.
v Se executar backups do VSS paralelos, configure os backups de instância paralelos para que as capturas instantâneas dos mesmos volumes não sejam criadas.
v Se executar backups do VSS paralelos, assegure-se de que os backups paralelos não criem uma captura instantânea do mesmo LUN.
v Não coloque vários volumes na mesma LUN. Configure um volume único, uma partição única e um LUN único como um para um.
v Não configure a opção ASNODENAME no arquivo dsm.opt ao usar o Data Protection para Exchange. A configuração de ASNODENAME pode fazer com que as operações de backups de dados do VSS e de restauração do VSS falhem.
Estratégias de backup do VSS
Pode-se optar por implementar diferentes estratégias de backup, dependendo dos requisitos do tráfego de rede, do planejamento de backup e dos tempos de restauração aceitáveis.
Ao considerar suas estratégias de backup, siga estas diretrizes: v Não implemente backups incrementais e diferenciais juntos.
v Se escolher uma estratégia que envolva backups incrementais ou diferenciados, você deve desativar a criação de log circular nos bancos de dados do Exchange Server.
v Considere aplicar tecnologias de replicação de banco de dados do Database Availability Group (DAG). Consulte a documentação da Microsoft para obter mais detalhes.
| | |
Para outra estratégia de backup do DAG, configure todos os membros do DAG para fazerem backup de todas as cópias de banco de dados. Use os sinalizadores /MINIMUMBACKUPINTERVALe /PREFERDAGPASSIVE.
Nota: Compreenda todos os aspectos da recuperação de desastres do Exchange Server e as recomendações de backup que a Microsoft fornece. Para obter mais informações, consulte a documentação do Exchange Server.
Apenas Backups Completos
Uma estratégia de backup completa é a melhor para Exchange Servers que sejam relativamente pequenos já que cada backup contém dados suficientes para restaurar o banco de dados inteiro.
Cada backup leva mais tempo para ser executado. No entanto, o processo de restauração é mais eficiente pois somente o backup completo mais recente (ou outro apropriado) é restaurado.
Backup Completo mais Backups Incrementais
Backup completo mais backups incrementais são uma estratégia normalmente utilizada quando o planejamento de backup normal ou a capacidade da rede não pode suportar um backup completo todas as vezes.
Nesses casos, pode-se implementar um backup completo periódico seguido por uma série de backups incrementais para minimizar o impacto sobre o
planejamento de backup e tráfego de rede durante os períodos de pico de uso. Por exemplo, é possível planejar backups completos no fim de semana e backups incrementais durante a semana. É possível implementar backups completos durante os períodos de pouco uso e quando o aumento no tráfego da rede puder ser tolerado. Entretanto, o processo de restauração se torna mais complexo porque um backup completo e backups incrementais subsequentes devem ser restaurados. Além disso, as transações dentro dos logs devem ser aplicadas, o que aumenta o tempo de processamento. O processo de recuperação demora mais tempo, conforme mais transações são aplicadas.
Se utilizar essa estratégia de backup, modifique as políticas de gerenciamento de armazenamento do Tivoli Storage Manager para assegurar que todos os backups incrementais sejam colocados no Servidor do Tivoli Storage Manager. Desta maneira, pode-se melhorar o desempenho da restauração de dados ao reduzir o número de montagens de mídia que são necessárias para restaurar uma série de backups incrementais.
Backup Completo mais Diferenciados
As operações de restauração de dados são mais facilmente implementadas com esta estratégia do que com a estratégia de backup completa mais incremental. Esta estratégia poderá ser útil se o seu planejamento de backup e a capacidade da rede puderem facilitar o backup de todos os logs de transações que se acumulam entre os backups completos. Essa estratégia requer que apenas um backup diferenciado mais o último backup completo sejam transferidos para realizar uma restauração. No entanto, a mesma quantidade de dados deve ser transferida na imagem diferenciado, como na série de backups incrementais.
Portanto, uma política de backup completo mais backup diferencial aumenta o tráfego na rede e o uso do armazenamento do Tivoli Storage Manager. Esta política assume que os backups diferenciados sejam processados com a mesma frequência que os backups incrementais.
| | |
Considere cuidadosamente as potenciais vantagens e se é possível justificar os recursos adicionais que são necessários para reenviar todos os logs de transações anteriores com cada backup diferenciado subsequente.
Fazer Backup do Armazenamento do Tivoli Storage Manager
Versus Fazer Backup de shadow volumes locais
Ao determinar a política para seus backups, considere as diferenças a seguir entre o backup de dados para o armazenamento do Tivoli Storage Manager versus discos VSS.
Armazenamento do Tivoli Storage Manager
Uma operação de backup do Tivoli Storage Manager armazena os dados cujo backup foi feito no armazenamento do Servidor do Tivoli Storage Manager. Embora este tipo de backup geralmente leve mais tempo para processar que um backup para shadow volume locais, um backup do Tivoli Storage Manager é necessário quando um armazenamento de longo prazo é necessário. Salvar dados do Exchange na fita para fins de arquivo é um exemplo de necessidade de armazenamento de longo prazo. Os backups do Tivoli Storage Manager também são necessários para situações de recuperação de desastre quando os discos
utilizados para backups locais não estão disponíveis. Ao manter diversas cópias de backup em armazenamento do Servidor do Tivoli Storage Manager, uma cópia point-in-time fica disponível se os backups nos shadow volumes locais forem corrompidos ou excluídos.
Os backups para armazenamento do Servidor do Tivoli Storage Manager estão sujeitos ao tempo, não por versões.
Volumes Shadow Locais
Deve haver espaço de armazenamento local suficiente disponível nos volumes shadow locais para que uma estratégia de backup VSS seja bem-sucedida. Para acomodar suas operações de backup do Data Protection para Exchange, assegure-se de que o espaço de armazenamento disponível suficiente seja designado aos volumes. Os recursos de ambiente e armazenamento também impactam quantas versões de backup são mantidas em shadow volumes locais (para restauração rápida de VSS e restauração instantânea de VSS) e quantas versões de backup são mantidas em Servidor do Tivoli Storage Manager
(Restauração VSS e armazenamento de longo prazo). Crie diferentes conjuntos de políticas para backups para ambos os shadow volumes locais e para
armazenamento do Servidor do Tivoli Storage Manager. Se utilizar um provedor de VSS diferente do Windows VSS System Provider, assegure-se de revisar a documentação para esse provedor específico do VSS.
Pode-se gerenciar backups em shadow volumes locais por tempo e versões. No entanto, como as capturas instantâneas locais são criadas com mais frequência, e devido às limitações de fornecimento e de espaço de armazenamento VSS
aplicadas, é mais eficiente basear a política de backups locais nos limites de versão. Além disso, em ambientes DAG, todos os membros do DAG devem utilizar a mesma política local do VSS.
Atenção: Para backups de banco de dados anteriores, é possível verificar se um backup é válido sem restaurar o backup fisicamente. Antes de restaurar o backup de banco de dados anterior, é possível executar a operação de restauração com a opção Apenas Verificar no Console de Gerenciamento da Microsoft (MMC). Como alternativa, é possível usar a opção /VERIFYOnly com o comando restore na interface de linha de comandos.
Diretrizes de backup do Database Availability Group
É possível criar um backup a partir de uma cópia ativa ou a partir de qualquer cópia passiva em um Exchange Server Database Availability Group (DAG). Ao usar o Data Protection para Exchange com os DAGs, considere as seguintes diretrizes.
v Use um membro do DAG para restaurar backups de banco de dados do DAG. v Assegure-se de que a mesma política do VSS se aplique a todos os membros do
DAG.
v Certifique-se de que o primeiro backup seja um backup FULL ao mover os backups para backups do membro do DAG.
v Certifique-se de que os backups anteriores sejam excluídos manualmente após mover os backups para os backups do membro do DAG, assumindo que esses backups não são mais necessários.
v Assegure-se de que os backups LOCAL sejam restaurados e expirados apenas no servidor Exchange no qual o backup é criado.
v Certifique-se de que as operações de restauração do banco de dados sejam executadas apenas no database. ativo.
O recurso de alta disponibilidade de backups do Database Availability Group (DAG) melhora os backups de dados e a recuperação de dados do Exchange Server. Ao fazer backup de dados em um ambiente DAG, siga estas diretrizes: v Para diminuir a carga no servidor do Exchange de produção, especifique que os
backups são criados de uma cópia do banco de dados passivo. Se nenhuma cópia passiva estiver disponível, o backup será criado a partir da cópia ativa do banco de dados. Para especificar que os backups sejam criados de uma cópia do banco de dados passivo, inclua o /PREFERDAGPASSIVE em um comando de backup.
v Use estas opções de backup da linha de comandos para excluir determinados bancos de dados do processamento de backup: /EXCLUDEDAGPASSIVE,
/EXCLUDEDAGACTIVEou /EXCLUDENONDAGDBS.
v Se pelo menos duas cópias funcionais de um banco de dados (um ativo e outra passiva) existirem em um ambiente DAG, será possível ignorar a verificação de integridade dos arquivos de banco de dados e de log usando as opções
/SKIPINTEGRITYCHECKcom o comando backup.
Atenção: Se você efetuar diretamente bypass da verificação de integridade