Between 2.4 -> 2.6 a change to the underlying system.users layout when auth is enabled made it so that any backups taken on 2.4 could not be restored onto 2.6 and used cleanly.

This poses a problem in terms of usability of backups. While it may be a lot to ask, and the infrastructure currently does not support it, mongodump/restore should be capable of dealing with these schema version changes appropriately and transparently.

The way it currently works, backwards compatibility break whenever a metadata change is made and it makes us do a rolling upgrade to safely view our data in new versions. This somewhat defeats the purpose of backups if they're not usable right out of the box.

Let's say I am in a highly regulated space and I am audited. They want to review the last 5 years worth of data.

1. Mongodump does not clearly label the version of the data it has backed up, so I'm playing a guessing game to figure out what backups go to what versions depending on when we upgraded, what that deployment is, etc.

2. I cannot simply restore the last 5 years of information to one deployment with a db for each backup. Not easily anyway. Must launch several different deployments.

3. I must continue to internally support old versions of mongodb and have them built for my environment and ready to deploy JUST for this. Can't deprecate versions of mongo when we've moved on to newer versions for compliance purposes now.

4. Also, can no longer restore JUST a DB using mongorestore. I must also remember to restore the admin database separately to get auth information. Furthermore, you have to be careful about using the -d -c flags as renaming the db/collection won't be picked up by the admin database and when you restore that, auth will be incorrect since users will point to the wrong db name.