Guide complet pour la sauvegarde et la restauration des bases de données MongoDB

Introduction : Pourquoi les sauvegardes sont-elles importantes pour MongoDB ?

Lorsque vous utilisez MongoDB en production, la sauvegarde est essentielle – elle peut faire la différence entre une récupération après un incident et une perte de données permanente. Une base de données telle que MongoDB contenant des informations sur les utilisateurs, des transactions, des informations sur les produits ou l’état d’une application est une base de données où l’intégrité des données se traduit directement par la continuité de l’activité. Les processus de sauvegarde et de restauration des données MongoDB sont à la base de cette intégrité.

Une simple panne matérielle, une suppression involontaire ou une infection par un ransomware peut entraîner une perte importante de données. Dans de tels cas, il n’existe pas non plus d’options de récupération viables s’il n’y a pas de stratégie de sauvegarde solide et fiable en place. La qualité d’un plan de sauvegarde MongoDB déployé aujourd’hui dictera la rapidité avec laquelle les systèmes pourront revenir en ligne après une éventuelle défaillance, comme c’est malheureusement le cas pour la plupart des systèmes.

Quels sont les risques liés à l’absence d’une stratégie de sauvegarde fiable ?

L’exploitation d’un système MongoDB sans stratégie de sauvegarde présente trois catégories de risques principales :

• Risques opérationnels
• Financiers
• Réputation

Toutes ces catégories ont un certain type d’effet qui s’accumule au fil du temps et devient beaucoup plus difficile à résoudre après une perte de données.

Le risque opérationnel est le plus immédiat. Lorsqu’un nœud primaire tombe en panne, qu’une collection s’arrête ou qu’une migration échoue, le cluster se retrouve dans un état incohérent. La base de données de sauvegarde MongoDB attendue n’existe pas au départ, de sorte que l’équipe doit procéder à une récupération forensique à partir des journaux d’application ou des exportations fragmentées, s’ils existent.

L’exposition financière suit de près. Les obligations de conformité imposées par des réglementations telles que GDPR, HIPAA et SOC 2 signifient qu’une défaillance de sauvegarde sera un incident de conformité, et non une simple défaillance technique. Les audits ultérieurs, les amendes et les notifications obligatoires de violation peuvent tous être attribués à des pratiques de sauvegarde et de restauration MongoDB mal mises en œuvre ou inexistantes.

Les modes de défaillance les plus courants rencontrés par les organisations sont les suivants

• Abandons accidentels de collections – un développeur exécute db.collection.drop() dans le mauvais environnement.
• Migrations de schémas bâclées – un script de transformation corrompt des documents à grande échelle avant que l’erreur ne soit détectée.
• Ransomware et attaques d’infrastructure – les données cryptées deviennent inaccessibles sans une copie hors ligne.
• Défaillance matérielle sans redondance – un nœud autonome tombe en panne sans réplique ni snapshot récent.
• Corruption silencieuse – les problèmes d’intégrité des données ne sont pas détectés jusqu’à ce qu’une sauvegarde soit nécessaire, et les sauvegardes existantes peuvent alors être corrompues.

Les atteintes à la réputation sont plus difficiles à quantifier, mais elles n’en sont pas moins réelles. Les utilisateurs, particuliers ou entreprises, qui confient leurs données à une plateforme s’attendent à ce que ces données restent sécurisées. Une perte de données largement médiatisée – même si elle est due à un problème d’infrastructure plutôt qu’à une intention malveillante – nuit tellement à la confiance des utilisateurs qu’il faut des années pour la rétablir et la reconstruire.

Comment les types de déploiement de MongoDB affectent-ils les besoins de sauvegarde (autonome, ensemble de répliques, cluster partagé) ?

La topologie de déploiement de MongoDB actuellement utilisée détermine les méthodes de sauvegarde possibles, le niveau de complexité et les garanties de cohérence disponibles. Les trois principales topologies existantes sont l’autonome, l’ensemble de répliques et le cluster partagé, chacune ayant des exigences différentes en matière de sauvegarde.

Les déploiements autonomes sont les plus simples à sauvegarder mais comportent les risques inhérents les plus élevés. Comme il n’y a pas de système secondaire sur lequel basculer pendant que les sauvegardes sont en cours, tout processus de sauvegarde à forte intensité d’E/S entrera en concurrence directe avec le trafic de production. Les instantanés de systèmes de fichiers avec prise en charge de la sémantique de copie sur écriture sont les plus appropriés dans cette situation, comme LVM ou ZFS (tous deux sont instantanés et non perturbateurs).

Les jeux de répliques offrent une grande souplesse opérationnelle. Le processus de sauvegarde de MongoDB peut être déchargé sur un nœud secondaire, ce qui permet d’isoler la charge de travail de sauvegarde des nœuds primaires. Les sauvegardes basées sur Oplog deviennent également possibles dans ce cas, permettant une restauration ponctuelle à n’importe quel moment en utilisant la fenêtre de rétention Oplog – ce que les déploiements autonomes ne peuvent pas offrir.

L’oplog est un journal plafonné et horodaté de chaque opération d’écriture dans la base de données, que MongoDB peut utiliser à des fins de réplication en le rejouant pour restaurer les données à n’importe quel moment antérieur.

Les clusters en grappes requièrent la coordination la plus minutieuse. C’est pourquoi la capture de tous les shards et de l’ensemble de répliques du serveur de configuration au même moment logique permet d’obtenir une sauvegarde cohérente à l’échelle du cluster. La fonction d’équilibrage des blocs doit être interrompue avant le début de la sauvegarde, et la cohérence entre les blocs serait difficile à garantir sans une coordination explicite. MongoDB Atlas Backup (le service de base de données en nuage géré par MongoDB) gère la plupart de ces tâches automatiquement, mais les clusters shardés autogérés nécessitent toujours une orchestration manuelle ou un outil tiers.

Quels sont les objectifs de temps de récupération (RTO) et de point de récupération (RPO) à prendre en compte ?

Le RTO et le RPO sont les deux paramètres qui définissent ce qu’une stratégie de sauvegarde doit fournir. L’objectif de temps de rétablissement ( RTO ) est la durée maximale acceptable entre un événement de défaillance et le rétablissement du service normal. L’objectif de point de récupération (RPO ) est la quantité maximale acceptable de perte de données, exprimée en tant que point dans le temps. Ces deux valeurs doivent être définies avant même d’essayer de sélectionner des outils de sauvegarde ou des modèles de planification – ce sont les exigences auxquelles répondent toutes les autres décisions.

La plupart des organisations ne parviennent à définir leur RTO et leur RPO qu’après avoir subi une panne de taille importante, ce qui les oblige à définir ces paramètres sous la pression. Par exemple, une application orientée client qui traite des commandes en continu ne peut pas tolérer un temps d’arrêt de quatre heures ou une perte de données de six heures. De nombreuses configurations de sauvegarde qui n’ont jamais été testées sous pression produiraient exactement ces résultats.

Utilisez le cadre suivant pour établir des objectifs de référence :

Un pipeline de sauvegarde et de restauration de base de données MongoDB avec un RPO de cinq minutes sera complètement différent d’un pipeline avec un RPO de 24 heures. La sauvegarde continue basée sur Oplog est nécessaire pour permettre des points de récupération inférieurs à une heure, car elle capture chaque opération d’écriture en temps quasi réel. Les stratégies basées uniquement sur des instantanés (capture d’instantanés à certains intervalles) produisent un point de récupération égal à la fréquence des instantanés – ce qui signifie qu’un programme d’instantanés de quatre heures produit un RPO de quatre heures dans le pire des cas.

