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 \
--gzipThis 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.
root@20561a786828:/# 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 archiveWhoops! 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 😅.
root@20561a786828:/# 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 doneHopefully 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.