I have a backup of /data/db that contains all .wt files along with journal directory etc. I have stopped the db, replaced the current db directory with the one backed up and started the db. This works, Mongo starts up but when I "show databases" there are no results. The local machine (that was backed up) did not have authentication enabled. The machine I am using to attempt the restore does have it enabled, I am able to start the mongo client without any authentication.
Is there another step to this process?
Is the authentication difference an issue?
Related
In a production server (Windows Server 2012 R2), we run out of space in the main HDD where a PostgreSQL 9.3 database was stored, so I had to move out the data directory to another drive. I followed all the steps to do it that, stop the server, move the data directory, change the folder permissions and change the -D start parameters.
I could start the server, but it only shows the default postgres db and user (I checked in pgAdmin and psql). All the files are there, even if I try to recreate the same user, I get an user already exist error. I also confirmed if the server started with the new directory (SHOW data_directory;).
Then I move back all the files to the original drive and I have the same problem.
I also checked the logs, but it shows nothing relevant to the problem.
After a complete reinstall of mongo, it has still remembered the replica set configuration from before; where has it stored this?
I installed mongo on a linux server, using our project's user account, into a directory owned by that user. I set up replication and had it working fine. Then, to test out some finer install points, I removed the whole mongo directory and did a reinstall. Entering into mongo, I found that the replication was already set up as before; so it would appear that mongo is storing the information somewhere.
I have checked several areas which might have been holding the replica set config:
First, in the mongo directory, but that was deleted.
In some traditional linux structure probably owned by root, but the project user does not have root access and mongo, run by the same, should not either.
The project user's home directory. Now this does have a .dbshell file containing the command line history, but only that. I did not see any other files there that related.
Some location specified in the mongo configuration. But I only have two paths mentioned in there, one for the system log (systemLog.path) and the other for storage (storage.dbPath), and the both point to the mongo directory, which was deleted.
Does anyone know where mongo is storing this configuration information?
The replication data is stored in the local database in each node (as of MongoDB 3.2.9). This database contains information about the replica set, and also contains the oplog (the oplog.rs collection). The replica set information is stored in the system.replset collection in this local database.
The physical files for this database (and also for other databases) are stored in the dbPath directory, which can be configured using:
The --dbpath parameter when starting mongod
The storage.dbPath setting in the configuration file
The default dbpath value is /data/db
Your replica set setting will not be retained if you emptied the dbpath directory. If you find that the replication settings are being retained, it is possible that the dbpath setting is incorrect.
One of my servers has a virus and the Postgres service in Windows is not running a backup and I'm using Odoo8 and even the Odoo Service is not running.
Is it possible to restore a database using only a OID directory which from what I know is the database file of Postgres.
I assume you mean /data/base/<oid> directory. Unfortunately it's not enough. There are some settings stored outside database oid directory as you called it.
Ex:
/data/glboal/ - cluster users' settings (passwords, roles etc)
/data/pg_xlog/ - WAL entries - possibly with transactions changes not "transfered" to database files yet.
/data/pg_tblspc/ - tablespaces
You need whole /data directory. Read more about PHYSICAL BACKUP.
Edit:
So, if whole /data is available for you, you can restore database to other server. There's one thing you should remember: destination postrges cluster must be at the same varsion ex. 9.4.1. When the first and seccond numbers match (ex 9.2.10 and 9.2.16) this should also work most of the times. Keeping that in mind, you just need to replace /data/ directory on destination server with your source /data directory (destination server must be stopped during that operation).
Our server is down and have no backups on our dbs. But we were able to get data/db using WinSCP. It would be fortunate if we could use these data files to restore our dbs. I have tried setup mongodb in other server and copied data/db from failed server. As I started mongod instance in the new server it says a compatibility issue with authentication schema that data files from data/db was. So we cannot start mongod. I wonder if there's a work around so we can start a mongod with the old data/db from failed server? Or other way to restore dbs? Thank you very much.
I am migrating from server OLD at the old hosting company to server NEW at the new hosting company.
I want to run the clone command so I clone the mongoDB from OLD to NEW.
For OLD:
The public ip address is: 44.55.66.77.
The machine login user name is: admin, and the password is password
What is the right way to do this?
So far I can't even log into the server OLD
So far I have tried the following command prompts on NEW:
mongo -u admin -p password 44.55.66.77
mongo remote-ip:44.55.77.66 -u admin -p password
That don't work
I also tried this from mongo shell:
db.CopyDatabase('OldDb', 'NewDb', '44.55.66.77', 'admin', 'password')
and I get: the "could not connect to server" error message
Aside from firewall considerations in order to copy data between MongoDB servers, db.copyDatabase() (aka the copydb command) has a number of important usage caveats including:
copydb does not produce point-in-time snapshots of the source database; writing data to the source or destination database during the copy process will result in divergent data sets
copydb does not lock the destination server during its operation, so the copy will occasionally yield to allow other operations to complete.
There is also a known issue that copydb may not work with the role-based privileges in MongoDB 2.4 if you have authentication enabled (see SERVER-8213, which was recently fixed in the 2.5.x development releases).
A much better approach to migrating your data would be to restore from a normal backup using mongodump/mongorestore or file system snapshots. The Backup & Recovery section of the MongoDB manual has tutorials covering procedures for different deployment types.