πŸŽ‰ Sign up for a free company account trial β€” No credit card required πŸŽ‰

Using archives to back up and restore a MongoDB database

Share this article on : Twitter, LinkedIn

I recently had to backup the data from weremote.eu and restore it on my local machine for some transformations.

I added company and professional accounts on the platform and I had to transform the current company data so that it matches the new format.

First, I backed up the data using the mongodump like illustrated below:

mongodump -h xxx.xxx.xxx.xxx \
          -u youruser \
          --authenticationMechanism SCRAM-SHA-256 \
          --authenticationDatabase authdb \
          -d the_database \
          --archive=/opt/backups/`date '+%FT%H-%M-%S-%Z'`.archive \
          --gzip

This created a neat archive called 2019-12-29T21-01-21-UTC.archive.

I was happy with what I did so I moved on to the deployment part. It all worked flawlessly.

Today I was trying to restore the database on my local machine using mongorestore so I could write the scripts I needed to write to transform the data to the new format.

But I hit this error.

[email protected]:/# mongorestore --archive=/opt/backups/2019-12-29T21-01-21-UTC.archive
2020-01-01T16:48:36.244+0000	Failed: stream or file does not appear to be a mongodump archive

Whoops! I got really scared since I had no other backup of that database.

Fortunately, before becoming frustrated enough and deleting the file out of anger, I remembered I used --gzip when I created the archive.

So I decided to run mongorestore with that argument. And it worked πŸ˜….

[email protected]:/# mongorestore --gzip --archive=/opt/backups/2019-12-29T21-01-21-UTC.archive
2020-01-01T16:49:49.249+0000	preparing collections to restore from
2020-01-01T16:49:49.269+0000	reading metadata for weremote.orders from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.283+0000	restoring weremote.orders from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.293+0000	no indexes to restore
2020-01-01T16:49:49.293+0000	finished restoring weremote.orders (46 documents)
2020-01-01T16:49:49.302+0000	reading metadata for weremote.jobpostings from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.318+0000	restoring weremote.jobpostings from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.321+0000	reading metadata for weremote.addons from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.348+0000	restoring weremote.addons from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.351+0000	no indexes to restore
2020-01-01T16:49:49.351+0000	finished restoring weremote.jobpostings (46 documents)
2020-01-01T16:49:49.351+0000	reading metadata for weremote.events from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.352+0000	no indexes to restore
2020-01-01T16:49:49.353+0000	finished restoring weremote.addons (3 documents)
2020-01-01T16:49:49.372+0000	restoring weremote.events from archive '/opt/backups/2019-12-29T21-01-21-UTC.archive'
2020-01-01T16:49:49.396+0000	no indexes to restore
2020-01-01T16:49:49.396+0000	finished restoring weremote.events (6443 documents)
2020-01-01T16:49:49.396+0000	done

Hopefully software developers who find themselves in a similar situation will find this article useful.

As a closing thought, if you're experiencing issues in backing up your database using mongodump, such as connection issues, or cluster selection problems, but you are able to connect to the database using the mongo client, you might have different versions of mongodump on your jump server than on your database machine.

Are you a MongoDB professional? Looking for remote jobs? Sign up for an account.

Subscribe for updates

Remote work enthusiasts everywhere are already getting blog updates and fresh jobs.

Join us on Twitter and Instagram or let's connect on Linkedin

Learn more about our Policies or find out how we can help you.

Β© 2020 WeRemote Europe