Dump and Restore Live instance

I have a single mongo db 4.2 instance running on windows. I am trying to provide a ‘hot’ or live backup of the instance without stopping or shutting down. I am getting errors during a dry run of the restore and am unsure if I am doing something wrong.

To ensure the backup is consistent, I am running with the --oplog option. To support the oplog, I attempted to configure a replication set with a single member, the server itself. The server configuration was modified to include:

replication:
   oplogSizeMB: 2048
   replSetName: rs0

I the ran the follow command on the server:

rs.initiate({ "_id" : "rs0", "version" : 1, "members" : [{ "_id" : 0, "host" : "127.0.0.1:27017" }]})

I restarted the server instance and attempted to create a backup as such:

mongodump.exe --oplog --archive=f:\test.mongo_data.gz --gzip --username "xxxx" --password "yyyy"

This appears to run correctly and produces the test.mongo_data.gz file.

Now I want to restore this to another server to test the restore process. I have copied the file to the other server, which is configured identically. It has some existing data, but it is safe to remove it all. To simplify restore, I disable authorization and only allow connections from localhost. I attempt to restore with command:

mongorestore.exe --oplogReplay --drop --preserveUUID --gzip --archive=E:\data\test.mongo_data.gz --dryRun --verbose

This results in:

using write concern: &{majority false 0}
archive prelude wdms.journal
archive prelude config.image_collection
archive prelude wdms.blobs
archive prelude wdms.settings
archive prelude wdms.nodes
archive prelude wdms.clusterNodes
archive prelude .oplog
archive prelude admin.system.users
archive prelude admin.system.version
preparing collections to restore from
found collection wdms.journal bson to restore to wdms.journal
found collection metadata from wdms.journal to restore to wdms.journal
found collection wdms.blobs bson to restore to wdms.blobs
found collection metadata from wdms.blobs to restore to wdms.blobs
found collection wdms.settings bson to restore to wdms.settings
found collection metadata from wdms.settings to restore to wdms.settings
found collection wdms.nodes bson to restore to wdms.nodes
found collection metadata from wdms.nodes to restore to wdms.nodes
found collection wdms.clusterNodes bson to restore to wdms.clusterNodes
found collection metadata from wdms.clusterNodes to restore to wdms.clusterNodes
found collection config.image_collection bson to restore to config.image_collection
found collection metadata from config.image_collection to restore to config.image_collection
found collection .oplog bson to restore to .oplog
don't know what to do with subdirectory "wdms", skipping...
don't know what to do with subdirectory "config", skipping...
don't know what to do with subdirectory "", skipping...
don't know what to do with subdirectory "admin", skipping...
found collection admin.system.users bson to restore to admin.system.users
found collection metadata from admin.system.users to restore to admin.system.users
found collection admin.system.version bson to restore to admin.system.version
found collection metadata from admin.system.version to restore to admin.system.version
dry run completed
0 document(s) restored successfully. 0 document(s) failed to restore.

I am concerned with the “don’t know what to do with subdirectory …” messages. Are they indicative of an error that will affect the restore?

You have to give --d or --db flag in restore command for older versions
I think for 3.0 & above you have to give nsInclude flag
Check mongo documentation for details

Thanks, but the --oplogReplay flag does not allow --db or --collection options to be used. I don’t think that will work.

Did you try nsInclude?
–db is for older versions as I mentioned above

nsInclude is also unavailable: mongorestore — MongoDB Manual

When using mongorestore with --oplogReplay to restore a replica set, you must restore a full dump of a replica set member created using mongodump --oplog.

mongorestore with --oplogReplay fails if you use any of the following options to limit the data to be restored:
    --db
    --collection
    --nsInclude
    --nsExclude

Cd to the directory where your dump file is residing and try to run or you may have to use oplogfile parameter
Kevin(Kevinadi) may be able to help you more on this as ihave seen a thread asking to use oplogfile