Aller au contenu
Réussir mon BTS SIO

Tape une notion, une commande ou le nom d'une épreuve.

Par exemple

Chapitre 1414 minIntermédiaire

Sauvegarder et restaurer MongoDB : mongodump et mongorestore

Par Josselyn C., prof de BTS SIO. Mis à jour le .

À la fin de ce chapitre, tu sauras

  • sauvegarder une base avec mongodump ;
  • restaurer tout ou partie d'une sauvegarde avec mongorestore ;
  • automatiser les sauvegardes avec un script planifié ;
  • tester une restauration et en déduire le RPO et le RTO.

3 exercices corrigés

Sauvegarder une base MongoDB, c'est en copier les données dans un fichier qu'on pourra recharger en cas de perte. L'outil standard est mongodump, qui exporte les collections au format BSON avec la définition de leurs index ; son pendant, mongorestore, les recharge dans une base. Ce chapitre montre les commandes utiles, les automatise avec un script planifié, et insiste sur l'étape que l'on oublie : tester la restauration. Les principes généraux (règle 3-2-1, RPO et RTO, rétention, plan de sauvegarde) sont dans le cours sur la sauvegarde et le PRA.

Les outils

mongodump, mongorestore, mongoexport et mongoimport font partie des MongoDB Database Tools, un paquet séparé du serveur (version 100.x, la 100.20.0 en novembre 2026). Ils sont inclus dans l'image Docker mongo et dans le paquet Linux mongodb-org ; sur Windows et macOS, on les télécharge à part (sur macOS, Homebrew les installe après brew tap mongodb/brew : brew install mongodb-database-tools). Ils se connectent avec la même chaîne de connexion que les autres clients.

OutilFormatUsage
mongodumpBSON (types exacts) + métadonnées (index, options)Sauvegarde d'une base ou d'une collection
mongorestoreLit ce que produit mongodumpRestauration
mongoexportJSON ou CSVÉchange de données : un tableur, un autre logiciel
mongoimportJSON, CSV ou TSVChargement de données externes

Sauvegarder avec mongodump

bash
# Toute la base appli_frais, dans un dossier daté : un fichier .bson et un .metadata.json par collection
mongodump --uri="mongodb://sauvegarde:<mdp>@localhost:27017/?authSource=admin" \
          --db=appli_frais --out=dump-2026-11-02
text
writing `appli_frais.fiches` to `dump-2026-11-02/appli_frais/fiches.bson`
writing `appli_frais.visiteurs` to `dump-2026-11-02/appli_frais/visiteurs.bson`
done dumping `appli_frais.fiches` (9 documents)
done dumping `appli_frais.visiteurs` (5 documents)

Le plus pratique pour un script est une archive compressée, un seul fichier :

bash
mongodump --uri="mongodb://sauvegarde:<mdp>@localhost:27017/?authSource=admin" \
          --db=appli_frais --archive=appli_frais-2026-11-02.archive.gz --gzip

Les options les plus utiles :

