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.
| Outil | Format | Usage |
|---|---|---|
mongodump | BSON (types exacts) + métadonnées (index, options) | Sauvegarde d'une base ou d'une collection |
mongorestore | Lit ce que produit mongodump | Restauration |
mongoexport | JSON ou CSV | Échange de données : un tableur, un autre logiciel |
mongoimport | JSON, CSV ou TSV | Chargement de données externes |
Sauvegarder avec mongodump
# 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
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 :
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 :
| Option | Effet |
|---|---|
--db=appli_frais | Une seule base (sans elle : toutes les bases de l'instance) |
--collection=fiches | Une seule collection (avec --db) |
--excludeCollection=journal | Toutes les collections sauf celle-ci |
--query='{…}', --queryFile=filtre.json | Seulement les documents qui correspondent au filtre (avec --collection) |
--archive=fichier, --gzip | Un seul fichier, compressé |
--oplog | Sur 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.yaml | Lit 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 :
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
# 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
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.
| Option | Effet |
|---|---|
--drop | Supprime 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-02 | Restaure depuis un dossier plutôt qu'une archive |
--oplogReplay | Rejoue 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
# 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
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 :
#!/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
# 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.
mongodumpfonctionne aussi sur Atlas (sans--oplogni la baseadminsur 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éthode | Avantages | Limites |
|---|---|---|
mongodump / mongorestore | Simple, portable entre versions et serveurs, restauration d'une seule collection | Lent sur de très grosses bases ; cohérence à un instant précis seulement avec --oplog |
| Instantané du disque | Très rapide, quelle que soit la taille | Restauration de toute l'instance ; dépend de l'infrastructure |
| Sauvegarde Atlas | Rien à gérer, restauration à la minute sur les offres payantes | Dépend du fournisseur ; limitée sur l'offre gratuite |
Tester la restauration
// 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 :
- sauvegardent la base
appli_fraisdans une archive compressée datée du jour ; - sauvegardent seulement les fiches de 2026 (champ
moiscommençant par2026) ; - restaurent seulement la collection
visiteursde l'archive dans une baseappli_frais_test, en remplaçant ce qui s'y trouve ; - exportent les visiteurs (matricule, nom, prénom, région) en CSV.
Voir la réponseMasquer la réponse de l'exercice 1
# 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.
- Quelle donnée est perdue si l'on restaure simplement la sauvegarde de la nuit ? Comment s'appelle cette perte dans un PRA ?
- Propose une procédure de restauration qui ne touche pas aux visiteurs.
- Quelles mesures auraient évité l'incident ?
Voir la réponseMasquer la réponse de l'exercice 2
- 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). - Restaurer seulement
fiches, à sa place, à partir de l'archive de la nuit :mongorestore --archive=… --gzip --nsInclude='appli_frais.fiches' --drop. Le--dropne supprime que la collection restaurée ;visiteursn'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. - 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.envsé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.
mongoexportn'est pas un outil de sauvegarde : pas d'index, pas d'options, types approximatifs en CSV. Il fautmongodump.- 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é ?