Sauvegarde et restauration MongoDB (mongodump, mongorestore, snapshot)

Met en place la sauvegarde d'un MongoDB déjà installé et décrit, scénario par scénario, la restauration depuis une sauvegarde. Sauvegarde : mongodump d'une collection, d'une base ou de tout le déploiement (--archive --gzip ; sur un replica set, point cohérent avec --oplog et lecture depuis un secondary), fichier d'identifiants, sauvegardes planifiées avec rétention via systemd timer/cron, restauration de test et snapshot de système de fichiers en option. Restauration : répétition de restauration, restauration complète, base ou collection unique, retour à un instant précis avec sauvegarde + oplog, clone vers un autre cluster et sharded cluster. Pour des centaines de Go de données, lorsqu'un retour rapide est exigé ou sur un sharded cluster, on préfère un snapshot ou un outil d'entreprise (PBM, Ops Manager) à mongodump ; le choix est expliqué dans les premières étapes.

Topologie: Serveur de sauvegarde ou un membre + replica set / instance unique / sharded cluster (mongos)

Scénarios

• Mettre en place la sauvegarde : mongodump, planification et restauration de test — Utilisateur de sauvegarde, fichier d'identifiants, mongodump manuel et planifié, restauration de test sous un autre nom ; snapshot et mongoexport en option. Commencez ici si c'est une première mise en place.
• La sauvegarde est-elle vraiment restaurable ? (--dryRun et répétition sur une instance temporaire) — Sans toucher aux données de production : intégrité de l'archive, namespaces et oplog qu'elle contient et, en option, restauration complète dans un mongod temporaire avec comptage des documents.
• Restaurer toutes les données depuis la sauvegarde (restauration complète, --drop) — Les données sont en grande partie perdues ou corrompues et le déploiement doit revenir à l'instant de la sauvegarde. Les écritures postérieures à la sauvegarde sont perdues ; l'application est arrêtée pendant la restauration.
• Récupérer une seule base ou collection (--nsInclude, sous un nouveau nom ou en place) — Une collection ou une base a été supprimée ou corrompue, le reste est intact : seul ce namespace est repris de la sauvegarde ; les autres données ne sont pas touchées et l'application peut rester en service.
• Revenir à un instant précis : sauvegarde + oplog (drop accidentel, update/delete erroné) — L'opération erronée a eu lieu après la sauvegarde et les écritures jusqu'à cet instant sont aussi nécessaires : la dernière sauvegarde complète est restaurée, puis l'oplog de production est rejoué jusqu'à juste avant l'opération erronée (--oplogReplay --oplogLimit). Replica set uniquement.
• Restaurer la sauvegarde sur un autre cluster / serveur (clone, environnement de test, migration) — Le déploiement source n'est pas touché : la sauvegarde est restaurée sur un autre replica set ou une autre instance (copie de test ou de reporting, migration de serveur, montée de version) ; les utilisateurs sont migrés en option.
• Restaurer un sharded cluster : les limites de mongodump et la bonne méthode — La topologie sauvegardée est un sharded cluster : restauration logique via mongos (recréation des shard keys, balancer) ou reconstruction physique de tout le cluster à partir de snapshots coordonnés.

Avant de commencer