OptionEffet
--db=appli_fraisUne seule base (sans elle : toutes les bases de l'instance)
--collection=fichesUne seule collection (avec --db)
--excludeCollection=journalToutes les collections sauf celle-ci
--query='{…}', --queryFile=filtre.jsonSeulement les documents qui correspondent au filtre (avec --collection)
--archive=fichier, --gzipUn seul fichier, compressé
--oplogSur un replica set, et pour toute l'instance : capture aussi les écritures faites pendant la sauvegarde, pour une copie cohérente à un instant précis
--config=/etc/mongodump.yamlLit le mot de passe (ou l'URI) dans un fichier, au lieu de la ligne de commande

Le compte utilisé est celui du chapitre 13, avec le rôle backup : il peut tout lire pour sauvegarder, mais ni modifier, ni supprimer.

Avec Docker, on lance mongodump dans le conteneur et on récupère l'archive sur la sortie standard :

bash
docker compose exec -T mongo mongodump --archive --gzip --db=appli_frais \
  -u sauvegarde -p "$MDP_SAUVEGARDE" --authenticationDatabase admin > appli_frais-$(date +%F).archive.gz

--archive sans nom de fichier écrit sur la sortie standard, que le > redirige vers un fichier de ta machine ; -T désactive le terminal interactif, qui corromprait le flux binaire.

Restaurer avec mongorestore

bash
# Restaurer l'archive dans une base de TEST, pour vérifier qu'elle est exploitable
mongorestore --uri="mongodb://sauvegarde:<mdp>@localhost:27017/?authSource=admin" \
             --archive=appli_frais-2026-11-02.archive.gz --gzip \
             --nsFrom='appli_frais.*' --nsTo='appli_frais_test.*' --drop
text
restoring `appli_frais_test.fiches` from "archive `appli_frais-2026-11-02.archive.gz`"
finished restoring `appli_frais_test.fiches` (9 documents, 0 failures)
restoring `appli_frais_test.visiteurs` from "archive `appli_frais-2026-11-02.archive.gz`"
finished restoring `appli_frais_test.visiteurs` (5 documents, 0 failures)
restoring indexes for collection `appli_frais_test.visiteurs` from metadata
restoring indexes for collection `appli_frais_test.fiches` from metadata
14 document(s) restored successfully. 0 document(s) failed to restore.
OptionEffet
--dropSupprime chaque collection avant de la restaurer : on obtient exactement l'état sauvegardé
--nsInclude='appli_frais.fiches'Ne restaure que cette collection (accepte *)
--nsFrom='appli_frais.*' --nsTo='appli_frais_test.*'Restaure sous un autre nom de base : idéal pour un test, sans toucher à la production
--dir=dump-2026-11-02Restaure depuis un dossier plutôt qu'une archive
--oplogReplayRejoue les écritures capturées par --oplog

Restaurer une collection dans une base de test, puis recopier quelques documents dans la production, est la bonne méthode pour réparer une erreur limitée (une fiche supprimée par erreur) sans écraser le travail fait depuis la sauvegarde.

Exporter et importer des données

bash
# Les fiches payées, en CSV pour le service comptable
mongoexport --uri="mongodb://appli:<mdp>@localhost:27017/appli_frais" \
            --collection=fiches --type=csv --fields=mois,etat,montantValide \
            --query='{"etat":{"$in":["VA","MP","RB"]}}' --sort='{"mois":1,"etat":1}' \
            --out=fiches-payees.csv
text
mois,etat,montantValide
2026-08,RB,512.2
2026-08,VA,184.4
2026-09,MP,562.4
2026-09,VA,898.9

En JSON, mongoexport écrit un document par ligne, au format Extended JSON, qui garde la trace des types : {"_id":{"$oid":"6a0000000000000000000001"}, …, "dateEmbauche":{"$date":"2021-09-01T00:00:00Z"}}. mongoimport sait relire ce format, ainsi que du CSV (--type=csv --headerline) : c'est la façon simple de charger une liste de visiteurs fournie par le service des ressources humaines.

Automatiser la sauvegarde

Une sauvegarde manuelle finit toujours par être oubliée. Sur un serveur Linux, un script planifié par cron fait le travail chaque nuit :

bash
#!/usr/bin/env bash
# /usr/local/bin/sauvegarde-mongodb.sh : sauvegarde quotidienne de la base appli_frais
set -euo pipefail

DOSSIER=/sauvegardes/mongodb
FICHIER="$DOSSIER/appli_frais-$(date +%F).archive.gz"
mkdir -p "$DOSSIER"

# /etc/sauvegarde-mongodb.yaml (chmod 600) contient la ligne : uri: mongodb://sauvegarde:…@localhost:27017/?authSource=admin
mongodump --config=/etc/sauvegarde-mongodb.yaml --db=appli_frais --archive="$FICHIER" --gzip

# Vérifier que l'archive n'est pas vide, puis garder 14 jours de sauvegardes locales
test -s "$FICHIER"
find "$DOSSIER" -name 'appli_frais-*.archive.gz' -mtime +14 -delete
bash
# crontab -e (compte dédié aux sauvegardes) : tous les jours à 2 h 30
30 2 * * * /usr/local/bin/sauvegarde-mongodb.sh >> /var/log/sauvegarde-mongodb.log 2>&1

set -euo pipefail arrête le script à la première erreur, au lieu de supprimer d'anciennes sauvegardes après un mongodump raté. Les fondamentaux du scripting Bash et de la planification sont dans le cours de scripting. Sur Windows Server, le Planificateur de tâches lance un script PowerShell équivalent.

Ce script ne fait que la première copie. La règle 3-2-1 en demande trois, sur deux supports différents, dont une hors site : copie l'archive vers un NAS ou un stockage objet (avec rclone ou restic), et garde au moins une copie hors ligne ou immuable, qu'un rançongiciel ne pourra pas chiffrer. Les sauvegardes contiennent des données personnelles : chiffre-les avant de les envoyer hors du site (restic chiffre nativement ; sinon gpg ou age).

Atlas et les autres méthodes

  • Atlas sauvegarde lui-même les clusters : sur l'offre gratuite, si tu actives la sauvegarde, un instantané par jour, quatre gardés ; sur les offres payantes, des instantanés continus qui permettent de revenir à n'importe quelle minute. mongodump fonctionne aussi sur Atlas (sans --oplog ni la base admin sur l'offre gratuite) : garder ta propre copie hors d'Atlas reste une bonne pratique, pour ne pas dépendre d'un seul fournisseur.
  • L'instantané du système de fichiers (LVM, ZFS, instantané de la VM) copie les fichiers de données en quelques secondes, quelle que soit la taille de la base. Il doit être pris de façon cohérente (journalisation activée, ou base verrouillée avec db.fsyncLock() le temps de l'instantané).
  • Un membre de replica set n'est pas une sauvegarde : une suppression par erreur est répliquée sur tous les membres en quelques millisecondes (réplication et sauvegarde).
MéthodeAvantagesLimites
mongodump / mongorestoreSimple, portable entre versions et serveurs, restauration d'une seule collectionLent sur de très grosses bases ; cohérence à un instant précis seulement avec --oplog
Instantané du disqueTrès rapide, quelle que soit la tailleRestauration de toute l'instance ; dépend de l'infrastructure
Sauvegarde AtlasRien à gérer, restauration à la minute sur les offres payantesDépend du fournisseur ; limitée sur l'offre gratuite

Tester la restauration

js
// Après la restauration de test, dans mongosh
const t = db.getSiblingDB('appli_frais_test');
t.fiches.countDocuments();                       // 9, comme la production au moment de la sauvegarde
t.visiteurs.countDocuments();                    // 5
t.fiches.getIndexes().map(i => i.name);          // [ '_id_', 'visiteur_1_mois_1', 'etat_1_mois_-1' ]
t.dropDatabase();                                // nettoyer après le test

Exercices

Exercice 1 sur 3 Écrire les commandes Réussi À revoir

Écris les commandes qui :

  1. sauvegardent la base appli_frais dans une archive compressée datée du jour ;
  2. sauvegardent seulement les fiches de 2026 (champ mois commençant par 2026) ;
  3. restaurent seulement la collection visiteurs de l'archive dans une base appli_frais_test, en remplaçant ce qui s'y trouve ;
  4. exportent les visiteurs (matricule, nom, prénom, région) en CSV.
Voir la réponseMasquer la réponse de l'exercice 1
bash
# 1.
mongodump --uri="$URI_SAUVEGARDE" --db=appli_frais --archive="appli_frais-$(date +%F).archive.gz" --gzip

# 2. Le filtre en Extended JSON ; mois est une chaîne AAAA-MM, un intervalle suffit
mongodump --uri="$URI_SAUVEGARDE" --db=appli_frais --collection=fiches \
          --query='{"mois":{"$gte":"2026-01","$lte":"2026-12"}}' --archive=fiches-2026.archive.gz --gzip

# 3.
mongorestore --uri="$URI_SAUVEGARDE" --archive=appli_frais-2026-11-02.archive.gz --gzip \
             --nsInclude='appli_frais.visiteurs' --nsFrom='appli_frais.*' --nsTo='appli_frais_test.*' --drop

# 4.
mongoexport --uri="$URI_LECTURE" --db=appli_frais --collection=visiteurs \
            --type=csv --fields=matricule,nom,prenom,region --out=visiteurs.csv

Pour la 2, les apostrophes simples empêchent le shell d'interpréter les $ du filtre. Pour la 4, Sophie Lambert, qui n'a pas de région, aura une colonne region vide.

Tu avais trouvé ?

Exercice 2 sur 3 Analyser un incident Réussi À revoir

Lundi matin, la collection fiches a été vidée par un script de test lancé par erreur sur la production à 9 h 10. La sauvegarde de la nuit (2 h 30) existe. Entre 2 h 30 et 9 h 10, une vingtaine de visiteurs ont saisi des frais.

  1. Quelle donnée est perdue si l'on restaure simplement la sauvegarde de la nuit ? Comment s'appelle cette perte dans un PRA ?
  2. Propose une procédure de restauration qui ne touche pas aux visiteurs.
  3. Quelles mesures auraient évité l'incident ?
Voir la réponseMasquer la réponse de l'exercice 2
  1. Les saisies faites entre 2 h 30 et 9 h 10 : environ 6 h 40 de travail. C'est la perte de données maximale admise, le RPO : avec une sauvegarde par nuit, il vaut jusqu'à 24 heures. Il faudra demander aux visiteurs de ressaisir leurs frais du matin, ou réduire le RPO (sauvegardes plus fréquentes, --oplog, sauvegarde continue d'Atlas).
  2. Restaurer seulement fiches, à sa place, à partir de l'archive de la nuit : mongorestore --archive=… --gzip --nsInclude='appli_frais.fiches' --drop. Le --drop ne supprime que la collection restaurée ; visiteurs n'est pas touchée. Avant, faire une sauvegarde de l'état actuel (même vide) pour garder une trace, prévenir les utilisateurs, et vérifier après coup le nombre de fiches et les index.
  3. Un compte au moindre privilège pour les scripts (le rôle sur mesure du chapitre 13 refuse drop) ; des chaînes de connexion distinctes entre test et production, dans des fichiers .env séparés ; une base de test sur un autre serveur ; et des sauvegardes plus fréquentes si la perte d'une matinée n'est pas acceptable.

Tu avais trouvé ?

Exercice 3 sur 3 Critiquer un plan de sauvegarde Réussi À revoir

Un étudiant écrit dans son dossier E6 : « La base MongoDB est sauvegardée : elle tourne en replica set de trois membres, et je fais un mongoexport de chaque collection une fois par semaine sur le même serveur. » Relève les problèmes.

Voir la réponseMasquer la réponse de l'exercice 3
  • Un replica set n'est pas une sauvegarde : il protège de la panne d'un serveur, pas d'une suppression ou d'un chiffrement par rançongiciel, répliqués aussitôt.
  • mongoexport n'est pas un outil de sauvegarde : pas d'index, pas d'options, types approximatifs en CSV. Il faut mongodump.
  • Une fois par semaine : jusqu'à 7 jours de saisies perdues (RPO). Quotidien au minimum pour des données de travail.
  • Sur le même serveur : la panne du disque ou le rançongiciel emportent la base et ses sauvegardes. Il faut des copies sur un autre support et hors site (règle 3-2-1).
  • Aucun test de restauration n'est mentionné : sans lui, rien ne prouve que les sauvegardes sont exploitables.

Tu avais trouvé ?

Chapitre terminé !

Fais les 3 exercices avant de passer à la suite : c'est en t'entraînant que tout se fixe.

chapitres
–
de série
–
du cours
–
Chapitre suivant : Exercices MongoDB corrigés, méthode pour l'E6 et aide-mémoireRevoir le sommaire du cours