Les délais d’exécution sont tout aussi sensibles lorsqu’il s’agit de choisir une stratégie de sauvegarde. La restauration de 2 To d’une archive mongodump à partir d’un stockage objet prendrait plusieurs heures. En revanche, la restauration à partir d’un instantané de système de fichiers résidant sur un système de stockage en bloc attaché ne prendrait que quelques minutes. Le processus de restauration MongoDB lui-même – et pas seulement le format de sauvegarde – doit être pris en compte dans tous les calculs de RTO. Les équipes qui documentent et testent régulièrement leurs cadres de restauration sont plus susceptibles d’atteindre leurs objectifs de RTO lorsque cela est important.

Comment la sauvegarde de MongoDB s’intègre-t-elle dans une stratégie plus large de protection des données d’entreprise ?

La sauvegarde n’est qu’une facette d’une stratégie de protection ; elle n’en est pas la totalité. Bien que la sauvegarde de MongoDB englobe les données au niveau de la base de données (collections, index, utilisateurs et paramètres de configuration), la résilience de l’entreprise nécessite également une couverture appropriée de l’état de l’application, de la gestion des secrets et des dépendances entre services. La stratégie de sauvegarde MongoDB qu’une entreprise choisit de mettre en œuvre doit être définie en gardant cet objectif primordial à l’esprit.

Pourquoi la sauvegarde au niveau de la base de données n’est-elle pas suffisante pour assurer la résilience de l’entreprise ?

Une sauvegarde complète de MongoDB capture l’intégralité du contenu du moteur de base de données. Elle ne capture pas les éléments suivants

• La configuration de l’application qui indique à la base de données comment se comporter
• Les certificats TLS qui sécurisent les connexions à la base de données
• Les variables d’environnement qui stockent les informations d’identification
• L’état de l’infrastructure, qui décrit la topologie du réseau dans lequel la base de données est exécutée.

La récupération d’une sauvegarde MongoDB dans un environnement instable ou mal configuré va créer une base de données fonctionnelle à laquelle votre application ne pourra pas se connecter ou s’authentifier. Pour que les entreprises soient résilientes, elles devront prendre en compte chacun des éléments suivants :

1. Configuration et secrets de l’application – fichiers d’environnement, entrées Vault, chaînes de connexion et clés API dont dépendent les services.
2. État de l’infrastructure – définitions Terraform ou CloudFormation qui décrivent l’environnement réseau, de calcul et de stockage.
3. Cohérence des données interservices – enregistrements connexes dans d’autres bases de données ou files d’attente de messages qui doivent s’aligner sur le point de restauration MongoDB.
4. La configuration de MongoDB elle-même – les définitions des ensembles de répliques, les rôles des utilisateurs et les index personnalisés qui ne sont pas toujours capturés par un mongodump de base.

Comment les sauvegardes MongoDB s’intègrent-elles aux plateformes de sauvegarde d’entreprise ?

L’intégration est généralement réalisée grâce à l’un des trois principaux mécanismes suivants : des crochets pré/post-sauvegarde qui déclenchent mongodump ou un snapshot avant que la plate-forme ne capture le système de fichiers, des plugins basés sur des agents que le fournisseur de la plate-forme fournit ou prend en charge, ou une orchestration basée sur l’API où la plate-forme de sauvegarde appelle un script externe qui gère les étapes spécifiques à MongoDB.

Les plateformes avec lesquelles les organisations intègrent le plus souvent MongoDB sont les suivantes :

• Bacula Enterprise. Intégration basée sur des plugins avec prise en charge des scripts de pré-travail ; bien adaptée aux environnements réglementés exigeant des pistes d’audit.
• Veeam. Approche axée sur les instantanés ; la cohérence de MongoDB nécessite un traitement adapté à l’application ou des scripts de gel préalable.
• Commvault. Intégration d’IntelliSnap pour les instantanés au niveau des blocs ; prise en charge des topologies d’ensembles de répliques et de clusters partagés.
• NetBackup (Veritas). Basé sur un agent avec planification des politiques ; plugin MongoDB disponible pour les niveaux de licence d’entreprise.

Comment les systèmes de sauvegarde centralisés réduisent-ils les risques opérationnels ?

Si chaque équipe est responsable de la gestion de son propre processus de sauvegarde de MongoDB, il en résultera des planifications variables, une rétention incohérente et aucun moyen de savoir si les sauvegardes sont réussies en premier lieu. Les systèmes de sauvegarde centralisés assurent l’uniformité des politiques dans toutes les instances de base de données, ce qui élimine la catégorie d’incidents qui surviennent lorsque la tâche de sauvegarde d’une équipe est silencieusement interrompue pendant des semaines.

L’avantage opérationnel ne réside pas seulement dans la visibilité, mais aussi dans la responsabilité. Un système centralisé qui suit chaque tâche de sauvegarde, vérifie chaque instantané terminé et déclenche une procédure d’escalade en cas de défaillance crée une trace clairement documentée qui est souvent nécessaire à des fins d’audit de conformité. La gestion des sauvegardes MongoDB répartie entre les équipes a tendance à produire des lacunes qui ne sont découvertes que lorsqu’il y a un besoin urgent de restauration.

Quelles sont les stratégies de sauvegarde de MongoDB disponibles ?

La stratégie de sauvegarde de la base de données MongoDB appropriée dépendra de la topologie de votre déploiement, de la fenêtre tolérable de perte de données et de la complexité opérationnelle. Les trois stratégies de sauvegarde de base décrites ci-dessous – la sauvegarde logique, la sauvegarde physique et la restauration ponctuelle basée sur l’oplog – ne s’excluent pas mutuellement. Deux ou trois de ces options sont utilisées en tandem dans la plupart des environnements de production.

Qu’est-ce que la sauvegarde logique et quand devriez-vous utiliser mongodump/mongorestore ?

La sauvegarde logique prend un instantané des données MongoDB sous forme de documents BSON qui sont écrits dans des fichiers par mongodump. Mongorestore est ensuite capable de restaurer ces données dans n’importe quelle autre instance MongoDB compatible. Ce processus est indépendant de la topologie, n’a pas besoin d’accéder à un système de fichiers et génère une sortie portable qui peut être examinée, filtrée ou restaurée par collection.

La sauvegarde de MongoDB produite par mongodump capture les documents, les index, les utilisateurs et les rôles. Elle ne capture pas l’oplog ou les transactions en cours, ce qui signifie que cet instantané n’est cohérent qu’au moment où la vidange se termine, alors que le processus lui-même peut prendre des minutes, voire des heures (sur des ensembles de données volumineux).

La sauvegarde logique est le bon choix lorsque :

• La portabilité est importante – déplacer des données entre les versions de MongoDB ou les fournisseurs de cloud.
• Une restauration sélective est nécessaire – récupération d’une seule collection sans toucher au reste de la base de données.
• L’ensemble de données est petit – moins de ~100GB, où la durée du dumping ne crée pas de risque significatif pour la cohérence.
• Aucun accès au système de fichiers n’est disponible – environnements d’hébergement gérés où les API d’instantanés ne sont pas exposées.

Pour les déploiements importants, à forte intensité d’écriture, mongodump seul est rarement suffisant comme stratégie principale de sauvegarde et de restauration de MongoDB.

Qu’est-ce qu’une sauvegarde physique et quand devriez-vous utiliser des instantanés de système de fichiers ?

La sauvegarde physique prend une copie des fichiers de données brutes que MongoDB écrit sur le système de fichiers (les fichiers du moteur de stockage WiredTiger, le journal et les index) au niveau du système de fichiers/blocs. Les outils appropriés pour y parvenir sont les instantanés LVM sous Linux, les instantanés AWS EBS et la fonction d’envoi/réception ZFS.

Comme la sauvegarde est instantanée et se produit en dehors du processus mongoDB, les sauvegardes sont beaucoup plus rapides à créer que mongodump sur de grands ensembles de données et la base de données elle-même ignore presque totalement que la sauvegarde est en cours, du point de vue des performances.