• Le serveur sauvegardé tourne sur un système d'exploitation supporté ; l'horloge est synchronisée par NTP et le fuseau horaire est correct (les noms des fichiers de sauvegarde et la planification utilisent l'heure locale).
• Depuis ce serveur, la résolution de noms et l'accès aux ports de … fonctionnent.… Sur un replica set, les noms de la chaîne de connexion doivent correspondre aux noms des membres dans rs.conf() ; le driver se connecte à ces noms.…
• … se trouve sur un disque distinct du disque de données ou sur un partage réseau, et son espace libre vaut au moins la taille de la sauvegarde compressée (en général 20–50 % des données) multipliée par la durée de rétention. Une sauvegarde sur le même disque disparaît avec les données si le disque est perdu.
• L'authentification est activée et vous disposez de l'utilisateur … (root, ou les rôles userAdminAnyDatabase + clusterAdmin) et de son mot de passe. L'utilisateur de sauvegarde est créé avec cet utilisateur.
• La fenêtre d'oplog est nettement plus longue que la durée d'une sauvegarde complète (au moins plusieurs heures). --oplog recueille les entrées d'oplog produites pendant la sauvegarde ; si la fenêtre est plus courte que la sauvegarde, celle-ci échoue.… Pour un retour à un instant donné, la première entrée de l'oplog de production doit être antérieure à la fin de la sauvegarde complète utilisée ; sinon, les opérations intermédiaires n'existent nulle part.…
• Un accès HTTPS au dépôt MongoDB (repo.mongodb.org) existe ou un miroir interne est défini ; si les outils sont déjà installés sur le serveur, leurs versions s'affichent.
• dbPath (…) se trouve sur le LV … et le volume group dispose d'au moins … d'espace libre. Le journal WiredTiger (…/journal) doit être sur le même LV ; s'il a été déplacé sur un autre disque, fsyncLock avant le snapshot est obligatoire.
• Vous disposez des droits root ou sudo. Si une restauration complète est prévue, une fenêtre de maintenance et l'accord de l'équipe applicative ont été obtenus.… Avant la restauration, l'incident a été consigné (quand, quelle opération, qui) ; l'équipe applicative sait quelles données vont revenir.…
• La sauvegarde a été mise en place avec le scénario « Mettre en place la sauvegarde » de ce guide : les outils (mongorestore, mongosh) et le fichier d'identifiants … (… : backup + restore) existent sur ce serveur. Sinon, appliquez d'abord les deux premières phases du scénario Mettre en place la sauvegarde.
• Une restauration réécrit les données et les index : le disque de données des serveurs cibles dispose d'un espace libre d'au moins 1,5 fois le volume (non compressé) des données restaurées.… Sur un replica set, les secondaries reçoivent les mêmes écritures par réplication ; la fenêtre d'oplog se réduit pendant la restauration.…
• … dispose d'un espace libre égal à la taille non compressée des données restaurées (sauvegarde complète + oplog). Le mongod temporaire écoute uniquement sur 127.0.0.1, port … ; ce port doit être libre.
• La cible (…) est installée et fonctionne, l'authentification est activée et vous avez le mot de passe de l'utilisateur … (root). La version cible est identique à la source ou plus récente (par ex. 7.0 → 8.0) ; la restauration vers une version plus ancienne n'est pas supportée.

Phases du guide

• Installation des outils — Ajouter le dépôt MongoDB … · Ajouter le dépôt MongoDB … · Installer mongodump, mongorestore et mongosh · Préparer le répertoire de sauvegarde
• Utilisateur de sauvegarde et fichier d'identifiants — Créer l'utilisateur de sauvegarde · Écrire le fichier d'identifiants (--config) · Tester la connexion
• Sauvegarde manuelle (mongodump) — Vérifier la taille des données et la fenêtre d'oplog · Arrêter le balancer · Prendre une sauvegarde avec mongodump · Redémarrer le balancer · Vérifier la sauvegarde (gzip et dryRun) · Sauvegarde d'un sous-ensemble par requête (--query)
• Restauration (mongorestore) — Restauration de test sous un nouveau nom (--nsFrom/--nsTo) · Comparer le nombre de documents · Supprimer la base de test · Définir un rôle pour oplogReplay · Restauration complète en place (--drop) · Retirer le droit temporaire …
• mongoexport / mongoimport (transfert de données, pas une sauvegarde) — Exporter la collection (mongoexport) · Importer dans une collection distincte (mongoimport) · Comparer les types et nettoyer
• Snapshot du système de fichiers — Prendre un snapshot LVM (avec fsyncLock) · Archiver le snapshot dans le répertoire de sauvegarde · Prendre une copie de fichiers avec fsyncLock
• Sauvegarde d'un sharded cluster : limites et solution d'entreprise — Choisir une méthode pour une sauvegarde cohérente d'un sharded cluster
• Sauvegarde planifiée et rétention — Limiter le balancer aux heures hors sauvegarde · Écrire le script de sauvegarde · Rendre le script exécutable · Préparer l'accès SSH au serveur distant · Créer le service et le timer systemd · Déclencher manuellement la sauvegarde planifiée et la vérifier …
• Supervision et maintenance — Surveiller l'âge de la dernière sauvegarde · Exercices de restauration réguliers
• 1. Diagnostic : fichiers de sauvegarde et outils — Lister les fichiers de sauvegarde et les dernières sauvegardes dans l'ordre
• 2. Répétition : lecture de l'archive — Vérifier l'intégrité de la compression (gzip -t) · Tester la restauration sans écrire de données (--dryRun) · L'archive contient-elle un oplog ? (point cohérent)
• 3. Répétition : restauration complète sur une instance temporaire — Préparer mongod pour l'instance temporaire · Démarrer le mongod temporaire · Restaurer la sauvegarde sur l'instance temporaire · Compter les données restaurées · Arrêter et supprimer l'instance temporaire
• 4. Après — Consigner le résultat de la répétition
• Sharded cluster : la restauration complète ne se fait pas avec ce scénario — Passer au scénario sharded cluster
• 1. Diagnostic : la restauration complète est-elle le bon scénario ? — Examiner l'état actuel et les données touchées · Tester la restauration sans écrire de données (--dryRun)
• 2. Filet de sécurité — Arrêter l'application et vérifier les connexions · Sauvegarder l'état actuel (point de repli)
• 3. Exécution : restauration complète — Accorder un droit temporaire pour oplogReplay · Restaurer la sauvegarde en place (--drop… --oplogReplay…) · Retirer le droit temporaire · Nettoyer les collections utilisateurs temporaires de la restauration
• 4. Vérification — Vérifier le nombre de documents et d'index · Vérifier que le replica set a rattrapé son retard
• 5. Après — Prendre une nouvelle sauvegarde complète et redémarrer l'application
• 1. Diagnostic : état actuel du namespace et état dans la sauvegarde — Examiner l'état en production · Tester la restauration sans écrire de données (--dryRun)
• 2. Filet de sécurité — Sauvegarder l'état actuel (point de repli)
• 2. Exécution : restaurer sous un nouveau nom — Restaurer la sauvegarde sous un nouveau nom (--nsFrom/--nsTo) · Comparer les comptages de la sauvegarde et de la production · Réinsérer les documents supprimés en production ($merge) · Supprimer la copie temporaire
• 3. Exécution : restaurer en place (--drop) — Préserver la shard key : resharder la collection · Restaurer le namespace en place
• Retour à un instant donné sur replica set uniquement — Le retour à un instant donné par l'oplog est impossible sur ce déploiement
• 1. Diagnostic : instant de l'opération erronée et fenêtre d'oplog — Trouver l'opération erronée dans l'oplog · Vérifier que la sauvegarde complète se trouve dans la fenêtre d'oplog
• 2. Filet de sécurité : copier l'oplog de production — Prendre une copie de l'oplog de production · Sauvegarder l'état actuel (point de repli)
• 3. Exécution : revenir à cet instant sur une instance temporaire — Préparer mongod pour l'instance temporaire · Démarrer le mongod temporaire · Restaurer la sauvegarde complète sur l'instance temporaire · Appliquer l'oplog de production jusqu'à juste avant l'opération erronée · Contrôler les données récupérées sur l'instance temporaire · Reporter en production les données récupérées …
• 4. Après — Prendre une nouvelle sauvegarde complète et traiter la cause racine
• 1. Diagnostic : la cible est-elle la bonne et est-elle compatible ? — Vérifier que la cible n'est pas la source et contrôler sa version · Tester la restauration sans écrire de données (--dryRun)
• 2. Filet de sécurité et identifiants de la cible — Écrire un fichier d'identifiants temporaire pour la cible · Sauvegarder les données existantes de la cible