Resiliência de dados do SharePoint e OneDrive no Microsoft 365
No Microsoft 365, o OneDrive baseia-se na plataforma de ficheiros do SharePoint. Neste artigo, apenas o SharePoint é utilizado para fazer referência a ambos os produtos. Este artigo também se aplica a quaisquer outros produtos que armazenem dados no SharePoint, como anexos na nuvem, ficheiros partilhados no Teams, gravações e transcrições de reuniões do Teams, componentes Loop e Quadros.
Existem dois recursos principais que compõem o armazenamento de conteúdos principais do SharePoint:
- Armazenamento de blobs: o conteúdo do utilizador que é carregado para o SharePoint é armazenado no Armazenamento do Azure. O SharePoint criou um plano de resiliência personalizado sobre o Armazenamento do Azure para garantir uma duplicação quase em tempo real de conteúdo de utilizador e um sistema verdadeiramente ativo/ativo.
- Metadados: os metadados sobre cada ficheiro são armazenados na Base de Dados SQL do Azure. O SQL do Azure oferece uma história completa de continuidade de negócio que o SharePoint utiliza e os detalhes são abordados mais à frente neste artigo.
O conjunto completo de controlos para garantir a resiliência dos dados é explicado em secções adicionais.
Resiliência do armazenamento de blobs
O SharePoint tem uma solução personalizada para armazenamento de dados de clientes no Armazenamento do Azure. Cada ficheiro é escrito simultaneamente numa região primária e secundária do datacenter. Se as escritas numa região do Azure falharem, a gravação do ficheiro falhará. Depois de os conteúdos serem escritos no Armazenamento do Azure, as somas de verificação são armazenadas separadamente com metadados e são utilizadas para garantir que a escrita consolidada é idêntica ao ficheiro original durante todas as leituras futuras. Esta mesma técnica é utilizada em todos os fluxos de trabalho para impedir a propagação de quaisquer danos que possam ocorrer. Em cada região, o Armazenamento Localmente Redundante (LRS) do Azure fornece um elevado nível de fiabilidade.
O SharePoint utiliza Append-Only armazenamento, o que significa que a Microsoft só pode adicionar novos blobs e nunca pode alterar os antigos até serem eliminados permanentemente. Este processo garante que os ficheiros não podem ser alterados ou danificados após uma gravação inicial, protegendo contra atacantes que tentam danificar versões antigas. Uma vez que a proteção da integridade da versão está incorporada na arquitetura do SharePoint, as versões anteriores do conteúdo do ficheiro podem ser obtidas, dependendo das definições individuais do administrador.
Os ambientes do SharePoint em ambos os datacenters podem aceder a contentores de armazenamento em ambas as regiões do Azure. Por motivos de desempenho, o contentor de armazenamento no mesmo datacenter local é sempre preferido. No entanto, os pedidos de leitura que não veem os resultados dentro de um limiar pretendido têm o mesmo conteúdo pedido pelo datacenter remoto para garantir que os dados estão sempre disponíveis.
Resiliência de metadados
Os metadados do SharePoint também são essenciais para aceder ao conteúdo do utilizador, uma vez que armazena a localização e as chaves de acesso aos conteúdos armazenados no Armazenamento do Azure. Estas bases de dados são armazenadas no SQL do Azure, que tem um extenso plano de continuidade de negócio.
O SharePoint utiliza o modelo de replicação fornecido pelo SQL do Azure e criou uma tecnologia de automatização proprietária para determinar se é necessária uma ativação pós-falha e para iniciar a operação, se necessário. Como tal, insere-se na categoria "Ativação pós-falha manual da base de dados" de uma perspetiva do SQL do Azure. As métricas mais recentes para a recuperação da base de dados SQL do Azure estão disponíveis aqui.
O SharePoint utiliza o sistema de cópia de segurança do SQL do Azure para ativar restauros para um ponto anterior no tempo (PITR) durante um máximo de 14 dias.
Ativação pós-falha automatizada
O SharePoint utiliza uma ativação pós-falha automatizada personalizada para minimizar o impacto na experiência do cliente quando ocorre um evento específico da localização. A automatização condicionada pela monitorização que deteta uma falha de um único ou vários componentes para além de determinados limiares resulta num redirecionamento automatizado da atividade de todos os utilizadores para fora do ambiente problemático e posterior para uma secundária quente. Uma ativação pós-falha faz com que os metadados e o armazenamento de computação sejam servidos inteiramente a partir do novo datacenter. Uma vez que o armazenamento de blobs é sempre totalmente ativo/ativo, não é necessária qualquer alteração para uma ativação pós-falha. O escalão de computação prefere o contentor de blobs mais próximo, mas utiliza localizações de armazenamento de blobs locais e remotas em qualquer altura para garantir a disponibilidade.
O SharePoint utiliza o serviço Azure Front Door para fornecer encaminhamento interno à rede da Microsoft. Esta configuração permite o redirecionamento de ativação pós-falha independente do DNS e reduz o efeito da colocação em cache do computador local. A maioria das operações de ativação pós-falha são transparentes para os utilizadores finais. Se existir uma ativação pós-falha, os clientes não precisam de efetuar alterações para manter o acesso ao serviço.
Controlo de Versões e Restauro de Ficheiros
Para bibliotecas de documentos recentemente criadas, o SharePoint tem a predefinição de 500 versões em cada ficheiro e pode ser configurado para reter mais versões, se assim o desejar. A IU não permite definir um valor inferior a 100 versões, mas é possível definir o sistema para armazenar menos versões através de APIs públicas. Para fiabilidade, não é recomendado qualquer valor inferior a 100 e pode resultar na perda inadvertida de dados por parte do utilizador.
Para obter mais informações sobre o controlo de versões, consulte Controlo de versões no SharePoint.
O Restauro de Ficheiros é a capacidade de voltar atrás no tempo em qualquer Biblioteca de Documentos no SharePoint para qualquer segundo tempo nos últimos 30 dias. Este processo pode ser utilizado para recuperar de ransomware, eliminações em massa, danos ou qualquer outro evento. Esta funcionalidade utiliza versões de ficheiro, pelo que a redução das versões predefinidas pode reduzir a eficácia deste restauro.
A funcionalidade Restauro de Ficheiros está documentada para o OneDrive e o SharePoint.
Eliminação, cópia de segurança e Restauro para Um Ponto Anterior no Tempo
O conteúdo de utilizador eliminado do SharePoint passa pelo fluxo de eliminação seguinte.
Os itens eliminados são retidos nas reciclagens durante um determinado período de tempo. Para o SharePoint, o tempo de retenção é de 93 dias. Começa quando elimina o item da localização original. Quando elimina o item da reciclagem do site, este é colocado na reciclagem da coleção de sites. Permanece lá durante o resto dos 93 dias e, em seguida, é eliminado permanentemente. Estão disponíveis mais informações sobre como utilizar a reciclagem nestas ligações:
Este processo é o fluxo de eliminação predefinido e não tem em conta as políticas ou etiquetas de retenção. Para obter mais informações, consulte Saiba mais sobre a retenção do SharePoint e do OneDrive.
Após a conclusão do pipeline de reciclagem de 93 dias, a eliminação ocorre independentemente dos Metadados e do Armazenamento de Blobs. Os metadados são removidos imediatamente da base de dados, o que torna o conteúdo ilegível, a menos que os metadados sejam restaurados a partir da cópia de segurança. O SharePoint mantém 14 dias de cópias de segurança de metadados. Estas cópias de segurança são feitas localmente quase em tempo real e, em seguida, enviadas para o armazenamento em contentores redundantes do Armazenamento do Azure, de acordo com a documentação no momento desta publicação, um agendamento de 5 a 10 minutos.
Além disso, os clientes também têm a opção de utilizar a Cópia de Segurança do Microsoft 365 para recuperação de dados. A Cópia de Segurança do Microsoft 365 oferece um tempo de proteção mais longo e fornece uma recuperação exclusivamente rápida de cenários comuns de continuidade de negócio e recuperação após desastre (BCDR), como ransomware ou substituição/eliminação acidental/maliciosa de conteúdos de funcionários. As proteções adicionais do cenário BCDR também são incorporadas diretamente no serviço, oferecendo um nível melhorado de proteção de dados.
Quando o conteúdo do Armazenamento de Blobs é eliminado, o SharePoint utiliza a funcionalidade de eliminação recuperável do Armazenamento de Blobs do Azure para proteger contra eliminação acidental ou maliciosa. Com esta funcionalidade, existe um total de 14 dias para restaurar o conteúdo antes de ser eliminado permanentemente. Além disso, como os blobs são imutáveis, a Microsoft pode sempre restaurar o estado de um ficheiro durante um período de 14 dias.
Observação
Embora as aplicações da Microsoft enviem conteúdos para a reciclagem para o processo padrão, o SharePoint fornece APIs que permitem ignorar a reciclagem e forçar uma eliminação imediata. Reveja as suas aplicações para garantir que isto só é feito quando necessário por motivos de conformidade.
Verificações de integridade
O SharePoint utiliza vários métodos para garantir a integridade dos blobs e metadados em todas as fases do ciclo de vida dos dados:
- Hash de ficheiro armazenado em metadados: o hash de todo o ficheiro é armazenado com metadados de ficheiro para garantir que a integridade dos dados ao nível do documento é mantida durante todas as operações
- Hash de blobs armazenado em metadados: cada item de blob armazena um hash do conteúdo encriptado para proteger contra danos no armazenamento subjacente do Azure.
- Tarefa de integridade dos dados: a cada 14 dias, cada site é analisado quanto à integridade ao listar itens na base de dados e ao compará-los com os blobs listados no armazenamento do Azure. A tarefa comunica todas as referências de blobs em falta de storage-blobs e pode obter esses blobs através da funcionalidade de eliminação recuperável do armazenamento do Azure , se necessário.