La principale condition préalable à la sauvegarde physique est la cohérence du système de fichiers. MongoDB doit être dans un état de point de contrôle propre ou avoir activé la journalisation (une mesure par défaut avec WiredTiger) pour que l’instantané représente un état récupérable. Si vous tentez de créer un instantané sans tenir compte de cet aspect, vous obtiendrez une sauvegarde qui risque de ne pas démarrer lors d’une procédure de reprise après sinistre de MongoDB.

La sauvegarde physique est le bon choix lorsque :

• La taille de l’ensemble de données est importante – lorsque la durée du mongodump créerait un écart de cohérence inacceptable.
• Le RTO est serré – les restaurations au niveau des blocs sont plus rapides que la réimportation au niveau des documents.
• L’infrastructure prend en charge les instantanés atomiques – environnements EBS, LVM ou ZFS où les instantanés de copie sur écriture sont disponibles.
• La restauration complète du cluster est le scénario attendu – plutôt que la restauration sélective au niveau de la collection.

Comment fonctionnent les sauvegardes ponctuelles et les méthodes basées sur l’exploitation ?

La restauration ponctuelle fonctionne en associant un instantané de base à la relecture d’oplog pour restaurer un déploiement MongoDB à n’importe quel point spécifique de la fenêtre de rétention d’oplog. Les nœuds secondaires utilisent oplog à des fins de réplication, tandis que les sauvegardes l’utilisent pour combler l’écart entre l’instantané de base et le point de récupération cible.

Le processus fonctionne comme suit : un instantané de base est pris à l’instant T, capturant l’état complet de la base de données. L’oplog est ensuite capturé en continu ou à intervalles réguliers à partir de l’instant T. Lors de la restauration, l’instantané de base est d’abord utilisé, puis les entrées de l’oplog sont rejouées jusqu’à l’horodatage cible – créant ainsi un état de la base de données qui est exact à ce moment précis.

Cette approche est soumise à deux contraintes pratiques. La première est le fait que l’oplog est plafonné – les entrées les plus anciennes sont écrasées dès que de nouvelles entrées doivent avoir lieu, de sorte que la fenêtre de récupération sera toujours limitée par la taille de l’oplog et le volume d’écriture. La deuxième contrainte est liée au fait que la récupération ponctuelle nécessite un ensemble de répliques, car les déploiements autonomes n’ont pas d’oplog et ne peuvent pas supporter cette méthode sans Atlas ou une solution tierce.

Quand devriez-vous utiliser la sauvegarde incrémentielle de MongoDB par rapport à la sauvegarde complète ?

Une sauvegarde complète copie l’ensemble des données à chaque exécution. Une sauvegarde incrémentale ne copie que les modifications effectuées depuis la dernière sauvegarde, soit par oplog tailing, soit par block-level change tracking. La meilleure option pour chaque organisation varie considérablement en fonction de la taille du jeu de données, de la fréquence des sauvegardes et du coût du stockage.

Une stratégie de sauvegarde typique consiste à utiliser une sauvegarde complète hebdomadaire avec des sauvegardes incrémentielles quotidiennes ou horaires, ce qui permet de trouver un compromis entre l’espace requis et la complexité de la restauration. Chaque sauvegarde complète réinitialise la chaîne incrémentielle et limite l’ancienneté de l’incrément, ce qui réduit dans une certaine mesure les risques de corruption.

Quels outils et services prennent en charge la sauvegarde et la restauration des bases de données MongoDB ?

L’écosystème de la sauvegarde et de la restauration de MongoDB englobe un grand nombre d’éléments répartis en plusieurs groupes : les services gérés dans le nuage, les utilitaires de ligne de commande natifs, les outils au niveau du système de fichiers et les plates-formes d’entreprise tierces. Chacune de ces options a une position distincte sur le spectre « simplicité opérationnelle – contrôle ».

Quels sont les avantages et les inconvénients de MongoDB Atlas Backup ?

MongoDB Atlas Backup est un service de sauvegarde entièrement géré qui est fourni avec les clusters Atlas. Le service fonctionne en continu, ne nécessite aucune configuration après son activation et prend même en charge la restauration basée sur l’horodatage à n’importe quel moment de la période de rétention. C’est le moyen le plus simple de mettre en œuvre un plan de sauvegarde MongoDB prêt pour la production pour les équipes qui utilisent déjà MongoDB Atlas.

Les fonctionnalités les plus remarquables d’Atlas Backup sont résumées dans le tableau ci-dessous.

La portabilité est la plus grande limitation d’Atlas Backup. Si une solution a été configurée pour un cluster, elle n’est pas transférable à un déploiement autogéré, et toutes les restaurations doivent être effectuées via l’interface Atlas ou l’API (inaccessible via les outils mongorestore standard). Cette seule contrainte peut être un obstacle pour les organisations qui travaillent avec des mandats multi-cloud ou des exigences réglementaires centrées sur la résidence des données.

Comment fonctionne MongoDB Atlas Backup to S3 et quand devriez-vous l’utiliser ?

MongoDB Atlas Backup to S3 est une fonctionnalité d’exportation d’instantanés – et non un flux de réplication continu. Elle peut être déclenchée manuellement ou selon un calendrier. Une fois déclenché, Atlas prend un instantané cohérent du cluster, l’écrivant dans un seau S3 spécifié dans un format qui permet de restaurer ces données ultérieurement avec les outils MongoDB standard. L’instantané exporté qui en résulte est découplé d’Atlas lui-même, ce qui le rend approprié pour l’archivage à long terme, la copie interrégionale ou dans le cadre des exigences de conservation de la conformité.

Il est également important d’être clair sur ce que cette fonctionnalité est et n’est pas. Atlas Backup ne fournit pas de flux en temps réel des changements oplog vers S3. L’exportation est effectuée à un moment précis, et l’écart entre ces exportations est le RPO effectif pour tout ce qui dépend exclusivement des copies S3. Les équipes qui ont besoin de points de récupération inférieurs à une heure doivent considérer ces exportations S3 comme une couche d’archivage secondaire – et non comme un mécanisme principal de récupération des données.

Les sauvegardes Atlas doivent être utilisées lorsqu’il y a un besoin de rétention à long terme ou de portabilité en dehors d’Atlas. N’en faites pas la seule méthode de sauvegarde de MongoDB en production, en particulier lorsque les RPO sont déjà suffisamment stricts.

Comment mongodump/mongorestore se compare-t-il à mongorestore avec oplog replay ?

La mongodump normale prend un instantané logique unique et cohérent de la base de données. La restauration via mongorestore reproduit l’instantané tel quel – créant une base de données qui est ramenée à son état exact au moment où le vidage a été effectué, sans aucune option de restauration à un autre point.

mongorestore with oplog replay étend le résultat susmentionné en appliquant les opérations de l’oplog à l’instantané restauré, en amenant la base de données à la date souhaitée. Cette fonctionnalité critique est ce qui rend la restauration ponctuelle possible pour les déploiements autogérés.

L’option de relecture de l’oplog(–oplogReplay) force mongorestore à appliquer toutes les entrées de l’oplog incluses dans le dump directement une fois que le processus de restauration du document est terminé. Cette option est rendue possible par l’utilisation d’un drapeau spécifique(–oplog) pour capturer l’oplog lui-même avec mongodump.

Comment les snapshots au niveau du système de fichiers (LVM, EBS, ZFS) peuvent-ils être utilisés en toute sécurité avec MongoDB ?

L’exigence de cohérence pour qu’une sauvegarde physique de MongoDB soit valide est que les fichiers de données représentent un point de contrôle WiredTiger propre. La raison pour laquelle WiredTiger peut être utilisé est qu’il écrit des données en arrière-plan et maintient un journal. Si vous deviez prendre un instantané des fichiers de données alors que le moteur est en cours d’exécution, l’instantané serait récupérable tant que la journalisation est activée (comme c’est toujours le cas par défaut). Il ne s’agit pas nécessairement d’un instantané des données lorsque Mongo est arrêté, mais d’un instantané atomique au niveau du système de fichiers.

