Résumé

  • La Backup Compliance Policy d’Atlas fixe un minimum de sauvegarde au niveau du projet. Même un propriétaire ne peut supprimer un instantané protégé ni raccourcir après sa création la durée qui le retient.
  • Les instantanés existants d’un cluster terminé restent soumis à la politique. Une rétention supplémentaire peut ensuite prolonger leur stockage, avec des droits de suppression différents de ceux de la période protégée.

Une bonne corbeille sait parfois dire non

Le propriétaire du projet est habitué à obtenir le dernier mot. Il possède le titre, les droits et, bien souvent, la responsabilité de la facture. Chez MongoDB Atlas, une politique de sauvegarde peut lui retirer une petite prérogative très concrète : faire disparaître le passé.

La Backup Compliance Policy empêche la suppression des instantanés protégés, quel que soit le rôle de l’utilisateur. Elle interdit de raccourcir leur rétention une fois qu’ils ont été pris. Elle impose aussi un minimum au projet, sous lequel la politique d’un cluster ne peut descendre. Cloud Backup ne peut être désactivé à volonté.

Cette contrariété est une partie du produit acheté. Une sauvegarde qu’un administrateur peut détruire dans un accès de zèle reste à la merci de cet administrateur — ou de celui qui aura pris son compte. L’entreprise cherche précisément à mettre une partie de sa mémoire hors de portée d’une décision immédiate.

Le malentendu commercial apparaît lorsque la signature reste au service sécurité tandis que le financement de la mémoire est abandonné à la prochaine réunion budgétaire.

Le projet transmet ses habitudes aux nouveaux venus

Le périmètre est important. La documentation indique des clusters dédiés M10 et supérieurs ; l’analyse porte ici sur ces déploiements Atlas Core. La règle est attachée au projet. Les clusters existants sont mis au niveau du minimum et les nouveaux adoptent cette protection. Une politique individuelle plus exigeante peut aller au-delà.

Supposons qu’une équipe lance un essai de courte durée dans un projet déjà soumis à une longue conservation. L’essai peut disparaître rapidement ; les sauvegardes qu’il a produites peuvent avoir une vie beaucoup plus longue. Le choix de l’emplacement a engagé cette seconde vie avant même que l’expérience ait livré son résultat.

La fréquence des futures sauvegardes peut être modifiée dans les limites imposées par le projet. Une réduction ne réécrit pas le calendrier de ce qui existe déjà. Les journaux d’opérations conservent leur fenêtre initiale. La politique oblige ainsi à distinguer deux budgets : celui des engagements que l’on continue de créer et celui de l’histoire déjà engagée.

La liste générique des économies possibles sur un service informatique aime les verbes courts : supprimer, réduire, arrêter. La protection transforme plusieurs de ces verbes en décisions prises plus tôt.

La retraite du cluster laisse une succession

Le parcours de suppression d’un cluster distingue explicitement la protection de la simple sauvegarde. Avec la politique de protection, les instantanés existants restent conservés suivant la politique après la terminaison. Sans elle, mais avec Cloud Backup activé, l’interface propose un choix pour conserver les instantanés. Cette option n’existe pas si Cloud Backup est désactivé.

Dans Atlas Core, l’historique d’opérations utile à la restauration à un instant donné peut aussi rester à l’état statique jusqu’à ce qu’il ne soit plus utilisable à cette fin. C’est une histoire conservée, avec sa limite d’usage. Le service arrêté ne produit plus de nouvelles opérations commerciales à sauvegarder.

La conséquence administrative est moins spectaculaire que la disparition d’un serveur, mais plus durable. Tant que des instantanés subsistent sous la politique, le projet ne peut être supprimé. Une organisation dont tous les projets ne peuvent être supprimés reste elle aussi en place. La documentation précise également que le nom du cluster terminé sert à identifier ses instantanés et empêche de recréer un cluster portant ce même nom.

Il faut donc transmettre un dossier de succession : quelles copies restent, jusqu’à quand, sous quel régime et à la charge de qui. Les heures actives du cluster et le stockage des sauvegardes ont chacun leur objet de facturation. Un reliquat de stockage ne prolonge pas magiquement la consommation de calcul d’un cluster arrêté.

Un projet vide doit l’être jusqu’au fond des tiroirs

Pour désactiver la politique dans un projet non vide, la personne désignée pour la sécurité ou les questions juridiques doit ouvrir une demande d’assistance et passer une vérification approfondie. MongoDB Support approuve la demande ; les propriétaires du projet peuvent ensuite désactiver la politique. Le droit d’administrer et la qualité de demandeur habilité ne se confondent pas.

Une exception permet aux propriétaires de projet ou d’organisation de désactiver la politique dans un projet vide. La définition comprend trois absences : aucun cluster actif, aucun cluster en pause et aucun instantané conservé d’un cluster terminé. Une liste de services en production devenue blanche ne remplit que la première partie du problème.

Cette procédure a besoin d’une adresse vivante. À la configuration, le représentant est identifié par son nom et son adresse utilisée pour le portail d’assistance. Une adresse incorrecte doit être corrigée avec Support. L’engagement peut durer plus longtemps que l’emploi de la personne qui l’a créé ; son remplacement mérite autant de soin que la succession d’un responsable de budget. La documentation ne donne pas de délai réel de traitement permettant de chiffrer cette étape pour un client donné.

La conservation et la protection se quittent à une date précise

Le détail le plus facile à perdre dans une présentation commerciale est la rétention supplémentaire. Elle laisse stocker des instantanés au-delà de la période protégée. Pendant cette prolongation, un utilisateur disposant du rôle approprié peut les supprimer. À la fin de la prolongation, Atlas les efface automatiquement.

Une archive ancienne peut donc être présente sans bénéficier encore de la même interdiction de suppression. Allonger la durée totale et allonger la protection répondent à deux demandes différentes. Un tableau qui n’affiche qu’un âge maximal rend ce passage invisible.

Les règles qui se chevauchent ajoutent une autre subtilité. MongoDB illustre le cas d’un instantané quotidien retenu deux jours et d’un instantané du samedi retenu trois semaines. Quand les deux règles produisent le même instantané, la durée la plus longue l’emporte. Cet exemple décrit la priorité entre deux calendriers, sans imposer trois semaines à tous les projets.

Le nombre de photographies n’est pas la taille de l’album

La facturation des sauvegardes dédiées repose sur un stockage qui est généralement incrémental. Les changements depuis la sauvegarde précédente comptent, avec les modalités déterminées par le fournisseur de stockage. Les données rapportées, la région et le régime de sauvegarde déterminent les quantités facturées.

Pour Cloud Backups, le tarif au Go par mois se présente dans la facture sous forme de lignes quotidiennes en Go-jours. Cette présentation ne multiplie pas la même charge. Les sauvegardes continues ont leurs propres tarifs et prennent en compte instantanés et journal interne d’opérations.

Certaines bascules, modifications de configuration ou interventions du fournisseur cloud peuvent imposer plusieurs instantanés complets. À l’inverse, retirer une copie ne retire pas les données encore référencées par une autre. Le comptage des instantanés ne fournit ni une facture fiable ni une économie proportionnelle. Il faut les volumes facturables, les régions, les dates et les tarifs applicables.

Le prix utile à discuter est celui d’une décision assumée : cette histoire mérite de résister aux prochains administrateurs pendant telle durée. Une entreprise peut très bien acheter cette rigidité. Elle devrait simplement lui donner un financement et un héritier avant de ranger le bon de commande.