Is it possible to restore databases which were manually copied from /var/lib/mongodb
to eg. /home/foo/mongobackup
?
I am not sure if the backup was made after stopping the mongod service. Either way, no files were written to the database when doing the backup. Unfortunately mongodump
was not used. I tried to simply change dbpath
in /etc/mongodb.conf
to /var/lib/mongodb_backup
. Trying the reload the backupped database I encounter errors. The problem for now seems to be a not one of data integrity, but a permission one, I can't figure out.
I get errors and mongod does not start (see log below). However both directories, the previous working, but empty one, and the backup have the same permissions and owners and are placed at the same directory ( /var/lib/
(Fedora 20)).
I get the following output when trying to systemctrl start mongod.service
:
Thu Feb 5 12:37:11.879 [initandlisten] MongoDB starting : pid=27936 port=27017 dbpath=/var/lib/mongodb_backup 64-bit host=openbeaconserver
Thu Feb 5 12:37:11.879 [initandlisten] db version v2.4.6
Thu Feb 5 12:37:11.879 [initandlisten] git version: nogitversion
Thu Feb 5 12:37:11.879 [initandlisten] build info: Linux buildvm-12.phx2.fedoraproject.org 3.10.9-200.fc19.x86_64 #1 SMP Wed Aug 21 19:27:58 UTC 2013 x86_64 BOOST_LIB_VERSION=1_54
Thu Feb 5 12:37:11.879 [initandlisten] allocator: tcmalloc
Thu Feb 5 12:37:11.879 [initandlisten] options: { command: [ "run" ], config: "/etc/mongodb.conf", dbpath: "/var/lib/mongodb_backup", fork: "true", journal: "true", logpath: "/var/log/mongodb/mongodb.log", pidfilepath: "/var/run/mongodb/mongodb.pid", port: 27017, quiet: true }
Thu Feb 5 12:37:11.879 [initandlisten] exception in initAndListen std::exception: boost::filesystem::status: Permission denied: "/var/lib/mongodb_backup", terminating
Thu Feb 5 12:37:11.879 dbexit:
I checked the permissions, they are identical:
working / empty mongodb path:
ls -la mongodb
insgesamt 81936
drwxr-xr-x. 3 mongodb root 4096 19. Sep 2013 .
drwxr-xr-x. 54 root root 4096 5. Feb 12:03 ..
drwxr-xr-x. 2 mongodb mongodb 4096 5. Feb 11:53 journal
-rw-------. 1 mongodb mongodb 67108864 4. Feb 16:21 local.0
-rw-------. 1 mongodb mongodb 16777216 4. Feb 16:21 local.ns
-rwxr-xr-x. 1 mongodb mongodb 0 5. Feb 11:53 mongod.lock
backup:
ls -la mongodb_backup/
insgesamt 39778456
drwxr-xr-x. 2 mongodb root 4096 28. Jul 2014 .
drwxr-xr-x. 54 root root 4096 5. Feb 12:03 ..
-rw-------. 1 mongodb mongodb 67108864 15. Apr 2014 openbeacon.0
-rw-------. 1 mongodb mongodb 134217728 1. Nov 2013 openbeacon.1
-rw-------. 1 mongodb mongodb 2146435072 4. Apr 2014 openbeacon.10
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.11
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.12
-rw-------. 1 mongodb mongodb 2146435072 5. Mai 2014 openbeacon.13
-rw-------. 1 mongodb mongodb 2146435072 8. Jul 2014 openbeacon.14
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.15
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.16
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.17
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.18
-rw-------. 1 mongodb mongodb 2146435072 15. Apr 2014 openbeacon.19
-rw-------. 1 mongodb mongodb 268435456 10. Jul 2014 openbeacon.2
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.20
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.21
-rw-------. 1 mongodb mongodb 2146435072 8. Jul 2014 openbeacon.22
-rw-------. 1 mongodb mongodb 536870912 10. Jul 2014 openbeacon.3
-rw-------. 1 mongodb mongodb 1073741824 10. Jul 2014 openbeacon.4
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.5
-rw-------. 1 mongodb mongodb 2146435072 8. Jul 2014 openbeacon.6
-rw-------. 1 mongodb mongodb 2146435072 9. Jul 2014 openbeacon.7
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.8
-rw-------. 1 mongodb mongodb 2146435072 10. Jul 2014 openbeacon.9
-rw-------. 1 mongodb mongodb 16777216 10. Jul 2014 openbeacon.ns
The only difference is the missing journal and mongod.lock
.
Is there something else to consider concering file and directory permissions? It is just strange, because both database directories seem to be identical.
Best Answer
If SELinux is enabled you can try stopping mongo and then running:
Maybe SELinux contexts were broken while transferring files.