La manière dont ce niveau d’atomicité est atteint dépend de l’outil :

• Instantanés LVM – instantanés de copie sur écriture d’un volume logique ; instantanés et cohérents si les données et le journal MongoDB résident sur le même volume. Pour les répartir sur plusieurs volumes, il est nécessaire d’effectuer des instantanés simultanés.
• Instantanés Amazon EBS – instantanés au niveau du bloc déclenchés via l’API AWS ; convient à MongoDB hébergé dans le nuage et dont les données se trouvent sur des volumes EBS. La cohérence multi-volumes nécessite l’utilisation de groupes d’instantanés multi-volumes EBS.
• Envoi/réception ZFS – Les instantanés ZFS sont atomiques de par leur conception et capturent l’ensemble des données dans un état cohérent. Ils conviennent parfaitement aux déploiements sur site où ZFS est le système de fichiers sous-jacent.

Le seul scénario qui peut être considéré comme dangereux dans ces circonstances est celui où MongoDB est utilisé sans journalisation sur un système de fichiers non ZFS. Heureusement, ce type de configuration est rare dans les déploiements modernes, mais il vaut toujours la peine de vérifier deux fois avant de s’appuyer sur des sauvegardes de MongoDB basées sur des instantanés pendant la production.

Existe-t-il des outils de sauvegarde tiers et quelles sont leurs fonctionnalités ?

Un certain nombre de solutions tierces complètent ou fournissent une alternative aux fonctions de sauvegarde intégrées de MongoDB, en particulier dans les environnements d’entreprise autogérés où Atlas n’est pas utilisé :

• Percona Backup for MongoDB (PBM) – open-source, prend en charge les sauvegardes logiques et physiques, la récupération par relecture d’oplog et la coordination des clusters shardés. L’alternative auto-hébergée la plus performante à Atlas Backup.
• Bacula Enterprise – plate-forme de sauvegarde d’entreprise avec intégration de MongoDB par le biais de scripts pré/post-travail et de plugins ; forte piste d’audit et fonctions de conformité pour les environnements réglementés.
• Ops Manager (MongoDB) – Plate-forme de gestion sur site propre à MongoDB, qui inclut la sauvegarde continue avec restauration ponctuelle basée sur oplog ; nécessite un déploiement séparé d’Ops Manager.
• Dbvisit Replicate – outil de capture des données de changement qui peut servir de fonction de sauvegarde pour MongoDB en diffusant les changements vers une cible secondaire.
• Services d’instantanés natifs du cloud – AWS Backup, Azure Backup et Google Cloud Backup prennent tous en charge les instantanés au niveau du volume, qui peuvent inclure les répertoires de données MongoDB s’ils sont configurés correctement.

Un point de départ commun pour la majorité des déploiements autogérés qui n’ont pas de plateforme de sauvegarde d’entreprise existante est Percona Backup for MongoDB. Son utilisation est gratuite, son développement est actif et il possède les fonctions de base requises pour le flux de travail complet de sauvegarde et de restauration de la base de données MongoDB.

Comment la sauvegarde de MongoDB peut-elle être intégrée à Bacula Enterprise pour la protection de l’entreprise ?

Bacula Enterprise est une solution de sauvegarde complète qui permet aux organisations de centraliser la protection des données dans des environnements hétérogènes composés de serveurs physiques, de machines virtuelles, d’instances cloud et de bases de données.

L’intégration de la sauvegarde MongoDB avec Bacula est réalisée à travers des scripts pré et post job. Bacula lance un mongodump ou un snapshot du système de fichiers avant de prendre la sauvegarde des fichiers générés et exécute ensuite des actions de rétention, de cryptage et de transfert à distance des données conformément à la politique préconfigurée.

Ce que Bacula apporte à une stratégie de protection des données MongoDB que l’outil natif ne fournit pas :

• Planification centralisée et application de la politique – les tâches de sauvegarde de MongoDB s’exécutent selon le même calendrier et le même cadre de rétention que toutes les autres charges de travail dans l’environnement, éliminant ainsi l’incohérence qui vient des tâches cron gérées par l’équipe.
• Pistes d’audit et rapports de conformité – chaque tâche de sauvegarde est enregistrée avec des horodatages, l’état de réussite et le volume de données, produisant ainsi l’enregistrement vérifiable exigé par les industries réglementées.
• Stockage et transport cryptés – les données sont cryptées au repos et en transit par défaut, la gestion des clés étant gérée au niveau de la plateforme plutôt que par base de données.
• Alerte et remontée des défaillances – les tâches de sauvegarde MongoDB qui échouent passent par le même pipeline d’alerte que les défaillances de l’infrastructure, au lieu de passer inaperçues dans un journal de script.
• Support des copies multi-sites et air-gapped – Bacula supporte les bandes, le stockage objet et les cibles de sites distants, ce qui est précieux pour les organisations qui ont besoin de copies de sauvegarde MongoDB hors ligne ou air-gapped dans le cadre de leur posture de protection contre les ransomwares.

C’est aussi une transition transparente pour les organisations qui s’appuient déjà sur Bacula Enterprise pour leurs besoins de sauvegarde. Au lieu de construire une autre infrastructure de sauvegarde séparée, le processus de sauvegarde MongoDB est facilement intégré dans le système existant, ce qui entraîne une réduction significative de la prolifération des outils et de la complexité de la gestion.

Comment effectuer une sauvegarde sûre pour différentes topologies MongoDB ?

Une méthode de sauvegarde MongoDB adaptée à un serveur unique ne garantit pas nécessairement l’intégrité et l’absence d’interruption de service lorsqu’elle est appliquée sans adaptation à un ensemble de répliques ou à un cluster partagé. L’une des principales raisons est le grand nombre de facteurs qui changent en fonction de la topologie MongoDB choisie.

Comment sauvegarder un ensemble de répliques sans affecter la disponibilité ?

La sauvegarde de votre ensemble de répliques repose sur un seul grand principe : n’effectuez jamais une sauvegarde gourmande en ressources par rapport à l’ensemble principal lorsque vous pouvez l’éviter. Le primaire reçoit tout le trafic d’écriture, et un processus de sauvegarde qui se bat pour ses E/S est la source d’une latence ressentie par tous les utilisateurs de l’application. La meilleure option est un secondaire dédié – configuré comme un membre caché, idéalement, de sorte qu’il ne reçoive aucun trafic et n’existe que pour des tâches opérationnelles telles que la sauvegarde.

Le processus de sauvegarde d’un jeu de réplicas sûr se déroule dans l’ordre suivant :

1. Vérifiez le retard de réplication sur le secondaire cible avant de commencer. Un secondaire en retard produit une sauvegarde qui ne reflète pas l’état actuel des données – vérifiez rs.printSecondaryReplicationInfo() et confirmez que le retard est dans des limites acceptables.
2. Sélectionnez un secondaire caché ou de faible priorité comme cible de sauvegarde afin d’éviter d’utiliser la capacité de lecture des membres desservant l’application.
3. Lancez la sauvegarde – soit un mongodump, soit un instantané du système de fichiers – contre le répertoire de données ou le point d’extrémité de la connexion du secondaire.
4. Capturez l’oplog en même temps que la sauvegarde si une restauration ponctuelle est nécessaire. Utilisez –oplog avec mongodump, ou enregistrez l’intervalle d’horodatage oplog qui correspond à la fenêtre d’instantané.
5. Vérifiez la sauvegarde avant d’éliminer les anciennes copies. Une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde, c’est une hypothèse.

Il existe également un cas particulier intéressant qui mérite d’être souligné : si tous les serveurs secondaires sont à la traîne en raison d’un pic de trafic d’écriture, il peut être préférable de retarder complètement la sauvegarde plutôt que de risquer de créer un instantané incohérent.

Comment sauvegarder un cluster shardé et coordonner la cohérence au niveau du cluster ?

