Migrer sa base de données locale vers la production : ne perdez plus vos données

Le problème

Pendant le développement, tu travailles avec une base de données locale. Tu crées des articles, des utilisateurs, des données de test. Quand vient le moment de déployer en production, le serveur démarre avec une base vide.

Sans migration, tout ce que tu as créé en local disparaît. Il faut tout ressaisir manuellement. Pour 5 entrées c'est acceptable, pour 20 articles et des centaines d'abonnés c'est impossible.

La solution est d'exporter ta base locale et de l'importer sur le serveur de production.

Prérequis

MongoDB installé localement ou accessible via MongoDB Compass
MongoDB Database Tools installé sur ta machine locale
Accès SSH au serveur de production
MongoDB qui tourne dans Docker sur le serveur

1. Installer MongoDB Database Tools

Les MongoDB Database Tools contiennent les commandes mongodump et mongorestore nécessaires pour exporter et importer les données.

Télécharge les tools depuis : https://www.mongodb.com/try/download/database-tools

Choisis la version correspondant à ton système d'exploitation.

Sur Windows, après l'installation, les outils se trouvent dans le dossier bin du répertoire d'installation. Note ce chemin car tu en auras besoin.

Sur Linux/Mac :

sudo apt install mongodb-database-tools

2. Exporter la base de données locale

Sur ta machine locale, ouvre un terminal et lance :

Sur Linux/Mac :

mongodump --uri="mongodb://localhost:27017" --db=mabase --out=./backup

Sur Windows, utilise le chemin complet vers mongodump :

& "C:\chemin\vers\bin\mongodump.exe" --uri="mongodb://localhost:27017" --db=mabase --out="C:\Users\moi\Documents\backup"

Cette commande crée un dossier backup avec tous les fichiers de ta base de données au format BSON.

Vérifie que l'export a fonctionné :

ls backup/mabase/

Tu dois voir un fichier .bson et un fichier .metadata.json pour chaque collection.

3. Transférer le backup sur le serveur

Utilise scp pour transférer le dossier backup sur le serveur de production :

scp -r ./backup user@IP_SERVEUR:/home/app/

Sur Windows, tu peux utiliser WinSCP ou le terminal PowerShell avec la même commande scp.

4. Importer sur le serveur de production

Connecte-toi en SSH au serveur :

ssh user@IP_SERVEUR

Copie le backup dans le container MongoDB :

docker cp /home/app/backup/mabase mongodb:/tmp/restore

Importe les données :

docker exec mongodb mongorestore \
  -u adminUser \
  -p MotDePasseFort \
  --authenticationDatabase admin \
  --db mabase \
  /tmp/restore

Si MongoDB n'a pas encore d'authentification :

docker exec mongodb mongorestore \
  --db mabase \
  /tmp/restore

5. Vérifier l'import

Connecte-toi à MongoDB et vérifie que les données sont bien là :

docker exec -it mongodb mongosh -u adminUser -p "MotDePasseFort" --authenticationDatabase admin

use mabase
db.articles.countDocuments()
db.users.countDocuments()

Tu dois voir le même nombre de documents que dans ta base locale.

6. Garder les données synchronisées

Une fois en production, ta base locale et ta base de production vont diverger. Voici quelques bonnes pratiques :

Ne jamais écraser la base de production avec la base locale. Si tu as des utilisateurs en production, tu perdrais leurs comptes.

Utilise des données de test en local. Crée un jeu de données de test dédié au développement, distinct des données de production.

Sauvegarde régulièrement la production. Le script de sauvegarde automatique vu dans l'article sur MongoDB en production permet de récupérer les données en cas de problème.

Pour les nouvelles collections, tu peux importer depuis la production vers le local pour avoir des données réalistes en développement :

mongodump --uri="mongodb://adminUser:MotDePasseFort@IP_SERVEUR:27017/mabase?authSource=admin" --out=./backup-prod
mongorestore --uri="mongodb://localhost:27017" --db=mabase ./backup-prod/mabase

Conclusion

La migration de base de données est une étape souvent négligée lors du premier déploiement. Prendre le temps de l'automatiser et de bien la comprendre évite de perdre des heures à ressaisir des données ou pire, de perdre des données d'utilisateurs réels en production.