Upgrade mongodb 2.0.7 to latest version

I’m running MongoDB shell version: 2.0.7 and I would like to make a backup of my database and upgrade my server to the latest version. so, I was wondering:

  1. Is it possible to make a backup of the database since “mongodump” doesn’t work. What options do I have?
  2. Is it possible to import that backup into a new server running MongoDB shell version v5.x ?


Hi @Fabio_Perez and welcome in the MongoDB Community :muscle: !

  1. mongodump v2.0.7 is able to create a backup of your cluster in 2.0.7 in theory at least. What’s the issue?
  2. Not directly because the dump made by 2.0.7 isn’t compatible with 5.0.X for sure. It’s MMAPv1 vs WiredTiger for a start. Many manyyyy things changed since September 2011

Some questions for you:

  1. Are you running mongod (the cluster) and mongo (the mongo shell) both in 2.0.7?
  2. How many GB are we talking to migrate here?
  3. Is this a Replica Set or a standalone?

In theory, the “normal” way to upgrade would be to follow the upgrade instructions from each major release and upgrade your cluster from major releases to major releases… But this would mean for you: 2.0.7 => 2.2.X => 2.4.X => 2.6.X => 3.0.X => 3.2.X => 3.4.X => 3.6.X => 4.0.X => 4.2.X => 4.4.X => 5.0.X (with X being the biggest minor version number as possible each time).

You can find the doc for each major releases but here is an example doc for RS 4.0: https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-replica-set/

Depending on the amount of data, MAYBE using mongoexport / mongoimport could be a solution as it’s JSON instead of BSON but it depends what’s in your data as well. You might have problems with data types, etc. If you only have basic values (string, bool, int, …) then maybe it could be a solution. But that’s a lot of IFs and no guarantee without testing & checking.


Hi Maxime,
Thanks for all that information.

  1. I’ll say that I would like to make a backup for the database from a remote server because I don’t have much space left on the server to store a local backup.
    So, from a newer remote server running Mongo 5.x I run the following command
    mongodump --host IP_server --db ping --out /home/mongos/mongo2x-`date +"%m-%d-%y"` --gzip
    and I got this error:
    Failed: can't create session: could not connect to server: server at reports wire version 0, but this version of the Go driver requires at least 2 (MongoDB 2.6)
    I understand that I need to have Mongo 2.6 running to use the command, but I’m running 2.0.7 so I’m not sure what are my options to make a backup and store that on a remote server.

Here are my answers to your questions:

  1. The server is running Debian 6.0.5 so I’m not sure how to know if I’m running mongod. Here is what I see when I try to check if the service is running.
Checking status of database: mongodb running.
  1. The DB is 47.93GB so far
  2. Is there a way I can check if it is a replica?
    I went to the /etc/mongodb.conf file
    and almost at the bottom I see
master = true
sourse = server2_hostname

Then I went to the config file of that other server and it has this:

slave = true
source = server1_hostname

Tho the replSet value is commented out so it does not have a name.
Does this mean that the replicaSet is active and the DBs are mirrored?

If the data is mirrored between the 2 servers, what would be the process to update ? should try to update the mongodb version on the second server (slave) to at least 2.6 to use mongodump ?

Thanks for your help with this.

Just as an update. I’m running mongod on the same version:

mongod --version
db version v2.0.7, pdfile version 4.5

Hi @Fabio_Perez,

It’s normal that you got this error. mongodump latest version (currently packaged with the other Mongo Tools in v100.5.3) isn’t compatible with MongoDB 2.0.X.

It supports MongoDB 4.0 => 5.0. So the good news is, when you reach 4.0, you should be able to mongodump your 4.0 server and mongorestore in a 5.0 final cluster directly.

Since relatively recently (couple of years top but I would say one year) the tools aren’t shipped anymore directly with the mongod binaries. They now follow independent release cycles.

2.0.X is so old that I never touched that version. I wouldn’t touch it with a stick! :smiley: When I see the “master” and “slave” terms, I think it’s because “Replica Set” wasn’t yet a concept at the time and the replication was still really primitive. So yes, I think they are “mirrored” with the old school system.

What I would do if I was in your shoes:

  • Do NOT touch the prod or try to upgrade it.
  • Stop write operations on the prod env.
  • On a new machine, download the MongoDB 2.0.7 binaries. In there you will have mongodump, mongorestore and mongod.
  • Use mongodump 2.0.7 against the 2.0.7 “cluster” and backup the data.
  • Download 2.2.X binaries.
  • Start a mongod 2.2.X single node / standalone
  • use mongorestore 2.2.X to import the data in this new 2.2.X version.
  • Download 2.4.X binaries.
  • Repeat…