La sauvegarde d’un cluster partagé est le scénario de sauvegarde MongoDB le plus compliqué à gérer. En effet, vous devez atteindre un point cohérent dans le temps à travers plusieurs ensembles de répliques fonctionnant à des moments différents, indépendamment les uns des autres. Chaque shard a son propre oplog et son propre état, et l’ensemble de répliques du serveur de configuration est l’endroit où sont stockées les métadonnées du cluster qui associent les chunks aux shards. Une sauvegarde qui réussit à capturer des unités à différents moments est inutile par défaut, car elle crée une image incohérente de la grappe.

Le processus de coordination nécessite les étapes suivantes :

• Arrêtez l’équilibreur de blocs à l’aide de sh.stopBalancer() avant de commencer toute activité de sauvegarde. Un équilibreur actif fait migrer des blocs entre des unités de stockage pendant la sauvegarde, ce qui produit un état dans lequel le même document peut apparaître dans deux snapshots d’unités de stockage ou dans aucun.
• Désactivez toutes les migrations de morceaux planifiées pendant la durée de la fenêtre de sauvegarde afin d’éviter que le rééquilibrage automatique ne reprenne au milieu de la capture.
• Sauvegardez d’abord l’ensemble de répliques du serveur de configuration. Le serveur de configuration détient la carte de morceaux faisant autorité – la capture de ce serveur avant celle des serveurs de stockage garantit que les métadonnées reflètent l’état du cluster avant la sauvegarde.
• Capturez chaque jeu de répliques en utilisant le même processus « secondary-first » décrit ci-dessus, aussi près l’un de l’autre dans le temps qu’il est possible d’un point de vue opérationnel.
• Enregistrez l’horodatage oplog pour chaque ensemble de répliques au point de capture. Ces horodatages sont nécessaires si la restauration à un moment donné doit aligner les états des disques au cours de la récupération.
• Réactivez l’équilibreur une fois que vous avez confirmé que toutes les sauvegardes sont terminées.

MongoDB Atlas accomplit toutes ces tâches automatiquement pour les clusters hébergés par Atlas. Quant aux environnements autogérés, Percona Backup for MongoDB a l’option d’effectuer une sauvegarde coordonnée des clusters sans avoir besoin de gérer manuellement l’équilibreur.

Comment garantissez-vous la cohérence des sauvegardes lorsque vous utilisez la journalisation et WiredTiger ?

Le moteur WiredTiger (moteur de stockage par défaut pour MongoDB) écrit les données en combinant les points de contrôle et la journalisation. Au moins une fois toutes les 60 secondes (ou lorsque le journal atteint un certain seuil de taille), WiredTiger écrit un point de contrôle cohérent sur le disque. Toutes les écritures sur disque sont consignées dans un journal entre les points de contrôle. Ainsi, les fichiers de données + le journal contiendront toujours l’intégralité de l’état récupérable du système.

Pour les sauvegardes MongoDB basées sur des instantanés, cela signifie qu’un instantané du système de fichiers pris à n’importe quel moment lorsque la journalisation est activée peut être restauré en toute sécurité. L’instantané peut se trouver entre deux points de contrôle, mais WiredTiger rejouera automatiquement le journal au démarrage pour assurer la cohérence.

La seule exigence est que le journal et le répertoire de données doivent se trouver dans la même opération d’instantané. Il n’est pas acceptable de prendre un instantané séparé du répertoire des données et un autre instantané du répertoire du journal, car cela rompt la garantie de récupération.

Quelles sont les étapes pour restaurer MongoDB à partir de sauvegardes ?

Une stratégie de sauvegarde qui n’a jamais été restaurée n’est pas testée par définition. Le processus de restauration justifie le même niveau de documentation et de pratique que le processus de sauvegarde, car chaque moment où il est nécessaire n’est jamais calme.

Comment restaurer une base de données MongoDB Backup et préserver les utilisateurs et les rôles ?

Les informations sur les utilisateurs et les rôles dans MongoDB sont contenues dans la base de données d’administration , et non dans les collections qu’ils gouvernent. Une opération mongorestore sur une base de données spécifique ne restaurera pas les utilisateurs et les rôles de cette base de données. Une restauration complète (qui réécrit également la base de données d’administration ) peut, sans le savoir, supprimer des utilisateurs existants ou dupliquer des utilisateurs en conflit.

Le processus de restauration le plus sûr, qui préserve les utilisateurs et les rôles, consiste à

1. Arrêtez toutes les connexions d’application à l’instance cible avant le début de la restauration. Les connexions actives pendant une restauration créent des conditions de course entre les écritures entrantes et le processus de restauration.
2. Restaurez d’abord la base de données cible, en excluant la base de données d’administration : mongorestore –db <dbname> –drop <dump_path>/<dbname>.
3. Inspectez la base de données d’administration vidée avant de la restaurer – en particulier les collections system.users et system.roles – pour confirmer qu’il n’y a pas de conflit avec les utilisateurs existants sur l’instance cible.
4. Restaurez les utilisateurs et les rôles de manière sélective en utilisant mongorestore –db admin –collection system.users et system.roles plutôt que de restaurer la base de données admin complète en une seule fois.
5. Vérifiez l’attribution des rôles après la restauration en exécutant db.getUsers() et en confirmant que les comptes de service d’application ont les privilèges attendus.
6. Ne réactivez les connexions d’application qu’une fois la vérification terminée.

Il est recommandé d’utiliser l’option –drop (abandonner chaque collection avant la restauration) lorsque vous effectuez une restauration complète. Toutefois, il convient de l’utiliser avec prudence lorsque vous restaurez une instance qui contient déjà les données que vous souhaitez conserver.

Comment restaure-t-on un instantané physique et ramène-t-on des membres dans un ensemble de répliques ?

La restauration d’un instantané physique comporte deux étapes distinctes : les fichiers de données doivent d’abord être restaurés, puis le nœud doit être réintroduit dans l’ensemble de réplicas.

Le fait de considérer ces étapes comme un processus unique est souvent à l’origine de nombreux problèmes.

Phase 1 – Restauration de l’instantané :

1. Arrêtez complètement le processus mongod sur le nœud cible avant de toucher aux fichiers de données.
2. Effacez le répertoire de données existant pour éviter que WiredTiger ne rencontre des fichiers de stockage conflictuels au démarrage.
3. Montez ou copiez l’instantané dans le répertoire de données, en veillant à ce que les fichiers de données et le répertoire du journal soient présents et intacts.
4. Démarrez mongod en mode autonome – sans l’option –replSet – pour permettre à WiredTiger de terminer son processus de récupération et d’atteindre un point de contrôle propre avant que les opérations d’établissement de répliques ne reprennent.

Phase 2 – Réintégration dans l’ensemble de réplicas :

1. Arrêtez le mongod autonome une fois que la passe de récupération s’est terminée proprement.
2. Redémarrez mongod avec le drapeau–replSet restauré à son nom d’ensemble de réplicas original.
3. Ajoutez le membre en utilisant rs.add() à partir du primaire s’il a été supprimé, ou permettez-lui de se joindre automatiquement s’il n’était que temporairement hors ligne.
4. Surveillez la progression de la synchronisation initiale – si l’instantané est suffisamment récent, le membre n’appliquera que les entrées de l’oplog qu’il a manquées plutôt que d’effectuer une synchronisation initiale complète à partir de zéro.

Remarque importante : un instantané plus ancien que la fenêtre de rétention de l’oplog va déclencher un processus complet de synchronisation initiale, quelles que soient les autres circonstances, ce qui peut être un processus long lorsqu’il s’agit d’ensembles de données volumineux et complexes.

Comment effectuer une restauration ponctuelle à l’aide d’oplog ou de sauvegardes dans le nuage ?

