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
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.