I would check the Production Notes / Upgrade instructions for each versions to check if there aren’t additional checks or command to run for specific versions. But it should be more or less OK. Long and annoying but at least this should work…

If you want to speed up the process, you could technically just replace the binaries and keep the same data folder when you start the new mongod version. If you choose this alternative, you definitely need to read the upgrade instructions because you’ll have to run a few additional commands. For example db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } ) is a command that you will need for each version. But you will also have extra “problems” with this approach. For example in v 2.6 => 3.0, you have to upgrade from MMAPv1 => WiredTiger.

So I think in your case, I would dump/restore until 3.0. Then starting from 3.0 it’s faster to just restart the node with the new binaries of the next major release (like 3.0.X => 3.2.X where X is as high as possible) and apply the required extra commands to finish the migration. And repeat until you reach 4.0.
Then you could just use the final latest version of mongodump 100.5.3 and do a final dump => restore in 5.0.9.

It’s a bit complicated when you have to upgrade 11 years of innovations… :sweat_smile:

Am I making sense or I just confused you even more at this point? The cool thing is that if you fail, you can always start over from scratch and don’t destroy the current prod.


Hi Maxime,
Thanks for all that information. You didn’t confuse me a lot LOL but it does seems like a lot of work to catch up with 11 years of innovations hehehehe.

  1. I was wondering how to download the binaries. I wen to this link: Release notes for 2.x
    and at one point there, it says “Download the binaries from this link” but that link redirects to someplace else. So I’m not sure as to where I can find all the binaries I need.

  2. Since the data on the backup is changing all the time because it’s live production data. Once I made the first backup on the new server, and run all the updates until almost the latest mongo version, that would mean that the data from that backup won’t be the same as the one currently in production. assuming It take me just 1 day doing all version updates.
    If what I’m saying makes sense and it’s true. doing this won’t help me at all because I can update the server while is life so I would lose data while doing the update. right? so maybe is not worth the time doing it? and just leave the server as is until the end of time?

Thanks again for the support

I went here to try to find the archives:

It leads to this link:



So you can go to the source where I assume there is truly evrything!


I hope you find what you need :slight_smile: !

Also, another solution could be to one shot it complete with mongoexport & mongoimport. If you export everything in JSON and these files are correct without complex types, there is no reason why it wouldn’t work. It’s gonna take a long time but… Maybe it’s worth it rather than doing the entire upgrade path. I would give it a shot maybe? mongoexport 2.0.7 a small collection and see if you can mongoimport 100.5.3 in 5.0.9 ?


1 Like

Hi @Fabio_Perez,

I joined MongoDB when 2.0 was the current release, so I have some familiarity although we’re digging into ancient history now ;-).

A few questions about your environment & goals:

  • Is 48Gb the size of your data files or the size of the data?

  • Is downtime during upgrades acceptable?

  • Is your cluster hosted in the cloud (or does it have great connectivity)?

  • Do you have a representative staging/QA environment where you can test upgrade processes?

  • Have you already looked at updating your MongoDB driver versions? There have been significant changes in wire protocol and API since MongoDB 2.0, so a driver upgrade will likely be a prerequisite to your server upgrades.

Some thoughts:

  • Given the size of your data set I would be inclined to perform in-place upgrades (take backups before and after each major version upgrade!) rather than doing a mongodump & mongorestore as those will require downtime and dumping all data through mongod in order to recreate the data files. In-place upgrades are relatively straightforward and quick – the most time consuming aspect is normally validation.

  • Before upgrading I would change from the deprecated Master/Slave topology to the modern Replica Set topology which will allow you to do rolling upgrades to newer server versions.

  • Follow the instructions in the documentation for doing in-place upgrades, for example Upgrading to MongoDB 2.2. Make sure you check the instructions for each major release as there will be some different steps given the wide range of versions you are upgrading through.

  • If you are looking for older server binaries you may find m helpful: https://github.com/aheckmann/m. You should be able to use this to download generic Linux binaries. m downloads and unpacks the binary tarballs and I expect these will be easier to work with than older server packages which will no longer have verifiable signatures (due to expiry).

  • Related reading: Replace mongodb binaries all at once? - #3 by Stennie. If you can get your deployment to a new enough version where automation can be used, you can potentially reduce the number of upgrade steps to get to a non-EOL server version.

If downtime is acceptable and you want to try the mongodump/mongorestore path (not fully tested or supported):

  • Use 2.2.7 version of mongodump to backup your deployment. The 2.2 version of mongodump captures index definitions in *.metadata.json files.

  • Try using latest version of mongorestore to restore this backup into a 5.0 deployment. You may encounter some errors due to stricter validation of collection options and indexes, but they should be fixable (you may have to edit the metadata.json file).