La restauration ponctuelle est un processus en deux étapes, qu’elle soit effectuée via oplog replay sur un cluster autogéré ou via l’interface Atlas. La première étape prépare la scène, en prenant un instantané complet de l’état du cluster avant le point de restauration. La deuxième étape prend cet instantané et le fait progresser en rejouant uniquement les opérations effectuées entre l’instantané et l’heure cible.

Pour une récupération autogérée basée sur oplog, mongorestore accepte le drapeau –oplogReplay avec un dump qui a été capturé avec –oplog. L’option –oplogLimit spécifie le plafond d’horodatage – en secondes depuis l’époque – au-delà duquel les entrées oplog ne sont plus appliquées. Pour identifier l’horodatage correct, il faut inspecter les journaux oplog ou les journaux d’application afin de localiser la dernière « bonne » opération avant l’événement qui a déclenché la restauration.

Pour la restauration ponctuelle d’Atlas, l’ensemble du processus est réalisé à l’aide de l’interface utilisateur ou de l’API d’Atlas. Une date cible est sélectionnée dans la fenêtre de rétention, Atlas construit la restauration en interne et le cluster récupéré est provisionné comme une nouvelle instance. Le cluster d’origine n’est pas écrasé par défaut, ce qui préserve sa capacité à comparer les états avant de s’engager dans le point de récupération.

Dans les deux scénarios, l’étape que toutes les équipes ont tendance à sauter lorsqu’elles sont sous pression est la vérification de l’état récupéré, avant la mise hors service de la machine de production. C’est également cette étape qui permet de découvrir les index manquants, les autorisations utilisateur incorrectes et les restaurations incomplètes avant la mise en production.

Comment gérez-vous les différences de version entre la sauvegarde et la version cible de MongoDB ?

La restauration d’une sauvegarde MongoDB d’une version à une autre présente un réel danger. Le format de stockage de WiredTiger peut changer, tout comme le schéma oplog et les drapeaux de compatibilité des fonctionnalités, ce qui peut entraîner l’échec d’une sauvegarde ou le démarrage d’une base de données qui ne fonctionne pas correctement.

Voici quelques-uns des exemples les plus courants de scénarios de restauration :

L’indicateur Feature Compatibility Version (FCV) est le mécanisme utilisé par MongoDB pour restreindre l’accès aux fonctionnalités spécifiques à une version. Une base de données restaurée à partir d’une sauvegarde 6.0 sur une instance 7.0 commencera avec FCV fixé à 6.0, limitant l’accès aux fonctionnalités 7.0 uniquement jusqu’à ce que setFeatureCompatibilityVersion soit explicitement exécuté.

Ne mettez pas à niveau FCV tant que la base de données restaurée n’a pas été validée – il n’est pas possible de revenir en arrière une fois qu’elle a été définie.

Lorsque la différence de version est inévitable, il est préférable de restaurer les données sur un système ayant la même version que la source de sauvegarde, de valider les données, puis d’effectuer une mise à niveau standard sur place.

Comment automatiser et planifier les sauvegardes de MongoDB de manière fiable ?

Une sauvegarde de MongoDB qui doit être lancée par quelqu’un n’est pas une stratégie. C’est une habitude, et les habitudes liées aux processus de sauvegarde manuels sont souvent oubliées en cas d’urgence. L’automatisation élimine l’élément humain de cette équation, mais elle ne peut être utile que si elle survit aux situations qui rendent les sauvegardes nécessaires – un serveur très chargé, un réseau peu fiable ou un problème d’infrastructure.

Quels sont les modèles de planification qui minimisent la charge et respectent votre RTO/RPO ?

La planification des sauvegardes est toujours un compromis entre la fréquence et l’impact. L’exécution d’un mongodump toutes les heures sur un serveur primaire à forte capacité d’écriture permet d’atteindre des RPO agressifs, mais met les sauvegardes en concurrence avec le trafic de production pour les mêmes performances d’E/S. La solution consiste ici à ne pas effectuer de sauvegardes sur un serveur primaire. La solution n’est pas d’effectuer moins de sauvegardes, mais de les aborder de manière plus intelligente.

La règle numéro un est de sauvegarder en dehors des heures de pointe. Dans la majorité des cas, cela signifie tard le soir ou tôt le matin dans le fuseau horaire de l’utilisateur principal. Toutefois, il existe certaines exceptions pour lesquelles il n’y a pas de « période creuse », comme les plateformes analytiques, les applications financières ou les applications distribuées à l’échelle mondiale. Dans ces situations, le transfert de la sauvegarde vers un système secondaire répliqué est une étape essentielle et non facultative.

La règle numéro deux consiste à aligner les types de sauvegarde et leur fréquence. L’exécution de sauvegardes complètes est coûteuse – les effectuer quotidiennement ou hebdomadairement est plus que suffisant dans la plupart des cas. Les sauvegardes incrémentielles de MongoDB ou les processus d’archivage d’oplogs comblent les lacunes entre les sauvegardes complètes – elles sont généralement effectuées toutes les heures ou même en continu sans impact notable sur les performances.

En gardant cela à l’esprit, nous pouvons former un petit tableau avec les suggestions pour les différentes options de fréquence de sauvegarde :

Comment rendre les outils d’orchestration, les scripts ou les tâches cron résilients et idempotents ?

La condition d’échec la plus fréquemment observée pour un processus d’automatisation de la sauvegarde et de la restauration de MongoDB est un script qui échoue silencieusement. Un job cron qui existe avec un code non nul, qui n’écrit pas de données sur la cible et qui n’alerte pas peut passer inaperçu pendant des jours, voire des semaines. La toute première indication d’une telle tâche est généralement l’échec d’une opération de restauration qui ne parvient pas à trouver les données qu’elle est censée restaurer.

La résilience commence par une gestion explicite des échecs. Chaque script de sauvegarde doit vérifier que la sortie qu’il a produite n’est pas vide et qu’elle se situe dans une fourchette de taille attendue avant de se terminer avec succès. Un mongodump qui se termine mais qui écrit une archive presque vide – ce qui arrive lorsque des problèmes de connexion interrompent l’exportation en cours de route – doit être traité comme un échec, et non comme un succès. Les codes de sortie ne suffisent pas.

L’idempotence est importante lorsque les sauvegardes font partie d’un pipeline d’orchestration plus large. Un travail de sauvegarde qui peut être exécuté deux fois sans craindre de produire un doublon ou des artefacts conflictuels est beaucoup plus facile à récupérer si un planificateur l’exécute deux fois en raison d’un chevauchement de temps ou d’une logique de réessai. Il est donc nécessaire d’avoir une sortie d’écriture vers des destinations nommées de manière unique – noms de fichiers horodatés ou clés de stockage d’objets – tout en utilisant des opérations de déplacement atomiques au lieu d’écrire directement sur le chemin final. Une sauvegarde partiellement écrite qui se trouve sur le chemin de destination (impossible à distinguer d’une sauvegarde complète) est l’un des modes d’échec les plus insidieux dans l’ensemble du pipeline de sauvegarde et de restauration de MongoDB.

Pour les équipes disposant d’outils d’infrastructure existants, des outils comme Ansible, Kubernetes CronJobs et Airflow peuvent tous offrir des environnements d’exécution beaucoup plus observables et contrôlables par rapport à un cron brut. Ils offrent une logique de réessai intégrée, un historique d’exécution et des crochets d’alerte que le cron de base n’a tout simplement pas.

Comment surveiller les tâches de sauvegarde et alerter en cas d’échec ?

La surveillance d’un pipeline de sauvegarde MongoDB ne se limite pas à savoir si la tâche s’est exécutée au départ. Une tâche qui s’exécute mais génère une sauvegarde corrompue ou incomplète est bien pire qu’une tâche qui échoue bruyamment – parce que seule la première situation crée un sentiment de fausse confiance. Les mesures qui valent la peine d’être suivies dans ces situations sont les suivantes :

