Escolher uma estratégia de recuperação de desastre para o SharePoint Server
APLICA-SE A:
2013 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 oferecem suporte a eles fornecem opções de configuração e recuperação de conteúdo que podem atender ao RTO (Objetivo de Tempo de Recuperação) e ao RPO (Objetivo de Ponto de Recuperação) necessários para sua empresa se houver 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 esse motivo, não incluímos informações sobre o planejamento de recuperação de desastres, mas focamos em opções para garantir que você possa recuperar seu farm do SharePoint Server em outro local.
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
Em um cenário de recuperação de desastre de espera fria, você se recupera configurando um novo farm em um novo local (preferencialmente usando uma implantação roteada) e restaurando backups. Ou você pode se recuperar restaurando o farm usando uma solução de backup, como System Center – Data Protection Manager (DPM). O DPM protege seus dados no nível do sistema operacional do computador e permite que você restaure 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, consulte Implantando o SharePoint Server com grupos de disponibilidade SQL Server Always On 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 você evite usar esse recurso em novas implantações. Faça planos para mudar aplicativos que usem esse recurso no momento. Em vez disso, use Always On Grupos de Disponibilidade.
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. É recomendável consultar seu fornecedor de SAN para determinar se você pode usar a replicação san para bancos de dados SQL ou outro mecanismo com suporte para fornecer o nível de disponibilidade de espera quente entre data centers. Observe que não há suporte para usar a replicação de SAN para servidores do SharePoint.
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?