Resumo

  • A Backup Compliance Policy do Atlas estabelece um mínimo de backup para o projeto e impede qualquer usuário de excluir snapshots protegidos ou encurtar sua retenção depois de criados.
  • Encerrar um cluster sob essa política mantém os snapshots existentes conforme as regras de backup. A retenção extra posterior tem outro regime: usuários com o papel adequado podem excluir as cópias nessa fase.

Um recurso que funciona quando o chefe ouve “não”

Há uma compra de software curiosa na MongoDB: pagar para que uma decisão futura do próprio administrador deixe de bastar. A Backup Compliance Policy do Atlas protege snapshots contra exclusão, inclusive por quem tem o título de proprietário do projeto. O dono conserva o cargo; a borracha fica fora de alcance.

Essa é uma utilidade real. Uma empresa pode querer que sua história de recuperação sobreviva à pressa de limpar um ambiente ou à tomada de uma conta administrativa. Se o administrador sempre puder remover a última proteção por conta própria, parte dessa promessa desaparece.

A documentação da política apresenta a contrapartida com clareza: o cliente perde meios de reduzir custos de armazenamento apagando backups ou diminuindo sua retenção. A mesma restrição produz proteção e inflexibilidade. Comprá-la exige mais gente na conversa do que quem configura o serviço.

O projeto distribui a obrigação

O pré-requisito documentado é o uso de clusters dedicados M10 ou superiores. O recorte aqui são esses ambientes Atlas Core. A política define um piso para o projeto, alcança clusters existentes e vale para os novos. Configurações anteriores são ajustadas para cumprir o mínimo; um cluster com exigência maior pode continuar acima dele.

O efeito aparece antes da primeira tentativa de economizar. Se um teste curto entrar num projeto de retenção longa, poderá deixar snapshots sujeitos a uma obrigação muito mais duradoura que o teste. Escolher o projeto passa a ser também escolher parte da vida futura dos dados.

Durante a proteção, nenhum usuário, independentemente do papel, pode excluir um snapshot protegido ou reduzir seu prazo depois da criação. Também não pode desligar Cloud Backup nem baixar a política do cluster aquém do mínimo do projeto. Uma redução na frequência de backups do cluster só alcança os próximos, respeitando esse piso; o histórico de operações mantém a janela original.

É aí que a economia precisa ser discutida no tempo certo. Alterar o plano para amanhã não transforma automaticamente o compromisso de ontem. O financeiro pode questionar novas obrigações e planejar o vencimento das antigas. A reunião de orçamento não ganha autoridade retroativa sobre os snapshots.

O serviço sai de cena, as cópias continuam no elenco

A rotina de encerramento distingue dois caminhos. Com a política de proteção, os snapshots existentes ficam retidos segundo a política de backup após o término do cluster. Sem ela, mas com Cloud Backup ligado, a interface permite escolher manter os snapshots existentes. Com Cloud Backup desligado, essa opção não aparece.

No Atlas Core, o registro de operações usado para recuperação em um ponto do tempo pode permanecer estático até deixar de ser utilizável nessa recuperação. Fica a história já produzida, com sua duração própria. O cluster encerrado não segue gerando novas operações do negócio.

O desligamento também deixa um endereço administrativo. Sob a política, um projeto com snapshots não pode ser excluído; sem remover todos os projetos, a organização tampouco pode ser apagada. A MongoDB informa ainda que usa o nome do cluster encerrado para identificar os snapshots, impedindo a criação de outro com o mesmo nome.

Esse resíduo merece um responsável. A pessoa que acompanhava o produto pode ter ido para outra equipe; alguém precisa herdar as cópias, as datas e a cobrança. As horas de atividade do cluster têm seu faturamento e o armazenamento remanescente tem o seu. Uma conta de backup depois do encerramento acompanha algo que continuou guardado, sem provar que o processamento continuou ligado.

Projeto vazio inclui gavetas vazias

Existe um processo para pedir a desativação da política. No projeto não vazio, o representante de segurança ou jurídico indicado abre um chamado e passa por verificação extensa. MongoDB Support aprova o pedido; depois disso, proprietários do projeto podem desativar a política. O título de proprietário e a habilitação para fazer esse pedido cumprem funções diferentes.

A exceção para projetos vazios é precisa: nenhum cluster ativo, nenhum pausado e nenhum snapshot retido de clusters encerrados. Nessas condições, um proprietário da organização ou do projeto pode desativar a política. A tela de produção sem clusters atende apenas parte da definição se as cópias antigas ainda estiverem lá.

O representante é identificado por nome e pelo endereço usado no portal de suporte. Um e-mail incorreto precisa ser corrigido com Support. Por isso, a troca de funcionário pede uma sucessão operacional, não só uma nova caixa no organograma. A documentação consultada não fornece um prazo real de atendimento que permita precificar a espera de um cliente específico.

A idade da cópia esconde uma mudança de direitos

A retenção extra de snapshots permite guardar as cópias além do período protegido. Durante essa extensão, elas podem ser excluídas por usuários com o papel adequado. Ao fim do prazo extra, o Atlas faz a exclusão automática.

Portanto, uma cópia antiga ainda presente pode ter deixado de contar com a mesma barreira contra exclusão. O comprador que pede mais tempo para consultar dados está escolhendo uma duração de armazenamento. O comprador que exige impedir a exclusão por pessoas autorizadas precisa olhar especificamente para a duração da proteção. Uma única coluna de “dias guardados” mistura duas promessas.

O calendário também depende de regras sobrepostas. A MongoDB dá o exemplo de snapshots diários retidos por dois dias e semanais de sábado por três semanas. Quando as duas regras produzem o mesmo snapshot, prevalece a retenção mais longa. As três semanas pertencem ao exemplo; o princípio é a precedência da maior duração.

A fatura não conta fotografias

A explicação de custos para clusters dedicados mostra outro detalhe. Cloud Backups costuma usar snapshots incrementais, dependendo do comportamento do provedor de armazenamento. O tamanho reportado e a região entram na conta. O preço em GB por mês aparece em itens diários de GB-dia, apresentação que não duplica a cobrança. Continuous Cloud Backups usa sua própria tabela e combina snapshots com o registro interno de operações.

Certas mudanças de configuração, transferências por falha ou manutenções da nuvem subjacente podem exigir mais de um snapshot completo. No sentido inverso, excluir uma cópia pode deixar os mesmos dados referenciados por outras. Nem multiplicar a quantidade de snapshots pelo banco atual nem projetar uma economia proporcional à quantidade removida produz uma boa estimativa. São necessários volumes faturáveis, regiões, prazos e tarifas aplicáveis.

A compra faz sentido quando alguém assume esse compromisso inteiro. O sistema guardará a história contra parte das vontades futuras da empresa. O contrato interno da empresa precisa dizer quem acompanha e financia essa história quando o produto já tiver ido embora.