Escolher uma estratégia de recuperação de desastre para o SharePoint Server
APLICA-SE A:
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
Definimos recuperação de desastre como a capacidade de recuperação de uma situação na qual o data center principal que hospeda um farm do SharePoint Server não consegue continuar a operar. Independentemente da natureza do evento e de sua causa, a interrupção do data center é significativa o suficiente para colocar em movimento as ações definidas no plano de recuperação de desastre da sua organização. Isso significa colocar um farm totalmente operacional em produção usando recursos computacionais localizados em um data center não afetado pelo evento.
O SharePoint Servers 2019, 2016, 2013 e os SQL Servers que os suportam fornecem opções de recuperação de conteúdos e configuração que podem cumprir o Objetivo de Tempo de Recuperação (RTO) e o Objetivo de Ponto de Recuperação (RPO) necessários para a sua empresa se ocorrer um desastre. Para saber mais sobre esses e outras conceitos de recuperação de desastre, confira Conceitos de alta disponibilidade e recuperação de desastre no SharePoint Server.
Introdução
Uma estratégia de recuperação de desastre para um farm do SharePoint Server deve ser suficiente para atender aos requisitos comerciais da sua organização, que são normalmente expressos por meio de duas medidas: Objetivo de tempo de recuperação (RTO) e Objetivo de ponto de recuperação (RPO). Os requisitos de RTO e de RPO derivam da determinação do custo de tempo de inatividade para a organização caso ocorra um desastre.
Importante
[!IMPORTANTE] Como prática recomendada, recomendamos que você identifique e quantifique claramente o RTO e o RPO da sua organização antes de desenvolver uma estratégia de recuperação e de implementar uma solução técnica. Foco no que é necessário, não em como fazer.
Os custos de tempo de inatividade variam significativamente entre as indústrias, especialmente devido aos diferentes efeitos do tempo de inatividade. O tamanho da empresa é o fator mais óbvio. Entretanto, esse não é o único. A definição de uma medida significa estabelecer a natureza e das implicações da falha. Reduzida ao nível mais simples, uma falha de um aplicativo crítico poderia levar aos seguintes tipos de perdas:
Perda do serviço de aplicativo. O efeito do tempo de inatividade varia com o aplicativo e com a empresa.
Perda de dados. A potencial perda de dados devido a uma interrupção do sistema pode ter um significativo impacto legal e financeiro.
A maioria das organizações incorrerá em um custo de inatividade de ambos os tipos anteriores de perda, mas a natureza da empresa determinará que tipo de perda terá o maior efeito. O artigo a seguir, escrito por Chris Preimesberger na eWEEK, realça o efeito financeiro da inatividade do data center. A inatividade de TI não planejada pode custar US$ 5 mil por minuto: relatório.
Na maioria dos cenários, o Produtos do SharePoint é um dos diversos aplicativos que devem ser recuperados no caso do desligamento de um data center que se qualifica como um desastre. Por este motivo, não incluímos informações sobre o planeamento da recuperação após desastre, mas concentramo-nos nas opções para garantir que consegue recuperar o farm do SharePoint Server noutra localização.
Independentemente do tipo e da dimensão de um desastre, a recuperação envolve o uso de um data center em espera para o qual o farm poderá ser recuperado.
Opções de recuperação do data center em espera
Os data centers em espera são necessários onde sistemas e backups locais redundantes não conseguem se recuperar da interrupção no data center principal. O tempo e o esforço imediato para fazer um farm substituto funcionar em um local diferente é quase sempre conhecido como espera ativa, espera passiva e espera a frio. Nossas definições para esses data centers de recuperação do farm são as seguintes:
Espera a frio. Um data center secundário que podem oferecer disponibilidade em horas ou em dias.
Espera passiva. Um data center secundário que pode oferecer disponibilidade em minutos ou em horas.
Espera ativa. Um data center secundário que pode oferecer disponibilidade em segundos ou em minutos.
Cada um desses data centers em espera tem características e requisitos específicos, além de um custo associado para operá-los e mantê-los.
Estratégia de recuperação de desastre a frio: uma empresa envia backups para dar suporte à recuperação bare-metal para armazenamento local e regional fora do local regularmente, e tem contratos feitos para aluguel de servidores de emergência em outra região.
Pros: Quase sempre a opção de manutenção mais barata, operacionalmente. Quase sempre, uma opção cara para a recuperação, uma vez que exige que servidores físicos sejam configurados corretamente após a ocorrência de um desastre.
Contras: a opção de recuperação mais lenta.
Criar uma estratégia de espera para recuperação de desastres com o Azure Site Recovery.
Pros: Quase sempre, a recuperação é muito barata, já que um farm de servidores virtual pode exigir pouca configuração na recuperação.
Cons: Pode ser muito caro e demorado para manter.
Estratégia de recuperação de desastre de espera ativa: uma empresa executa vários data centers, mas serve conteúdo e serviços por meio de apenas um data center.
Pros: Quase sempre, a recuperação é bem rápida.
Cons: Pode ser muito caro para configurar e de manter.
Importante
Não importa qual das soluções de recuperação de desastre anteriores você decida aplicar, é provável que haverá alguma perda de dados.
Recuperação em espera a frio
Num cenário de recuperação após desastre de reserva a frio, pode recuperar ao configurar um novo farm numa nova localização (de preferência através de uma implementação com script) e ao restaurar cópias de segurança. Em alternativa, pode recuperar ao restaurar o farm com uma solução de cópia de segurança, como o System Center – Data Protection Manager (DPM). O DPM protege os seus dados ao nível do sistema operativo do computador e permite-lhe restaurar cada servidor individualmente. Este artigo não contém instruções detalhadas sobre a forma de como criar e recuperarem cenários de espera a frio. Para saber mais, veja:
Recuperação de espera passiva
Em um cenário de recuperação de desastre de espera passiva, você cria um ambiente de espera passiva criando um farm duplicado no data center alternativo e garantir que seja atualizado regularmente usando backups completos e incrementais do farm principal.
Ambientes de espera passiva virtuais
A virtualização oferece uma opção funcional e barata para uma solução de recuperação de espera passiva. Você pode usar o Hyper-V como uma solução interna ou o Azure como uma solução hospedada para fornecer a infraestrutura necessária para a recuperação. Para obter mais informações, veja Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure (Implementar o SharePoint Server com Grupos de Disponibilidade AlwaysOn do SQL Server no Azure)
Recuperação de espera ativa
Em um cenário de recuperação de desastre ativo, você pode configurar um farm de failover no data center em espera de forma que ele possa assumir operações de produção quase imediatamente depois que o farm principal ficar offline. Um ambiente com um farm de failover separado tem as seguintes características:
Um banco de dados de configuração separado e um banco de dados de conteúdo da site da Administração Central do SharePoint devem ser mantidos no farm de failover.
Todas as personalizações devem ser implantadas em ambos os farms.
Dica
Há uma consistência entre os dois farms e, para reduzir a possibilidade de erro, recomendamos que você use a implantação com script para criar o farm principal e o de failover usando as mesmas configurações e personalizações.
As atualizações de software do sistema operacional, do SQL Server e do SharePoint Server devem ser aplicadas a ambos os farms, para manter uma configuração consistente entre ambos os farms.
Você pode copiar bancos de dados de conteúdo do SharePoint Server para o farm de failover usando espelhamento assíncrono, confirmação assíncrona em uma réplica de grupo de disponibilidade ou o envio de logs.
Observação
O espelhamento do SQL Server só pode ser usada para copiar bancos de dados para um servidor único espelhado, mas você pode enviar o log para vários servidores secundários.
O recurso de espelhamento de banco de dados do SQL Server será removido nas versões futuras. Recomendamos que evite utilizar esta funcionalidade em novas implementações. Faça planos para mudar aplicativos que usem esse recurso no momento. Em alternativa, utilize Grupos de Disponibilidade AlwaysOn.
Os aplicativos de serviço variam na forma como podem enviar logs para um farm. Para obter mais informações, consulte Redundância de aplicativo de serviço, posteriormente neste artigo.
A topologia de farm de espera ativa pode ser repetida em mais de um data center, desde que você configure o envio de logs do SQL Server para um ou mais data centers adicionais.
Importante
[!IMPORTANTE] A largura de banda e a latência de rede disponíveis são as principais considerações quando você estiver usando uma abordagem de failover para a recuperação de desastre. Recomendamos que consulte o fornecedor de SAN para determinar se pode utilizar a replicação SAN para bases de dados SQL ou outro mecanismo suportado para fornecer o nível de disponibilidade de reserva frequente nos datacenters. Tenha em atenção que a utilização da replicação SAN para servidores do SharePoint não é suportada.
Redundância de aplicativo de serviço
Para fornecer disponibilidade entre data centers para aplicativos de serviço, recomendamos que para os serviços que puderem ser executados entre farms, você execute um farm de serviços separado que possa ser acessado dos data centers principal e secundário.
Para os serviços que não possam ser atualizados entre farms, e para fornecer disponibilidade para o próprio farm de serviços, a estratégia para fornecer redundância entre data centers para um aplicativo de serviço varia. A estratégia empregada depende de:
Haver um valor comercial na execução do aplicativo de serviço no farm de recuperação de desastre onde não está sendo usado.
Os bancos de dados associados ao aplicativo de serviço podem enviar logs, podem ser espelhados assincronamente ou replicados usando a confirmação assíncrona.
O aplicativo de serviço pode ser executado em bancos de dados somente leitura.
Revise o artigo Suporte para as opções de alta disponibilidade e recuperação de desastres para bancos de dados do SharePoint antes de projetar uma solução de recuperação de desastre que use um data center em espera ativa ou passiva.
Requisitos do sistema para recuperação
Em um cenário ideal, os componentes e os sistemas de failover correspondem aos componentes e sistemas principais de todas as maneiras: plataforma, hardware e número de servidores. No mínimo, o ambiente de failover deverá ser capaz de manipular o tráfego esperado durante o failover. Tenha em mente que somente um subconjunto poderá ter de ser servido pelo site de failover. Os sistemas devem corresponder em pelo menos o seguinte:
Versão do sistema operacional e todas as atualizações
Versões e todas as atualizações do SQL Server
Versões e todas as atualizações do SharePoint Server
Além dos requisitos anteriores, o tempo de recuperação do farm também será afetado pela disponibilidade de instalações e de componentes de infraestrutura. Verifique se os seguintes requisitos são atendidos:
Energia, resfriamento, rede, diretório e SMTP são totalmente redundantes
Escolha um mecanismo de alternância; seja DNS ou balanceamento de carga de hardware, que atenda às suas necessidades.
Confira também
Conceitos
Conceitos de alta disponibilidade e recuperação de desastre no SharePoint Server
Outros recursos
Que cargas de trabalho podem ser protegidas pelo Azure Site Recovery?