Restore mongodb standalone

Ops and Admin
1

Hi All,

We have lost data in collection documents, before 13th July, we have these files in /data/db dir how can we recover it usng /data/db dir, we checked all other dir, /var we didnt find any WT except in /data/db dir… below files present in /data/db

collection-0--1930030124829508624.wt    
collection-0--5138667409853774933.wt    
collection-0--7067830708941503295.wt    
collection-0--7947847146613003270.wt    
collection-12--5138667409853774933.wt
diagnostic.data/
index-1--1930030124829508624.wt
index-1--7067830708941503295.wt
index-10--5138667409853774933.wt
mongod.lock
journal/
sizeStorer.wt
sizeStorer.wt.1
storage.bson
WiredTiger
WiredTiger.lock
WiredTiger.turtle
WiredTiger.wt
WiredTiger.wt.orig
WiredTigerLAS.wt

How can we restore with old data before 13th July in collections, we don’t have current backup present at the moment.

2

To do a restore you first need a backup. A filesystem snapshot is good enough.

1 Like
4

By your own words you don’t have a backup, ergo you cannot restore. You would need the database file at the point before you lost your data.

The files you have for your standalone database represent the database as it is now or when you shut it down.

1 Like
5

Thanks Chris for feedback.

We have checked with our dba team they are suggesting all the collection and index files before 13th july are present in /data/db dir…whcih i have shared above.

Suppose if DBAs are telling correctly that all the files before 13th july are present in /data/db dir, how can we restore it any methods.

Current senerio is i checked the collections by taking latest mongodump in standalone db and checked in one db collection documents are present after 13th july to sysdata in collection files.

Any suggestion would be great help, we need to recover the old data before 13th july, what steps we have to follow.

We checked all the files before shut down, no WT files found except /data/db dir.

6

So there was a backup and they have given you files? Why would your dba team not just do the recovery for you, that is a dba’s role.

Then you should be able to start mongod using /data/db for the --dbpath option(this is the default anyway).

If the data is not there, then you need files from further back.

1 Like
7

Thanks Chris for the feedback.

We have standlone db in prod, and we are planning to run this steps to restore mongodb old data before 13th July data.

  1. taken mongodump backup of all dbs using mongodump command

  2. take backup of current collection and index WT files present in data/db dir.

  3. As dba team suggest us all files present in /data/db dir before 13th July also
    Will run the command after backups :
    mongod --dbpath /data/db

  4. now if suppose db is not coming up, what should we do .
    and also we have question we dont have any test and dev env setup so will do run these commands in prod db only.

  5. we need suggestions the data which is present in /data/db dir from 13th july to till date if suppose restore happens from mongod --dbpath /data/db command will current data will mismatch , is there any conflicts in data can occur.

for all these please suggest, thanks.

8

Hi @bp_sin

I would be very cautious in your scenario. I strongly recommend you take a backup of your production database and test all outcomes in a separate environment first. If this is critical production data to restore and your team doesn’t have the in-house expertise, I would consider hiring a consultant for assistance.

If I understand your situation correctly:

  • Some data before July 13th was accidentally deleted
  • You have a file copy backup of the dbPath before the data was deleted
  • You want to merge missing data into a production database

The last step is the most complicated: unless collections of interest happen to be insert only, there may be conflicts between the current data and the data as of a month ago. You will have to work out how to reconcile any differences. Restoring older data will also include data that has been intentionally removed at a later date.

My suggested approach would be:

  • Start a mongod in a test environment using the dbPath backup from July 13th. Verify that this is a viable backup and the data that you are looking for is available.
  • Take a backup of your production data and restore into a separate mongod in a test environment.
  • Write queries (or a script) to compare collections of interest in these two test environments.
  • Use mongodump --query to selectively export missing data from the July 13th backup.
  • Import into your production test server using mongorestore, and verify the outcomes are as you expect.
  • Repeat in production once you are confident your procedure results in the desired outcome. Always take fresh backups before doing any maintenance procedures that might alter data.

Unless your production data is not essential, I would take the time to set up a test environment.

Regards,
Stennie

9

Thanks Stennie,

Could you please assist from WT collection and index files present in /data/db dir , how to restore the old data.
is we can use mongod --dbpath /data/db command to restore , before that will take the backup using mongodump and current backup of all files present inn /data/db dir.

for test env creation can we keep all this /data/db dir fles in our local system where i have installed mongo in dir: /data/ and restart mongod to test.

10

Hi @bp_sin,

If you follow my suggested approach above, the first step is making sure you have a viable file copy backup:

  • Start a mongod in a test environment using the dbPath backup from July 13th. Verify that this is a viable backup and the data that you are looking for is available.

If these files are a viable backup copy, mongod --dbpath /path/to/your/backup should start without any errors relating to data files and you will be able to query to confirm if the data you are looking for is present.