• Les sauvegardes sont réussies, mais la taille du fichier de sortie a considérablement diminué par rapport à l’exécution précédente, ce qui est le signe d’une capture partielle ou d’une interruption de connexion au milieu de la vidange.
• La durée de la sauvegarde a augmenté de manière substantielle sans que le volume de données n’augmente en conséquence – il s’agit souvent d’un indicateur précoce de contention d’E/S ou de décalage de réplication sur la source secondaire.
• L’emplacement de stockage de destination n’a pas reçu de nouvelle sauvegarde dans la fenêtre prévue – attrape les cas où le planificateur lui-même a échoué ou le travail a été silencieusement ignoré.
• Les résultats des tests de restauration, qui doivent être exécutés régulièrement sur un échantillon de sauvegarde, montrent des erreurs ou produisent une base de données qui échoue aux contrôles de validation au niveau de l’application.

Les alertes relatives à ces conditions doivent être envoyées au même pipeline d’astreinte que les alertes d’infrastructure, et non dans une boîte de réception distincte qui n’est consultée que sporadiquement.

Comment la sécurité et la conformité affectent-elles les pratiques de sauvegarde de MongoDB ?

Une sauvegarde est un duplicata des données critiques qui est stocké dans un endroit situé en dehors des limites de sécurité de la base de données de production. Tous les contrôles d’accès, niveaux de cryptage et audits doivent être au moins aussi sûrs – sinon plus – que la base de données de production.

Comment les sauvegardes doivent-elles être chiffrées au repos et en transit ?

Le chiffrement au repos garantit que les fichiers de sauvegarde stockés sur disque, bande ou stockage d’objets sont illisibles sans la clé de déchiffrement correspondante.

Pour les fichiers de sauvegarde MongoDB écrits sur le stockage d’objets, cela signifie activer le chiffrement côté serveur sur le panier de destination – AES-256 via AWS S3, Google Cloud Storage, ou Azure Blob Storage – ou chiffrer l’archive de sauvegarde avant qu’elle ne quitte le système source (avec un outil comme GPG). La clé de chiffrement doit être stockée séparément de la sauvegarde elle-même ; une clé stockée avec les données qu’elle protège n’offre aucune protection significative.

Le chiffrement en transit garantit que les données de sauvegarde se déplaçant entre l’instance MongoDB, l’agent de sauvegarde et la destination de stockage ne peuvent pas être interceptées.

TLS doit être appliqué à toutes les connexions mongodump en utilisant l’option –tls et la configuration du certificat correspondant. Pour les solutions de sauvegarde gérées par une plateforme comme Atlas Backup ou Bacula Enterprise, le cryptage du transport est géré par la plateforme – mais il est toujours utile de vérifier que la configuration applique TLS plutôt que de simplement le supporter en tant qu’option.

Comment contrôler l’accès aux sauvegardes et appliquer le principe du moindre privilège ?

Les fichiers de sauvegarde MongoDB devraient avoir les mêmes contrôles d’accès que la base de données de production. Il est important d’essayer de limiter autant que possible le nombre d’utilisateurs et d’applications qui peuvent lire/écrire ou supprimer les fichiers de sauvegarde en utilisant les mesures suivantes :

• Les volumes de stockage de sauvegarde doivent refuser l’accès public par défaut, l’accès n’étant accordé qu’aux comptes de service spécifiques et aux rôles IAM requis par le pipeline de sauvegarde.
• L’accès humain aux fichiers de sauvegarde doit être explicitement approuvé et enregistré – les tests de restauration de routine doivent utiliser un compte de restauration dédié à faible privilège plutôt que des informations d’identification administratives.
• Les autorisations d’écriture et de suppression sur les destinations de sauvegarde doivent être séparées – le système qui crée les sauvegardes ne doit pas avoir la capacité de les supprimer, ce qui limite le rayon d’action d’un agent de sauvegarde compromis.
• Les journaux d’accès aux sauvegardes doivent être conservés indépendamment des fichiers de sauvegarde eux-mêmes, de sorte que l’historique des accès subsiste même si les sauvegardes sont supprimées.
• Le stockage inter-comptes ou inter-projets doit être utilisé dans la mesure du possible, afin qu’un environnement de production compromis n’accorde pas automatiquement l’accès aux données de sauvegarde.

Quel est l’impact des politiques de conservation et des exigences en matière de suppression des données sur la stratégie de sauvegarde ?

La politique de conservation des données dans le cadre de la sauvegarde tire dans deux directions opposées. L’aspect opérationnel suggère une préférence pour une très longue période de rétention des sauvegardes – plus vous pouvez restaurer loin en arrière, plus il y a de choix de sauvegardes. L’aspect conformité (GDPR, CCPA, HIPAA) suggère une préférence pour la suppression – si un utilisateur demande que des données soient supprimées du système réel, elles doivent également être supprimées des sauvegardes.

Cela crée une véritable tension pour la stratégie de sauvegarde de MongoDB. Une sauvegarde immuable qui ne peut être ni modifiée ni supprimée répond aux exigences de protection contre les ransomwares, mais entre en conflit avec le droit à l’effacement.

La solution pratique consiste en un modèle de conservation à plusieurs niveaux : des sauvegardes à court terme qui sont mutables et soumises à des demandes d’effacement, et des sauvegardes d’archivage à long terme qui contiennent des données anonymisées ou pseudonymisées dont les enregistrements individuels ont été nettoyés avant d’être archivés. Pour mettre en œuvre cette solution, il faut que le pipeline de sauvegarde soit conscient de la classification des données – quelles collections contiennent des données personnelles et lesquelles n’en contiennent pas – plutôt que de traiter tous les résultats des sauvegardes MongoDB comme équivalents.

Comment les sauvegardes immuables et la protection contre les ransomwares s’appliquent-elles à MongoDB ?

Les ransomwares qui ciblent l’infrastructure de sauvegarde se concentrent sur la destruction des options de restauration avant le déploiement de la charge utile du ransomware. Si l’attaquant a la possibilité de supprimer ou de chiffrer les fichiers de sauvegarde, le principal moyen de défense contre le paiement d’une rançon est détruit. Les sauvegardes immuables (fichiers qui ne peuvent être ni modifiés ni supprimés pendant une durée déterminée) sont l’une des nombreuses options permettant d’éliminer cette possibilité.

Les mécanismes qui assurent l’immutabilité au niveau de la couche de stockage sont les suivants :

• Le verrouillage des objets S3 en mode conformité empêche la suppression ou l’écrasement des objets de sauvegarde pendant la période de rétention configurée, même par le propriétaire du compte ou les utilisateurs administratifs.
• Le stockage WORM (Write Once Read Many) sur les systèmes sur site offre une protection équivalente à l’infrastructure de sauvegarde sur bande et sur disque.
• Des comptes cloud ou des unités organisationnelles distincts pour le stockage des sauvegardes garantissent que les informations d’identification compromises dans l’environnement de production n’autorisent pas l’accès au compte de sauvegarde.

Comment les sauvegardes « air-gapped » ou « offline » peuvent-elles réduire l’impact d’une violation ?

Une sauvegarde en aérien est physiquement ou logiquement déconnectée de tout réseau qu’un pirate pourrait atteindre depuis l’environnement de production.

Pour la sauvegarde de MongoDB, cela signifie généralement une exportation périodique vers une bande, un disque hors ligne ou un environnement en nuage sans accès programmatique aux systèmes de production. Le point de récupération d’une sauvegarde air-gapped est limité par la fréquence à laquelle la brèche est franchie pour écrire de nouvelles données – des transferts quotidiens ou hebdomadaires sont courants – ce qui fait des copies air-gapped les plus appropriées pour agir comme une couche de récupération de dernier recours plutôt que comme le principal moteur du flux de travail de récupération de la base de données.

Le compromis ici est également délibéré : une sauvegarde plus lente et moins fréquente qui survit à une compromission totale de l’infrastructure est plus précieuse dans le pire des scénarios qu’une sauvegarde continue qui est cryptée en même temps que tout le reste.

