mongodb – Recover a mongo database erased by rm

We accidentally lost our database by a bash script, which turned out to be executed rm -rf / * (see this thread). Thanks to extundelete, we just recovered the / data / db / binder:

enter the description of the image here

However, we were not able to successfully load the database in Robo 3T; It looks pretty empty here:

enter the description of the image here

Here is the result of running. mongod --port 27017 --dbpath / data / db --bind_ip_all:

root @ iZj6c0pipuxk17pb7pbaw0Z: / data # mongod --port 27017 --dbpath / data / db --bind_ip_all

2019-03-25T08: 49: 52.425 + 0800 I CONTROL  [main] Automatic deactivation of TLS 1.0, to force the TLS 1.0 enable specify --sslDisabledProtocols & # 39; none & # 39;
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] Start of MongoDB: pid = 6130 port = 27017 dbpath = / data / db 64-bit host = iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] db version v4.0.7
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] Git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g March 1, 2016
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] dispatcher: tcmalloc
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] Modules: none
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] Construction environment:
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten]     distmod: ubuntu1604
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten]     Distarch: x86_64
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten]     target_arch: x86_64
2019-03-25T08: 49: 52.452 + 0800 I CONTROL  [initandlisten] options: {net: {port: 27017}, storage: {dbPath: "/ data / db"}}
2019-03-25T08: 49: 52.455 + 0800 W STORAGE  [initandlisten] Detected impure close: /data/db/mongod.lock is not empty.
2019-03-25T08: 49: 52.455 + 0800 I STORAGE  [initandlisten] Data files detected in / data / db created by the storage engine & # 39; wiredTiger & # 39 ;, so the active storage engine is set to & # 39; wiredTiger & # 39 ;.
2019-03-25T08: 49: 52.455 + 0800 W STORAGE  [initandlisten] Retrieving data from the last clean control point.
2019-03-25T08: 49: 52.455 + 0800 I STORAGE  [initandlisten]
2019-03-25T08: 49: 52.455 + 0800 I STORAGE  [initandlisten] ** WARNING: It is recommended to use the XFS file system with the WiredTiger storage engine
2019-03-25T08: 49: 52.455 + 0800 I STORAGE  [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T08: 49: 52.455 + 0800 I STORAGE  [initandlisten] wiredtiger_open config: create, cache_size = 256M, session_max = 20000, eviction = (threads_min = 4, threads_max = 4), config_base = false, statistics = (fast), log = (enabled = true, archive = true, path = journal, compressor = snappy), file_manager = (close_idle_time = 100000), statistics_log = (wait = 0), verbose = (recovery_progress),
2019-03-25T08: 49: 53.090 + 0800 E STORAGE  [initandlisten] WiredTiger error (17) [1553474993:90473][6130:0x7f41f14f9a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: The file exists Raw: [1553474993:90473][6130:0x7f41f14f9a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: the file exists
2019-03-25T08: 49: 53.090 + 0800 STORAGE  [initandlisten] The WiredTiger.wt unexpected message file was found from WiredTiger, whose name changed to WiredTiger.wt.1
2019-03-25T08: 49: 53.689 + 0800 STORAGE  [initandlisten] Message from WiredTiger [1553474993:689973][6130:0x7f41f14f9a40], txn-recover: Main recovery loop: from 4/11366912 to 5/256
2019-03-25T08: 49: 53.692 + 0800 STORAGE  [initandlisten] Message from WiredTiger [1553474993:692366][6130:0x7f41f14f9a40], txn-recover: Recovery of log 4 to 5
2019-03-25T08: 49: 53.761 + 0800 STORAGE  [initandlisten] Message from WiredTiger [1553474993:761295][6130:0x7f41f14f9a40], txn-recover: Recovery of log 5 to 5
2019-03-25T08: 49: 53.826 + 0800 I STORAGE  [initandlisten] Message from WiredTiger [1553474993:826192][6130:0x7f41f14f9a40], txn-recover: Set global recovery time stamp: 0
2019-03-25T08: 49: 53.859 + 0800 RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp (0, 0)
2019-03-25T08: 49: 53.863 + 0800 E STORAGE  [initandlisten] WiredTiger error (17) [1553474993:863179][6130:0x7f41f14f9a40], WT_SESSION.create: __posix_open_file, 715: /data/db/_mdb_catalog.wt: handle-open: open: The file exists Raw: [1553474993:863179][6130:0x7f41f14f9a40], WT_SESSION.create: __posix_open_file, 715: /data/db/_mdb_catalog.wt: handle-open: open: The file exists
2019-03-25T08: 49: 53.863 + 0800 I STORAGE  [initandlisten] The unexpected file was found in the WiredTiger _mdb_catalog.wt message, whose name was changed to _mdb_catalog.wt.1
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten]
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** Read and write access to data and configuration is not restricted.
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** WARNING: You are running this process as root user, which is not recommended.
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten]
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** WARNING: This server is linked to localhost.
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** Remote systems can not connect to this server.
2019-03-25T08: 49: 53.877 + 0800 I CONTROL  [initandlisten] ** Start the server with --bind_ip 
specify which IP 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] ** the addresses in which the responses of, or with 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] ** link to all interfaces. If this behavior is desired, start the 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] ** server with --bind_ip 127.0.0.1 to disable this warning. 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] 2019-03-25T08: 49: 53.878 + 0800 I CONTROL [initandlisten] ** WARNING: soft limits too low. Limits established in 3824 processes, 65535 files. The number of processes must be at least 32767.5: 0.5 times the number of files. 2019-03-25T08: 49: 53.895 + 0800 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 07c86964-7065-424b-ad94-81a3388b41c1 2019-03-25T08: 49: 53.910 + 0800 I COMMAND [initandlisten] configuring featureCompatibilityVersion to 4.0 2019-03-25T08: 49: 53.921 + 0800 I STORAGE [initandlisten] createCollection: local.startup_log with generated UUID: 70822443-d50b-41af-b5ce-1a51e96e4be3 2019-03-25T08: 49: 53.937 + 0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with the directory & # 39; /data/db/diagnostic.data' 2019-03-25T08: 49: 53.940 + 0800 I RED [initandlisten] waiting for connections in port 27017 2019-03-25T08: 49: 53.957 + 0800 STORAGE [LogicalSessionCacheRefresh] createCollection: config.system.sessions with UUID generated: ce139bc0-906a-427a-8e57-4aa42b061e6a 2019-03-25T08: 49: 53.974 + 0800 I INDEX [LogicalSessionCacheRefresh] compile index in: config.system.sessions properties: {v: 2, password: {lastUse: 1}, name: "lsidTTLIndex", ns: "config.system.sessions", expireAfterSeconds: 1800} 2019-03-25T08: 49: 53.974 + 0800 I INDEX [LogicalSessionCacheRefresh] construction index using the bulk method; compilation can temporarily use up to 500 megabytes of RAM 2019-03-25T08: 49: 53.976 + 0800 I INDEX [LogicalSessionCacheRefresh] compilation index done. scanned 0 total records. 0 seconds 2019-03-25T08: 50: 51.611 + 0800 I RED [listener] connection accepted from 127.0.0.1:59894 # 1 (1 connection now open) 2019-03-25T08: 50: 51.612 + 0800 I RED [conn1] received client metadata from 127.0.0.1:59894 conn1: {application: {name: "MongoDB Shell"}, driver: {name: "MongoDB internal client", version: "4.0.7"}, os: {type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04"}}

Does anyone understand what is happening? Does anyone know how to recover this mongodb?