1

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.

serv-inc
  • 167
  • 9
nylki
  • 203
  • 2
  • 9

2 Answers2

2

If SELinux is enabled you can try stopping mongo and then running:

restorecon -R /var/lib/mongodb*

Maybe SELinux contexts were broken while transferring files.

Jakov Sosic
  • 5,157
  • 3
  • 22
  • 33
  • This seemed to partly work, atleast no permission errors anymore! now my problem appears to be a filled up filesystem, getting a `ERROR: Insufficient free space for journal files`. I will try to fix that separate issue and come back later here. thx so far! – nylki Feb 05 '15 at 14:02
0

The problem isn't the files but the directory

Here is the error

 Permission denied: "/var/lib/mongodb_backup"

If you do this

 ls -lsd /var/lib/mongodb_backup

That will be root:root so run the following

 chown mongodb: /var/lib/mongodb_backup
Mike
  • 21,910
  • 7
  • 55
  • 79
  • I understand, but the directory that returns no errors, has identical permissions, and it is already `mongodb:root`. see: `ls -lsd /var/lib/mongodb_backup 4 drwxr-xr-x. 2 mongodb root 4096 28. Jul 2014 /var/lib /mongodb_backup [root@openbeaconserver lib]# ls -lsd /var/lib/mongodb 4 drwxr-xr-x. 3 mongodb root 4096 19. Sep 2013 /var/lib/mongodb` – nylki Feb 05 '15 at 12:53
  • Just to be sure, I executed `chown mongodb: /var/lib/mongodb_backup` as you advised, but the error is still the same. Now `mongodb_backup`is owned by mongodb and is in group mongodb. – nylki Feb 05 '15 at 13:01