Quelles sont les meilleures pratiques pour les sauvegardes de production de MongoDB ?

Les sections ci-dessus couvrent des stratégies, des outils et des procédures individuels de manière isolée. Les meilleures pratiques sont ce qui les maintient ensemble dans un environnement de production – les normes minimales, les exigences en matière de documentation et les mesures de santé qui garantissent qu’une architecture de sauvegarde MongoDB reste fiable au fil du temps plutôt que de se dégrader silencieusement au fur et à mesure que l’infrastructure et les équipes changent et évoluent.

Quelles sont les règles minimales à mettre en place pour un déploiement en production ?

La politique de sauvegarde minimale acceptable pour MongoDB dépend de la criticité du déploiement. Un environnement de développement et une base de données de production réglementée ne nécessitent pas les mêmes contrôles, mais tous deux requièrent quelque chose de délibéré et de testé. Le tableau suivant définit les exigences de base par niveau de déploiement:

Deux exigences s’appliquent universellement, quel que soit le niveau. Premièrement, chaque sauvegarde doit être stockée dans un endroit distinct de l’instance qu’elle protège – une sauvegarde qui se trouve sur le même disque que la base de données qu’elle sauvegarde n’est pas une sauvegarde, mais une copie. Deuxièmement, toute stratégie de sauvegarde doit inclure au moins une restauration testée avant d’être considérée comme opérationnelle. Une configuration qui n’a jamais été restaurée avec succès est une hypothèse, pas une politique.

Comment documentez-vous les procédures de sauvegarde et de restauration pour les équipes de garde ?

Une documentation de sauvegarde qui n’existe que dans la tête de l’ingénieur qui a construit le pipeline échoue au moment où cet ingénieur devient injoignable – ce qui est généralement le moment exact où l’on a le plus besoin de lui. Les Runbooks doivent être écrits pour l’ingénieur qui n’a jamais touché à ce système auparavant – puisqu’il est tout à fait possible que ce soit lui qui exécute une restauration à 2 heures du matin après un incident.

Une documentation efficace sur la sauvegarde et la restauration de la base de données MongoDB comprend :

• L’emplacement de chaque destination de sauvegarde – les noms, chemins et méthodes d’accès des baquets de stockage, avec des instructions sur la manière de s’authentifier à partir d’un environnement propre.
• Les commandes exactes requises pour lancer une restauration, y compris les drapeaux, les chaînes de connexion et toutes les variables d’environnement qui doivent être définies avant le début de la restauration.
• Les résultats attendus d’une restauration réussie – à quoi ressemble un démarrage sain de mongod, quelles collections doivent être vérifiées, et comment valider que les comptes d’utilisateurs et les index sont intacts.
• Les modes d’échec connus et leur résolution – les erreurs de décalage de version, les symptômes de restauration partielle et ce qu’il faut faire si la sauvegarde la plus récente est corrompue.
• Contacts d’escalade – qui appeler si la procédure documentée ne résout pas l’incident, y compris les contacts d’assistance du fournisseur pour Atlas, Bacula, ou toute autre plateforme utilisée.

La documentation doit être conservée dans un endroit accessible en cas de panne de l’infrastructure – et non pas exclusivement dans un wiki fonctionnant sur la même plateforme que celle qui vient de tomber en panne.

Quels sont les indicateurs et les accords de niveau de service à suivre pour la santé des sauvegardes ?

La santé des sauvegardes est mesurée à l’aide de plusieurs mesures opérationnelles. Un pipeline de sauvegarde qui fonctionne techniquement mais qui produit des résultats dégradés – archives plus petites que prévu, durée accrue, fenêtres manquées – est en train d’échouer lentement, et cette défaillance ne sera visible qu’au pire moment. Les mesures suivantes fournissent des alertes précoces:

Ces mesures doivent être suivies dans la même plateforme d’observabilité que celle utilisée pour la surveillance de l’infrastructure – et non dans une feuille de calcul, ni examinées manuellement. L’alerte automatisée en cas de dépassement de seuil garantit qu’un pipeline de sauvegarde MongoDB qui se dégrade est traité avec la même urgence qu’un service de production qui se dégrade, plutôt que d’être découvert après coup.

Principaux enseignements

• Votre topologie de déploiement dans MongoDB (autonome, ensemble de répliques ou cluster partagé) détermine les méthodes de sauvegarde dont vous disposez.
• Définissez votre RTO et votre RPO avant de choisir un outil – ce sont les exigences que toutes les autres décisions doivent satisfaire.
• MongoDB Atlas Backup est l’option gérée la plus simple ; Percona Backup for MongoDB (PBM) est la meilleure alternative auto-hébergée.
• Le stockage des sauvegardes doit être crypté, contrôlé en termes d’accès et immuable – traitez-le avec la même rigueur de sécurité que la production.
• Surveillez la taille et la durée des sauvegardes, et pas seulement leur achèvement.
• Une sauvegarde qui n’a jamais été restaurée est une hypothèse – testez et documentez régulièrement vos procédures de restauration.

Conclusion

La sauvegarde et la restauration de MongoDB n’est pas un processus que l’on peut activer une fois et oublier immédiatement – c’est une discipline opérationnelle permanente qui englobe la sélection des outils, la planification, la sécurité, la documentation et les tests réguliers. La bonne stratégie pour une instance de développement autonome n’a rien à voir avec la bonne stratégie pour un cluster de production shardé servant des données réglementées, et l’écart entre ces deux contextes est à l’origine de la plupart des échecs de sauvegarde.

Les organisations qui récupèrent proprement les données perdues ne sont pas celles qui disposent des outils de sauvegarde les plus sophistiqués – ce sont celles qui ont testé leurs procédures de restauration avant d’en avoir besoin, qui ont documenté ces procédures pour les personnes qui n’étaient pas présentes lors de la construction du système, et qui ont traité la santé des sauvegardes comme une mesure opérationnelle de premier ordre plutôt que comme une réflexion a posteriori.

Questions fréquemment posées

Les sauvegardes MongoDB peuvent-elles être cohérentes à travers les architectures microservices ?

Réaliser une sauvegarde cohérente à travers des microservices qui maintiennent chacun leur propre base de données MongoDB nécessite de coordonner les horodatages des instantanés à travers tous les services simultanément – un problème d’orchestration non trivial. Dans la pratique, la plupart des équipes acceptent une cohérence éventuelle entre les sauvegardes au niveau des services et s’appuient sur une logique de réconciliation au niveau de l’application pour gérer les écarts, plutôt que de tenter une sauvegarde atomique unique entre les services.

Comment sauvegarder en toute sécurité des déploiements MongoDB multi-tenant ?

Les déploiements multi-locataires qui isolent les locataires par base de données peuvent être sauvegardés sélectivement en utilisant l’option –db de mongodump, ce qui permet une restauration par locataire sans toucher aux données des autres locataires. Les déploiements qui colocalisent les données des locataires dans des collections partagées nécessitent une logique d’exportation au niveau de l’application pour obtenir la même isolation, car mongodump opère au niveau de la collection et ne peut pas filtrer par champ de locataire en mode natif.

En quoi les déploiements MongoDB conteneurisés et basés sur Kubernetes modifient-ils la stratégie de sauvegarde ?

Les déploiements MongoDB basés sur Kubernetes – généralement gérés via l’opérateur MongoDB Kubernetes ou un StatefulSet – introduisent une infrastructure éphémère qui rend les hypothèses d’instantanés de système de fichiers peu fiables. L’approche recommandée est d’utiliser des sauvegardes logiques via mongodump déclenchées en tant que CronJobs Kubernetes, ou de déployer Percona Backup for MongoDB à côté du cluster, qui est conçu pour fonctionner nativement dans des environnements conteneurisés avec prise en charge des volumes persistants.