O Ops Manager pode armazenar backup, incluindo snapshot e oplogs, em um armazenamento de objetos compatível com S3 ou S3gravando dados de backup como blocos em um bucket S3 e rastreando metadados no banco de dados de aplicativo do Ops Manager. Com backups S3 imutáveis, o MongoDB Ops Manager integra-se com o S3 Bloqueio de Objeto ou um equivalente para fornecer as seguintes funcionalidades:
Armazene os dados de backup e os metadados de backup juntos no bucket S3.
Proteja os objetos de backup contra exclusão ou modificação até que um período de retenção definido expire, imposto pelo armazenar de objetos.
Importe uma cadeia de restauração point-in-time completa, snapshot e oplog juntos, de um bucket com Object-Lock habilitado para uma implantação do MongoDB Ops Manager nova ou reconstruída para recuperação de desastre ou migração.
Use esse recurso para proteger backups contra exclusão maliciosa ou acidental, como ataques de Ranamson ou erro do operador. Você pode restaurar backups em uma nova instância do Ops Manager usando apenas o que você armazena no S3.
This guide covers immutable S3 backups for Ops Manager deployments that you install and manage directly on a host. If you deploy Ops Manager using the MongoDB Controllers for Kubernetes Operator (MCK), see the Ops Manager resource specification example.
Importante
O MongoDB Ops Manager oferece suporte a snapshot S3 imutável a partir da versão 8.0.19. Os oplogs S3 imutáveis, que estendem essa proteção para oferecer suporte à restauração point-in-time de um backup totalmente imutável e importável, exigem a versão 9.0 ou 8.0.28.
Como funcionam os backups imutáveis do S3
Depois de configurar um armazenamento de snapshots S3 com um bucket habilitado para Object-Lock e habilitar backups imutáveis:
O Ops Manager grava os blocos de snapshot e os metadados necessários para a restauração no bucket S3, em vez de manter os metadados apenas no banco de dados de aplicativo Ops Manager.
Se configurado, o Ops Manager estende a retenção do bloqueio de objeto para cada snapshot para que o armazenamento de objeto evite a exclusão ou modificação antes que a janela de retenção da tarefa de backup termine.
O Ops Manager pode descobrir e importar esses snapshots imutáveis de um bucket pré-preenchido para outra instância do Ops Manager lendo apenas o que o bucket S3 armazena.
Se você também configurar um armazenar oplog S3 com o Bloqueio de Objeto ativado:
O Ops Manager grava fatias de oplog e os metadados necessários para restaurar no bucket do S3 oplog armazenar, da mesma forma que faz para os dados de snapshot.
O MongoDB Agent rastreia apenas entradas de oplog confirmadas pela maioria para essa tarefa de backup, portanto, o MongoDB Ops Manager nunca faz backup de uma entrada de oplog que um rollback posterior possa remover.
O MongoDB Ops Manager pode descobrir e importar esses oplogs imutáveis, juntamente com um snapshot imutável importado, para outra instância do MongoDB Ops Manager para oferecer suporte à restauração point-in-time a partir do backup importado.
Pré-requisitos
Para usar backups imutáveis S3, certifique-se de ter o seguinte:
MongoDB Ops Manager 8.0.19 ou posterior para snapshots imutáveis. Oplogs imutáveis também exigem a versão 9.0 ou 8.0.28.
armazenamento de snapshots do S3 (blockstore) configurado no Ops Manager. Os snapshots imutáveis suportam apenas armazenamentos de snapshots baseados em S3, não blockstores do MongoDB ou armazenamentos de snapshots do sistema de arquivos.
Sistema para armazenar objetos que suporte Bloqueio de Objetos, como AWS S3 ou dispositivos compatíveis, com Bloqueio de Objetos habilitado no bucket que você usa para o armazenamento. A maioria dos provedores S3 exige o versionamento de objetos para que o Bloqueio de Objetos funcione, e alguns provedores permitem o Bloqueio de Objetos apenas durante a criação do bucket.
Standard backup requirements, such as a MongoDB Agent with backup enabled on suitable nodes and an oplog (operations log) store for PITR.
Um bucket S3 com Object Lock habilitado para seu armazenamento de snapshots. O bucket não precisa ser novo e não precisa ser dedicado a esse armazenamento, embora um bucket dedicado seja recomendado. Você não pode habilitar o bloqueio de objeto na configuração de um armazenamento de snapshots S3 existente no MongoDB Ops Manager alterando suas configurações. Você deve configurar um novo armazenamento de snapshots S3 que aponte para um bucket com Object Lock habilitado.
Se você usar oplog imutáveis: um bucket S3 com versionamento e bloqueio de objetos habilitado para seu armazenamento de oplog. O bucket não precisa ser novo e não precisa ser dedicado a esse armazenamento, embora um bucket dedicado seja recomendado. Você não pode habilitar o bloqueio de objeto na configuração de um armazenar de oplog S3 existente no Ops Manager alterando suas configurações. Você deve configurar um novo recurso para armazenar oplog S3 que tenha como ponto de destino um bucket com versionamento e bloqueio de objeto habilitados.
Considerações
Ao planejar backups imutáveis do S3, considere os seguintes itens:
Sem imutabilidade retroativa. O Ops Manager protege apenas snapshots gravados em um bucket com o Object Lock depois que você ativa o backup imutável. O Ops Manager não aplica o Bloqueio de Objeto a objetos de snapshot existentes.
Configuração do bloqueio de objeto. O Ops Manager não fornece imutabilidade para buckets S3 que não são compatíveis com bloqueio de objeto. Você deve configurar o bloqueio de objeto no bucket separadamente. Configurar as configurações de bloqueio de objeto no Ops Manager ou atualizar as configurações de bucket após a criação não habilita o bloqueio de objeto no bucket.
Nenhuma migração automática de dados existentes. O recurso Migrar backup entre armazenamentos S3 permite alterar o armazenamento de snapshots S3 que uma tarefa de backup usa para snapshots futuros. Ele não copia nem move dados de snapshot existentes entre blocos.
Retenção e bloqueio de objetos em armazenamentos gerenciados. Quando um snapshot expira de acordo com a política de retenção do tarefa de backup , o Ops Manager para de expô-lo e tenta excluir objetos relacionados. O Ops Manager pode excluir os objetos somente após o período de retenção do bloqueio de objeto expirar.
Retenção em stores importadas. O MongoDB Ops Manager nunca exclui dados do bucket S3 do qual você importou. O MongoDB Ops Manager pode excluir os metadados que importou para seu próprio banco de dados de aplicativo. A retenção afeta apenas a visibilidade dos metadados no MongoDB Ops Manager.
Sem imutabilidade retroativa do oplog. Você pode habilitar o bloqueio de objeto somente ao criar um armazenamento de oplog S3. Você não pode habilitar o bloqueio de objeto em um armazenar de oplog S3 existente alterando suas configurações; você deve criar um novo armazenar.
O versionamento do oplog é desativado por padrão. Por padrão, o MongoDB Ops Manager não usa a versão exata do objeto S3 que registrou quando lê um oplog slice de um armazenamento de oplog imutável. A configuração do aplicativo
brs.oplogStoreFallBackToLatestVersioné definida comotruepor padrão, o que faz com que o MongoDB Ops Manager sempre busque a versão mais recente do objeto em vez da versão que ele registrou. Para exigir que o MongoDB Ops Manager use a versão registrada exata, um administrador global deve definirbrs.oplogStoreFallBackToLatestVersioncomofalse.Requisito de topologia para confirmação da maioria para monitoramento do oplog. O Ops Manager apenas monitora entradas de oplog confirmadas pela maioria para um armazenar de oplog habilitado para bloqueio de objeto, já que o bloqueio de objeto significa que o Ops Manager nunca pode desfazer ou alterar dados já gravados no armazenar. Em uma topologia PSA com o secundário inativo, ou uma topologia PAA, a cauda do oplog nunca pode atingir o commit da maioria, portanto, o acompanhamento trava até que a topologia se recupere. O Ops Manager emite um alerta indicando a causa e a solução quando isso acontece.
Aviso
O MongoDB Ops Manager não lê o modo ou período de retenção real do seu bucket, para armazenar snapshot ou oplog. Se os valores de retenção definidos no MongoDB Ops Manager não corresponderem às configurações de retenção configuradas diretamente no bucket S3, seus backups poderão não estar protegidos contra exclusão ou modificação, e as tarefas de limpeza do MongoDB Ops Manager poderão falhar se o bucket forçar uma retenção que o MongoDB Ops Manager não conhece.
Configurar armazenamento de snapshot imutável
Para configurar o armazenamento de snapshot imutável, conclua as seguintes tarefas:
Ative backups imutáveis no Ops Manager.
Prepare um bucket S3 com bloqueio de objeto habilitado.
Configure um novo armazenamento de snapshots S3 no Ops Manager.
Habilitar backups imutáveis
Uma configuração de aplicativo controla backups imutáveis. Um administrador global deve habilitar essa configuração antes de configurar um armazenamento de snapshots S3 com Object Lock.
Adicione a configuração do aplicativo de backup imutável.
Clique na aba Custom.
Clique em + Add Option.
No campo Key, digite
brs.immutableBackupEnabled.No campo Value, digite
true.Clique em Save.
Essa configuração habilita a imutabilidade de snapshot S3 para armazenar com suporte de buckets habilitados para objeto-bloqueio. O MongoDB Ops Manager aplica essa configuração imediatamente. Você não precisa reiniciar o MongoDB Ops Manager.
Observação
Você também pode definir brs.immutableBackupEnabled como true no conf-mms.properties em vez de usar a IU de administrador. Se você definir a configuração em ambos os locais, o MongoDB Ops Manager usará o valor conf-mms.properties.
Prepare um bucket S3 com bloqueio de objeto habilitado
Ativar o Bloqueio de Objeto.
Habilite o bloqueio de objeto no bucket. Dependendo do seu provedor, você pode fazer isso durante a criação do bucket ou posteriormente. A maioria dos provedores de S3 exige o versionamento de objetos para que o Object bloqueio funcione, e alguns provedores permitem o Object bloqueio apenas durante a criação do bucket.
(Opcional) Configure gravações condicionais no bucket.
O MongoDB Ops Manager usa o suporte de gravar condicional do seu bucket por padrão para reduzir o espaço de armazenamento que os metadados de snapshot imutáveis usam. Configure seu bucket para oferecer suporte a gravar condicionais.
Importante
O suporte à gravação condicional é recomendado, não obrigatório. Se o seu bucket não oferecer suporte a gravações condicionais, o MongoDB Ops Manager ainda protegerá seus snapshots com o Object Lock, mas o bucket poderá crescer a uma taxa inesperada.
Configure a retenção padrão.
Configure um modo de retenção padrão (GOVERNANCE ou COMPLIANCE) e um período no seu armazenamento de objetos. O MongoDB Ops Manager não define cabeçalhos de retenção de Object bloqueio em objetos individuais, portanto, a configuração de retenção padrão do seu bucket é o que realmente protege seus dados. Sem uma retenção padrão configurada no bucket, o bloqueio de objetos não protege seus objetos contra exclusão ou modificação.
Observação
Você não pode habilitar o bloqueio de objeto para a configuração de um armazenamento de snapshots S3 existente no MongoDB Ops Manager. Se você já usa um bucket S3 para backups, mas precisa de snapshots imutáveis, habilite o bloqueio de objeto nesse bucket, se o seu provedor permitir, ou aponte para um bucket diferente que já tenha o bloqueio de objeto habilitado e configure um novo armazenamento de snapshots S3.
Configurar um novo armazenamento de snapshots S3 no Ops Manager
Crie um novo armazenamento de snapshots S3.
Siga o procedimento Adicionar um armazenamento de snapshots compatível com S3 para criar um novo armazenamento de snapshots S3 que aponta para o bucket com bloqueio de objeto ativado. Especifique o nome do bucket, ponto de extremidade, região e credenciais conforme exigido pelo seu provedor S3.
Defina Object Retention Mode.
Selecione o modo de retenção do bloqueio de objeto, GOVERNANCE ou COMPLIANCE, que o Ops Manager aplica aos objetos deste armazenamento de snapshots. O MongoDB Ops Manager não lê nem valida o modo de retenção que você configura diretamente no bucket S3. Você deve definir manualmente este campo para corresponder ao modo de retenção que você configurou no bucket.
Importante
Você pode selecionar Object Lock Enabled apenas ao criar um novo armazenamento de snapshots S3. Você não pode alterar essa configuração depois de armazenar. Você pode alterar Object Retention Period (Days) e Object Retention Mode a qualquer momento.
Esse armazenamento de snapshots serve como destino para snapshots imutáveis. O Ops Manager grava blocos de snapshot e metadados para backups que usam esse armazenamento no bucket.
Observação
Se você gerenciar o MongoDB Ops Manager com o MongoDB Enterprise Kubernetes Operator, também deverá habilitar o bloqueio de objeto na entrada s3Stores correspondente em seu recurso MongoDBOpsManager. Defina o campo spec.backup.s3Stores[].objectLockEnabled como true para que o Kubernetes operador reconcilie o MongoDB Ops Manager com a conscientização do bloqueio de objeto.
Você ainda precisa de uma instância do MongoDB para atuar como um armazenamento de metadados para operações do Ops Manager.
Configurar o armazenamento imutável do Oplog
Para configurar o armazenamento oplog imutável, conclua as seguintes tarefas:
Habilite backups imutáveis no MongoDB Ops Manager, se ainda não o fez.
Prepare um bucket S3 com controle de versão e bloqueio de objeto habilitado.
Configure um novo armazenar de oplog S3 no MongoDB Ops Manager.
Mover tarefas de backup existentes para o armazenar oplog S3 imutável.
Habilitar backups imutáveis
This step uses the same Ops Manager application setting as immutable snapshot storage. If you've already completed Enable Immutable Backups while configuring immutable snapshot storage, skip this step.
Prepare um bucket S3 com controle de versão e bloqueio de objeto habilitados
Prepare um bucket para seu armazenar de oplog imutável.
Habilite o versionamento e o bloqueio de objeto.
Ao contrário de um armazenar de oplog padrão, um armazenar de oplog imutável requer que o versionamento e o bloqueio de objeto sejam habilitados no bucket. Dependendo do seu provedor, você pode habilitá-los durante a criação do bucket ou posteriormente.
(Opcional) Configure gravações condicionais no bucket.
O MongoDB Ops Manager usa o suporte de gravação condicional do seu bucket por padrão para reduzir o espaço de armazenamento que os metadados de backup imutáveis usam. Configure seu bucket para oferecer suporte a gravar condicionais.
Importante
O suporte à gravação condicional é recomendado, não obrigatório. Se o seu bucket não oferecer suporte a gravar condicionalmente, o MongoDB Ops Manager ainda protegerá seus oplogs com o bloqueio de objeto, mas o bucket poderá crescer a uma taxa inesperada.
Configure a retenção padrão.
Configure um modo de retenção padrão (GOVERNANCE ou COMPLIANCE) e um período no seu armazenamento de objetos. O MongoDB Ops Manager não define cabeçalhos de retenção de Object bloqueio em objetos individuais, portanto, a configuração de retenção padrão do seu bucket é o que realmente protege seus dados. Sem uma retenção padrão configurada no bucket, o bloqueio de objetos não protege seus objetos contra exclusão ou modificação.
Observação
Você não pode habilitar o bloqueio de objeto para a configuração de um armazenar de oplog S3 existente no MongoDB Ops Manager. Se você já usa um bucket S3 para armazenar oplog, mas precisa de oplog imutáveis, habilite o versionamento e o Objeto Bloqueio nesse bucket, se o seu provedor permitir, ou ponto para um bucket diferente que já tenha ambos habilitados e configure um novo armazenar de oplog S3.
Configurar um novo armazenar de oplog S3 no MongoDB Ops Manager
Configure o novo bucket como um armazenar de oplog S3.
Crie um novo armazenar de oplog S3.
Siga o procedimento Adicionar um oplog armazenar compatível com S3 para criar um novo oplog armazenar S3 que ponto para o bucket versionado e com objeto-bloqueio habilitado. Especifique o nome do bucket, o ponto de extremidade, a região e as credenciais conforme exigido pelo seu provedor S3.
Defina Object Retention Period (Days).
Insira o número de dias que o MongoDB Ops Manager protege os objetos de cada oplog slice com Bloqueio de objetos. Este valor deve corresponder ao período de retenção que você configurou diretamente no bucket. Este campo não modifica as configurações de retenção no próprio bucket S3, e o MongoDB Ops Manager não lê nem valida o período de retenção real do bucket.
Importante
Recomendamos definir este campo. Se você deixá-lo em branco, o MongoDB Ops Manager não terá um registro de quando o período de retenção do seu bucket realmente expira. O MongoDB Ops Manager tenta excluir um objeto assim que sua própria lógica de grooming o considera elegível, e o bucket S3 rejeita essa exclusão até que seu período de retenção termine. O MongoDB Ops Manager continua tentando excluir até que o bucket a permita.
Defina Object Retention Mode.
Selecione o modo de retenção de bloqueio de objeto, GOVERNANCE ou COMPLIANCE, que o MongoDB Ops Manager aplica aos objetos deste armazenamento de oplog. Recomendamos definir este campo. O MongoDB Ops Manager não lê nem valida o modo de retenção que você configura diretamente no bucket S3. Você deve definir manualmente este campo para corresponder ao modo de retenção que configurou no bucket.
Importante
Você pode selecionar Object Lock Enabled apenas ao criar um novo armazenar de oplog S3. Você não pode alterar essa configuração depois de armazenar. Você pode alterar Object Retention Period (Days) e Object Retention Mode a qualquer momento.
Este armazenamento de oplog serve como destino para backups imutáveis de oplog. O MongoDB Ops Manager grava fatias de oplog e metadados para backups que usam esse armazenar no bucket.
Mudar trabalhos de backup existentes para armazenar oplog imutável S3
Para reatribuir uma tarefa de backup existente ao armazenar de oplog imutável S3, use rótulos de atribuição:
Adicione um rótulo ao armazenar de oplog S3 imutável.
Siga o procedimento Editar um armazenar oplog S3-compatível existente para adicionar um rótulo ao armazenar oplog S3 imutável.
Importante
PIT restaurações estão indisponíveis até que o MongoDB Ops Manager tire o próximo snapshot após a reatribuição.
Verificar imutabilidade
O MongoDB Ops Manager grava automaticamente os dados de cada snapshot e os metadados de bloqueio de objeto que o protegem no bucket S3. Você não precisa exportar os dados manualmente. Use o procedimento a seguir para confirmar se um snapshot específico está protegido pelo bloqueio de objeto.
Para confirmar que um armazenar de oplog S3 tem o bloqueio de objeto habilitado, vá para a página de armazenamento de oplog e verifique as configurações desse armazenar.
Importar snapshots para recuperação de desastre
Se você precisar restaurar dados de um bucket S3 preexistente que contenha snapshots imutáveis e metadados de backup, poderá importar esses snapshots para uma implantação do Ops Manager. Use esse fluxo de trabalho para cenários de recuperação de desastres, como a restauração de backups após a reconstrução do Ops Manager.
Importante
Os snapshots importados são apenas para operações de restauração únicas. O Ops Manager não gerencia o ciclo de vida dos snapshots importados nem os inclui nos agendamentos de backup ativos.
Selecione ou adicione o bucket S3 externo.
Selecione um bucket existente ou selecione Add S3 bucket para definir um novo. O nome do bucket e o ponto de extremidade S3 devem corresponder aos valores configurados no armazenamento S3 do snapshot.
Importante
O formulário Add S3 bucket solicita os mesmos campos que o procedimento Adicionar um armazenamento de snapshots compatível com S3, incluindo um tipo de armazenamento de dados e uma lista de hospedar ou URI do MongoDB. Esses campos devem apontar para o armazenamento de metadados dedicado para este bucket, não para a implantação do MongoDB que você está restaurando.
Selecione os snapshot para importar.
Selecione os snapshots ou clustershots que você deseja importar do bucket.
Importante
Para um clustershot com shards armazenados em buckets diferentes, importe o bucket de cada shard separadamente. Adicione cada bucket adicional e selecione os shards desse bucket, um bucket de cada vez, até importar todos os shards do clustershot.
O Ops Manager não torna o clustershot restaurável e não o exibe na página Continuous Backup até que você importe todos os seus shards.
Assim que a importação for concluída, os snapshots importados aparecem na página Continuous Backup no projeto ao qual você os atribuiu. O MongoDB Ops Manager exibe apenas clustershots que estão totalmente importados.
O MongoDB Ops Manager nunca exclui ou faz a limpeza de dados do bucket S3 do qual você importou. Você controla o ciclo de vida dos objetos de snapshot importados na camada de armazenamento de objetos. O MongoDB Ops Manager pode excluir os metadados que importou para seu próprio banco de dados de aplicativo.
Importar Oplogs para recuperação de desastre
Se você precisar de dados de restauração point-in-time de um bucket S3 pré-existente que contenha oplogs imutáveis, você pode importar esses oplogs para uma implantação do MongoDB Ops Manager. Você deve importar o snapshot correspondente primeiro. O MongoDB Ops Manager só pode descobrir oplogs para um cluster que já tenha um snapshot importado.
Importante
Se um arquivo de metadados listado no bucket estiver ausente quando o Ops Manager tentar importá-lo, o Ops Manager ignorará esse arquivo, fará log de um aviso e ainda relatará a tarefa de importação como SUCCEEDED. Isso pode deixar uma lacuna na faixa de tempo restaurável que só aparece mais tarde, como uma rejeição, quando você tenta uma restauração point-in-time através dessa lacuna.
Selecione ou adicione o bucket S3 que contém os oplogs.
Selecione um bucket existente na lista Select an S3 bucket e clique em Next. Ou selecione Add S3 bucket para registrar um novo e clique em Save para registrar o bucket e continuar.
Importante
O formulário Add S3 bucket solicita os mesmos campos que o procedimento Adicionar um armazenamento de snapshots compatível com S3, incluindo um tipo de armazenamento de dados e URI do MongoDB.
Você também deve marcar a caixa de seleção que reconhece que o MongoDB não oferece suporte a problemas causados pela sua solução de armazenamento compatível com S3antes que o MongoDB Ops Manager salve o bucket.
Assim que a importação for concluída, o MongoDB Ops Manager exibirá uma ação Manage Oplogs nessa linha, onde você poderá visualizar ou excluir os oplogs importados.
Interações com PITR
PITR combina um snapshot de linha de base com dados de oplog armazenados em um armazenar de oplog. Snapshots imutáveis afetam apenas o componente snapshot de linha de base:
Quando você alterna para um armazenamento de snapshots S3 imutável, PITR continua a funcionar a partir de snapshots existentes e dados de oplog. Snapshots antigos permanecem em seu armazenar original, e a configuração do armazenar oplog não muda.
Depois que o primeiro snapshot imutável completo for concluído no novo armazenar, PITR pode usar esse snapshot como linha de base e continuar rastreando oplogs do seu armazenar de oplog configurado.
PITR de um snapshot importado está disponível somente se você também importar os oplogs imutáveis correspondentes. Caso contrário, você pode restaurar um snapshot importado apenas até o ponto exato em que o Ops Manager criou o snapshot.
Importante
Para proteção total de imutabilidade, use um armazenar oplog habilitado para bloqueio de objeto juntamente com um armazenamento de snapshots habilitado para bloqueio de objeto. Por padrão, o MongoDB Ops Manager não força esse emparelhamento: uma tarefa de backup pode usar um armazenamento de snapshots imutável com um armazenamento de oplog padrão, e o PITR ainda funciona com essa combinação. Para exigir o pareamento, um administrador global deve habilitar a configuração do aplicativo mms.backup.enforceObjectLockOplogsOnObjectLockSnapshot. O MongoDB Ops Manager desativa essa configuração por padrão. Para criar um armazenar oplog habilitado para objeto-bloqueio, siga o procedimento Adicionar um armazenar oplog compatível com S3.
Quando você habilita o bloqueio de objeto (Object Lock) em um armazenar de oplog, o MongoDB Agent rastreia apenas as entradas de oplog confirmadas pela maioria para essa tarefa de backup. Uma entrada com commit de maioria não pode sofrer rollback, portanto, esse comportamento impede que o MongoDB Ops Manager faça backup de uma entrada de oplog que um rollback posterior possa remover.
Cenários de falha e recuperação
Os snapshots S3 imutáveis não introduzem cenários adicionais de perda de dados quando você alterna os armazenamentos de snapshots. Cada snapshot é restaurado a partir de um único armazenamento, portanto, a lógica de restauração não requer dados de vários buckets para um snapshot.
Falha antes do primeiro snapshot na nova loja
Todos os snapshots existentes permanecem no armazenamento S3 original e são totalmente restauráveis.
O PITR funciona a partir do snapshot concluído mais recente e dos dados do oplog.
Falha durante o primeiro snapshot completo no novo armazenar
O Ops Manager marca o snapshot em andamento para o novo armazenamento como com falha ou incompleto e não o usa para restauros.
O último snapshot bem-sucedido no armazenar original continua sendo o snapshot restaureável mais recente.
Após a recuperação do Ops Manager e do cluster, o Ops Manager agenda um novo snapshot completo para o armazenamento imutável na próxima janela de snapshot.
Como o primeiro snapshot no novo armazenamento é sempre um snapshot completo e cada snapshot é restaurado a partir de um único armazenamento, a lógica de restauração não depende da mistura de dados de vários buckets S3 para um único snapshot.