If the WT files you have are not a consistent backup, your options are unfortunately limited. You can try repairing or salvaging data as a last resort but that is often unsuccessful (see: Recover corrupted files (MongoDB 3.0.12) .wt - #4 by Stennie_X).

You should have separate paths for data files belonging to different backups or environments. Mixing files from different deployments may result in an unusable deployment.

I’d still recommend engaging a consultant (or your DBA team, if there is someone with more MongoDB admin experience on the team) as incorrect manipulation of data files or merging of data could lead to further challenges.

Regards,
Stennie

1 Like
11

Thanks Stennie for feedback.

My approach am trying please suggest is it correct:

  1. I will install mongodb in my local system.
  2. I have copy of all the files which is present in /data/db dir in production env, i will copy all the WT files into my local system in suppose dir /data
  3. Startng mongod using path /data: mongod --dbpath /data
  4. check the collection documents and check if all the documents before 13th July stored in documents by querying from robo3t.

any other steps you would like to provide which i can test in my local system, thanks.

Or any other files i also need to copy apart from all the files from prod in /data/db dir.
to setup and test.

12

Thanks Stennie,

I have run in my local system by copying all the WT files from /data/db to /data/backup_restore and run the command mongod --dbpath /data/backup_restore, it’s still running from last 3 hours.

Could you please suggest if any files missing or corrupt files present in /data/db dir how can we restore the data before july 13 old data.

any suggestions.

13

Thanks Chris,

If suppose some of files are missing before 13th july in /data/db dir in prod env, can we still restore the rest of data present before 13th july in WT collection and index files in /data/db dir
using command

mongod --dbpath /data/db

how can we approach to test env first,

Can you please suggest

What are the steps to be follow in test env to replicate this senerios.

We have no data before 13th July in standalone db, DBA team updating all datafiles are present in /data/db dir in prod env, if there statmenet is correct then can we restore the old data directly in prod.

I have installed mongodb in my local system, if want to replicate the prod senerio my approach below:-

  1. copy all the files from prod env(/data/db) to another dir in local system lets say /data/backup
  2. then start the mongod --dbpath /data/backup
    will it restore all the old data before 13th july.
14

Hi @bp_sin,

mongod is the primary daemon process for MongoDB. On startup, mongod will verify the integrity of files in the dbpath but I wouldn’t expect this to take 3 hours for the 5 collections you have listed in your earlier output.

What is the last output from mongod? It may have started up successfully and be waiting for connections.

Running mongod with an older backup of your data files will allow you to query and potentially mongodump relevant data. This is not doing any sort of “restore” process: you have to do that manually and reconcile any differences between your two environments.

There should be startup errors if data files are missing or have checksum issues.

Are you working on this issue with anyone from your DBA team? As I mentioned earlier, this procedure would benefit from assistance from someone with more MongoDB admin experience.

Regards,
Stennie

1 Like
15

Thanks Stennie,
Our DBA replying with:
We should take backup.
I’m not sure that the data was actually deleted or not.
We’ve found that mongodb pod cannot access to data then tried to restore them July 16th . During that process we’ve taken a backup.
have no idea what kind of operation happened for production after that.
create new DB or overwrite them?

Could you please provide steps how will we create new mongodb.

17

How can we restore the old data from these files present in /data/db dir.

18

Hi @bp_sin,

Have you tried starting up a mongod instance with your backup copy of this dbPath as mentioned earlier?

mongod --dbpath /path/to/your/backup

If mongod is able to start successfully, you can query and export data using standard tools like the mongo shell and mongodump. Assuming the data you are looking for is present, try to follow the general guide I suggested earlier in this discussion.

If mongod has any issues reading the data files, there should be warnings logged on startup with more context on files that are missing or problematic. If you don’t have a viable backup copy, your options are limited and unlikely to be fully successful (see Recover corrupted files (MongoDB 3.0.12) .wt - #4 by Stennie, which Chris mentioned earlier).

The specific steps involved require an understanding of the data you are trying to recover and ideally someone who is working through the process with you directly (i.e. a MongoDB expert from your DBA team or an external consultant).

Regards,
Stennie

1 Like
19

HI Stennie, thanks for suggestion.
I tried copying all the files from /data/db dir of production db and restored into my local system where mongodb is installed, and kept in the dir: E:\restore_backup
and tried running mongo with command

mongod --dbpath E:\restore_backup

but it’s still runing from last 6 hours.

C:\Program Files\MongoDB\Server\5.0\bin>mongod --dbpath E:\restore_backup
{"t":{"$date":"2021-08-20T23:57:04.308+05:30"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"-","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":13},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":13},"outgoing":{"minWireVersion":0,"maxWireVersion":13},"isInternalClient":true}}}
{"t":{"$date":"2021-08-20T23:57:05.559+05:30"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"-","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2021-08-20T23:57:05.559+05:30"},"s":"W",  "c":"ASIO",     "id":22601,   "ctx":"main","msg":"No TransportLayer configured during NetworkInterface startup"}

{"t":{"$date":"2021-08-21T08:42:57.939+05:30"},"s":"I",  "c":"CONTROL",  "id":20536,   "ctx":"initandlisten","msg":"Flow Control is enabled on this deployment"}
{"t":{"$date":"2021-08-21T08:42:58.313+05:30"},"s":"I",  "c":"FTDC",     "id":20625,   "ctx":"initandlisten","msg":"Initializing full-time diagnostic data capture","attr":{"dataDirectory":"E:/restore_backup/diagnostic.data"}}
{"t":{"$date":"2021-08-21T08:42:58.320+05:30"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"127.0.0.1"}}
{"t":{"$date":"2021-08-21T08:42:58.320+05:30"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":27017,"ssl":"off"}}

any suggestions, thanks

20

Your mongod is running in foreground
Just open another cmd prompt and connect to your mongod with mongo

2 Likes
21

Thanks Ramachandra,

Getting below error:

C:\Program Files\MongoDB\Server\5.0\bin>mongo
MongoDB shell version v5.0.2
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
connect@src/mongo/shell/mongo.js:372:17
@(connect):2:6
exception: connect failed
exiting with code 1
22

I tired copy all the files from /data/db dir in prod db to my local system where mongodb is installed to location mongod --dbpath “E:\restore_backup” and run this command.

getting above error while executing.

Customer requirement to restore all the old data before july 16 , and as per dba team they are informing all the files before 16th July is present in prod mongo db in /data/db dir.

any suggestions how to restore all the old data.