When MongoDB fails to start properly, administrators often resort to running mongod --repair after removing the mongod.lock file. However, this can sometimes lead to partial database recovery, leaving the original data files (.ns, .0, .1, etc.) intact but inaccessible through normal MongoDB operations.

The mongorestore utility works with BSON dump files, not with MongoDB's raw storage files. When you're left with only the .ns and numbered data files, you need a different approach:

// This won't work with raw data files
mongorestore --db mydb /var/lib/mongodb/mydb.ns

1. Create a Clean MongoDB Instance

First, set up a new MongoDB instance to receive the recovered data:

mkdir -p /data/recovery_db
mongod --dbpath /data/recovery_db --port 37017

2. Copy the Original Data Files

Move (don't copy) your existing data files to a safe location:

mkdir ~/mongo_recovery
mv /var/lib/mongodb/*.ns ~/mongo_recovery/
mv /var/lib/mongodb/*.[0-9] ~/mongo_recovery/

3. Attempt File-Based Recovery

Use MongoDB's --repairpath option for a safer repair attempt:

mongod --dbpath ~/mongo_recovery \
       --repair \
       --repairpath /tmp/mongo_repair

For critical collections, you can use bsondump to extract data:

// Extract data from a specific chunk file
bsondump ~/mongo_recovery/mydb.1 > recovered_data.json

// Then import to new database
mongoimport --port 37017 --db recovered_db --collection mycoll < recovered_data.json

Implement these MongoDB best practices:

• Regularly run mongodump backups
• Monitor disk space to prevent repair failures
• Use journaling for crash recovery

// Example backup command
mongodump --out /backups/$(date +%Y%m%d)

For severely corrupted databases, consider professional recovery tools like:

• MongoDB's salvage option (use with extreme caution)
• Third-party recovery tools specifically designed for MongoDB data files

---

When working with MongoDB 2.0.4 (or similar versions), the database stores its data in a series of files with extensions like .ns, .0, .1, etc. The .ns file contains namespace metadata, while numbered files contain the actual BSON data. These files constitute MongoDB's native storage format and aren't directly compatible with tools like mongorestore which expect dump files.

In your case, several issues compounded the problem:

• Improper shutdown leaving lock files
• Repair operation failing due to permission issues
• Temporary directory deletion affecting database recovery

Option 1: Manual Database File Recovery

# Stop mongod if running
sudo service mongodb stop

# Backup existing files
sudo cp -R /var/lib/mongodb/ /var/lib/mongodb_backup

# Create a fresh dbpath
sudo mkdir /var/lib/mongodb_recovery
sudo chown mongodb:mongodb /var/lib/mongodb_recovery

# Copy original files to new location
sudo cp /var/lib/mongodb/*.ns /var/lib/mongodb_recovery/
sudo cp /var/lib/mongodb/*.0 /var/lib/mongodb_recovery/
sudo cp /var/lib/mongodb/*.1 /var/lib/mongodb_recovery/
# ... copy all numbered files

# Attempt repair with new dbpath
sudo -u mongodb mongod --dbpath /var/lib/mongodb_recovery --repair

Option 2: Using mmapv1 Storage Engine

# If using newer MongoDB versions, force old storage engine
mongod --dbpath /var/lib/mongodb_recovery --storageEngine mmapv1

After successful repair, connect to mongo shell:

mongo
> show dbs
> use problematic_db
> show collections
> db.collection.findOne()

If standard recovery fails, consider using bsondump:

bsondump /var/lib/mongodb/collection.0 > collection.json

Then re-import the JSON data into a new collection.

• Always work on copies of original files
• MongoDB 2.0.4 is very old - consider upgrading
• Journaling (introduced in later versions) prevents such issues
• Regular backups are crucial for production systems

For Ubuntu systems, ensure proper permissions:

sudo chown -R mongodb:mongodb /var/lib/mongodb
sudo chmod -R 755 /var/lib/mongodb

Configure proper shutdown procedures and consider using replica sets for redundancy.