Recover a mongo database deleted by rm












0















My developer accidentally lost our database by a bash script, which turned out to run rm -rf /* (see this thread). Thanks to extundelete, he just recovered the /data/db/ folder:



enter image description here



However, he could not successfully load the database in Robo 3T; it looks quite empty here:



enter image description 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-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T10:27:55.570+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-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }


Does anyone understand what's happening? does anyone know how to recover this mongodb?









share



























    0















    My developer accidentally lost our database by a bash script, which turned out to run rm -rf /* (see this thread). Thanks to extundelete, he just recovered the /data/db/ folder:



    enter image description here



    However, he could not successfully load the database in Robo 3T; it looks quite empty here:



    enter image description 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-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
    2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
    2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
    2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
    2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
    2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
    2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
    2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
    2019-03-25T10:27:55.570+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-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
    2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
    2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
    2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
    2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
    2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
    2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
    2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
    2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
    2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
    2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
    2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }


    Does anyone understand what's happening? does anyone know how to recover this mongodb?









    share

























      0












      0








      0








      My developer accidentally lost our database by a bash script, which turned out to run rm -rf /* (see this thread). Thanks to extundelete, he just recovered the /data/db/ folder:



      enter image description here



      However, he could not successfully load the database in Robo 3T; it looks quite empty here:



      enter image description 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-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
      2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
      2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
      2019-03-25T10:27:55.570+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-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
      2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
      2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
      2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
      2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
      2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
      2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
      2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
      2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
      2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
      2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }


      Does anyone understand what's happening? does anyone know how to recover this mongodb?









      share














      My developer accidentally lost our database by a bash script, which turned out to run rm -rf /* (see this thread). Thanks to extundelete, he just recovered the /data/db/ folder:



      enter image description here



      However, he could not successfully load the database in Robo 3T; it looks quite empty here:



      enter image description 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-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
      2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
      2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
      2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
      2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
      2019-03-25T10:27:55.570+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-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
      2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
      2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
      2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
      2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
      2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
      2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
      2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
      2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
      2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
      2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
      2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }


      Does anyone understand what's happening? does anyone know how to recover this mongodb?







      mongodb recovery disaster-recovery mongo-repair





      share












      share










      share



      share










      asked 6 mins ago









      SoftTimurSoftTimur

      1113




      1113






















          0






          active

          oldest

          votes











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "182"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232972%2frecover-a-mongo-database-deleted-by-rm%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          0






          active

          oldest

          votes








          0






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes
















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Database Administrators Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232972%2frecover-a-mongo-database-deleted-by-rm%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          SQL Server 17 - Attemping to backup to remote NAS but Access is denied

          Always On Availability groups resolving state after failover - Remote harden of transaction...

          Restoring from pg_dump with foreign key constraints